From report at bugs.python.org  Thu Apr  1 00:06:53 2010
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Wed, 31 Mar 2010 22:06:53 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

In ceval.c there is such code:

PyObject *
PyEval_CallObject(PyObject *func, PyObject *arg)
{
	return PyEval_CallObjectWithKeywords(func, arg, (PyObject *)NULL);
}
#define PyEval_CallObject(func,arg) \
        PyEval_CallObjectWithKeywords(func, arg, (PyObject *)NULL)

Is this needed any longer? (both #define and function have the same name)

----------
components: Interpreter Core
messages: 102038
nosy: fijal
severity: normal
status: open
title: useless PyEval_CallObject function
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  1 00:09:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 22:09:20 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270073360.31.0.445477346581.issue8276@psf.upfronthosting.co.za>


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

Well, #defines are not exported in shared libraries. I suppose PyEval_CallObject() was part of an old definition of the Python C-API and it was kept for compatibility.

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

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

From report at bugs.python.org  Thu Apr  1 00:10:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 22:10:41 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270073441.11.0.879036608341.issue8276@psf.upfronthosting.co.za>


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

The #define dates back from 2007, this changeset:

branch:      trunk
user:        guido
date:        Sat Aug 30 17:02:50 1997 +0200
files:       Include/ceval.h Python/ceval.c
description:
[svn r8683] Inline PyObject_CallObject (Marc-Andre Lemburg).

----------
nosy: +lemburg

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

From report at bugs.python.org  Thu Apr  1 00:20:50 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 31 Mar 2010 22:20:50 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073441.11.0.879036608341.issue8276@psf.upfronthosting.co.za>
Message-ID: <4BB3CABE.5030907@egenix.com>


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

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> The #define dates back from 2007, this changeset:
> 
> branch:      trunk
> user:        guido
> date:        Sat Aug 30 17:02:50 1997 +0200
> files:       Include/ceval.h Python/ceval.c
> description:
> [svn r8683] Inline PyObject_CallObject (Marc-Andre Lemburg).

That's not useless: it's a typical backwards compatibility macro
to auto-upgrade existing software via recompile.

It's also still used a lot in the Python source code and elsewhere:

http://www.google.de/search?q=PyEval_CallObject

The function PyEval_CallObject() can probably be removed by
now, though.

----------

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

From report at bugs.python.org  Thu Apr  1 00:26:04 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 31 Mar 2010 22:26:04 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1270074364.41.0.38284458052.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100331.zip is a new version of the regex module.

It includes speed-ups and a minor bugfix.

----------
Added file: http://bugs.python.org/file16709/issue2636-20100331.zip

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

From report at bugs.python.org  Thu Apr  1 00:57:24 2010
From: report at bugs.python.org (Nir Aides)
Date: Wed, 31 Mar 2010 22:57:24 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1270076244.85.0.137248340704.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16680/bfs.patch

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

From report at bugs.python.org  Thu Apr  1 00:58:12 2010
From: report at bugs.python.org (Nir Aides)
Date: Wed, 31 Mar 2010 22:58:12 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1270076292.16.0.732492393699.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I upload a new update to bfs.patch which improves scheduling and reduces overhead.

----------
Added file: http://bugs.python.org/file16710/bfs.patch

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

From report at bugs.python.org  Thu Apr  1 01:03:57 2010
From: report at bugs.python.org (Valerio)
Date: Wed, 31 Mar 2010 23:03:57 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270076637.79.0.720153189641.issue8193@psf.upfronthosting.co.za>


Changes by Valerio <turturici.valerio at gmail.com>:


Removed file: http://bugs.python.org/file16707/8193.patch

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

From report at bugs.python.org  Thu Apr  1 01:21:45 2010
From: report at bugs.python.org (Valerio)
Date: Wed, 31 Mar 2010 23:21:45 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270077705.54.0.888353962467.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

While i wait for what i have to do, i corrected the patch. But there is a problem: the version of zlib '1.2.3.3' raise an error on "distutils.version" module. The problem is caused by the regex expression in the "distutils.version" module:

version_re = re.compile(r'^(\d+) \. (\d+) (\. (\d+))? ([ab](\d+))?$',
                            re.VERBOSE)

this expression don't match with the type of version that zlib.ZLIB_VERSION return.

----------
Added file: http://bugs.python.org/file16711/8193.patch

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

From report at bugs.python.org  Thu Apr  1 01:26:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 31 Mar 2010 23:26:56 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1270078016.96.0.727539830224.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Now the "-Wd" and "-3" flags are active on some buildbots.
And the first failures ...


Need to backport fixes from py3k branch for:
- cgitb "SyntaxWarning: tuple parameter unpacking has been removed in 3.x"
- idlelib "reduce() not supported in 3.x; use functools.reduce()"


And test_multiprocessing is failing on: "sys.exc_clear() not supported in 3.x; use except clauses"

----------

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

From report at bugs.python.org  Thu Apr  1 01:32:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 31 Mar 2010 23:32:10 +0000
Subject: [issue7583] doctest should normalize tabs when comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270078330.65.0.907887787378.issue7583@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16712/issue7583.doctest.tabs.diff

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

From report at bugs.python.org  Thu Apr  1 01:36:49 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 31 Mar 2010 23:36:49 +0000
Subject: [issue7583] [patch] doctest should normalize tabs when comparing
	output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270078609.53.0.517101266075.issue7583@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
title: doctest should normalize tabs when comparing output -> [patch] doctest should normalize tabs when comparing output

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

From report at bugs.python.org  Thu Apr  1 01:38:05 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 31 Mar 2010 23:38:05 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270078685.04.0.329413703063.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

depends on issue #7583

----------

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

From report at bugs.python.org  Thu Apr  1 01:44:15 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 31 Mar 2010 23:44:15 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1270079055.47.0.845755400993.issue2521@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Added file: http://bugs.python.org/file16713/abc_leak.patch

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

From report at bugs.python.org  Thu Apr  1 01:45:06 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 31 Mar 2010 23:45:06 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1270079106.44.0.189066394519.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

New patches uploaded.  I separated out the patch to add the test case, to make it easier to test before and after applying the fix.

----------
Added file: http://bugs.python.org/file16714/leak_test.patch

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

From report at bugs.python.org  Thu Apr  1 01:45:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 31 Mar 2010 23:45:12 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1270079112.7.0.153900082501.issue2521@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file16690/abc_leak.patch

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

From report at bugs.python.org  Thu Apr  1 02:02:40 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 00:02:40 +0000
Subject: [issue7583] [patch] doctest should normalize tabs when comparing
	output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270080160.52.0.481262012797.issue7583@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

http://codereview.appspot.com/848043/show

----------

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

From report at bugs.python.org  Thu Apr  1 02:28:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 00:28:08 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1270081688.09.0.243162217005.issue7443@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It would be nice to see standalone test case that illustrates the problem.

----------
nosy: +techtonik

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

From report at bugs.python.org  Thu Apr  1 03:33:41 2010
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Thu, 01 Apr 2010 01:33:41 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270085621.07.0.680378827427.issue8276@psf.upfronthosting.co.za>


Maciek Fijalkowski <fijal at genesilico.pl> added the comment:

Yeah, I meant the function. Sorry for not being specific enough. I suppose the function is there to preserve ABI, but definitely code needed recompilation since 2007.

----------

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

From report at bugs.python.org  Thu Apr  1 03:37:47 2010
From: report at bugs.python.org (Patrick W.)
Date: Thu, 01 Apr 2010 01:37:47 +0000
Subject: [issue8277] ElementTree won't parse comments
In-Reply-To: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>
Message-ID: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>


New submission from Patrick W. <poke at BornToLaugh.de>:

When using xml.etree.ElementTree to parse external XML files, all XML comments within that file are being stripped out. I guess that happens because there is no comment handler in the expat parser.

Example:

test.xml
--------
<example>
  <nodeA />
  <!-- some comment -->
  <nodeB />
</example>

test.py
-------
from xml.etree import ElementTree
with open( 'test.xml', 'r' ) as f:
    xml = ElementTree.parse( f )
ElementTree.dump( xml )

Result
------
<example>
  <nodeA />

  <nodeB />
</example>

----------
components: XML
messages: 102051
nosy: poke
severity: normal
status: open
title: ElementTree won't parse comments
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Apr  1 03:41:36 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 01:41:36 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1270086096.54.0.545030394526.issue8218@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There's also an invalid link to an image just after the title "The low-level view":
-.. .. image:: http.png
+.. image:: http.png

The image is not there though, and in r66294 only the document has been added.

----------

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

From report at bugs.python.org  Thu Apr  1 03:44:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Apr 2010 01:44:11 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1270086251.75.0.807144098508.issue8218@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is a reST comment.

----------

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

From report at bugs.python.org  Thu Apr  1 03:47:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 01:47:17 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1270086437.56.0.502392063855.issue8218@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If the image is missing, then the whole line can be removed.

----------

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

From report at bugs.python.org  Thu Apr  1 03:49:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Apr 2010 01:49:24 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1270086564.58.0.27881211841.issue8218@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is there a main author for this fileN? If so, they can say whether they left the link as a reminder to put the image back later, or if they were just afraid of real version control <0.4 wink>

----------

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

From report at bugs.python.org  Thu Apr  1 03:52:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 01:52:11 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1270086731.42.0.0972664572716.issue8218@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The author is Marek Kubica, but he doesn't seem to be registered to this tracker.

----------

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

From report at bugs.python.org  Thu Apr  1 04:03:15 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Apr 2010 02:03:15 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270087395.87.0.959687345951.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

One last issue to solve before this goes in and I start the backport...test_tarfile.test_extract_hardlink is intermittently failing for me, which was an issue for Eric and I on an earlier version of Jason's patch. Sometimes it fails when run as a part of the whole test suite, and then it'll pass when run by itself. Thoughts, anyone? I've spent some time on it and I'm not sure what I'm missing.

----------

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

From report at bugs.python.org  Thu Apr  1 04:35:04 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 01 Apr 2010 02:35:04 +0000
Subject: [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: <1270089304.84.0.082734892182.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm attaching a new version of the patch (v5), against svn trunk (r79517)

I've been testing these hooks by using "gdb attach" to attach to real-world python programs.

When doing this with earlier versions of the hooks, gdb would pause for many seconds when printing some values (e.g. during a backtrace).  The issue was that "proxyval" scrapes the entire graph of python objects from the inferior process into gdb, and then prints it.  As well as being slow, this can be many pages of textual output.

To counter this, I've rewritten the pretty-printers to use a stream-based approach.  The various PyObjectPtr subclasses have a "write_repr" method that writes the represenation to a file-like object whilst they recurse.  I supply a file-like object "TruncatedStringIO", which raises an exception after a limit is reached: by default 1K of string data.  (some simple subclasses simply reuse repr(self.proxyval()) for this, but objects that can follow cross-references have their own write_repr implementation).

I've also rewritten frame handling: I eliminated the FrameInfo class, moving its functionality to the PyFrameObjectPtr class, and introduced a new "Frame" class to wrap gdb.Frame.  This allowed a big simplification of the extension commands, and fixed various bugs (involving inlining and optimization)

Within the py-up/py-down and py-bt commands, the code now prefixes Python frame printing with C-level frame indexes, to better tie together the C-level and Python-level views of the stack.

I've added a couple of new commands:
  * "py-print" - takes a string argument.  It attempts to look up the Python variable with that name, and print its value  (it searches first in the locals of the current frame, then globals, then builtins).
  * "py-locals" - prints Python local variables; an analog of gdb's "info locals"

Other changes since v4:
  * Add a ">" marker to the output of "py-list", indicating the current location
  * Add pretty-printer for PyCFunctionObject ("built-in function" and "built-in method")
  * Add selftests for the above
  * Make frame printing fetch information on locals on demand, rather than within FrameInfo's __init__ method (the latter is completely gone)
  * Introduce PyObjectPtr.pyop_field method, simplifying the code
  * Change the set/frozenset selftests to remove a reliance on ordering within the representation of the members
  * Try to be more robust for the case where PyEval_EvalFrameEx's "f" parameter is optimized out (see https://bugzilla.redhat.com/show_bug.cgi?id=556975 )
  * Remove the FIXME in PyLongObjectPtr: I've tested the code on builds with both sizeof(digit) == 2 and == 4
  * More selftests for unicode printing

All tests pass on my box (Fedora 12 x86_64 with gdb-7.0.1-33.fc12.x86_64): "Ran 45 tests in 17.439s"

----------
Added file: http://bugs.python.org/file16715/add-gdb7-python-hooks-to-trunk-v5.patch

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

From report at bugs.python.org  Thu Apr  1 04:37:27 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 01 Apr 2010 02:37:27 +0000
Subject: [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: <1270089447.6.0.536492642352.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Adding diff from v4 to v5, for ease of review.

For my reference, md5sum of v5's hooks:
d3e039bb1279e71e847cc7ade10d3272  python-gdb.py

----------
Added file: http://bugs.python.org/file16716/diff-of-gdb7-hooks-v5-relative-to-v4.diff

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

From report at bugs.python.org  Thu Apr  1 04:55:28 2010
From: report at bugs.python.org (Dan Dever)
Date: Thu, 01 Apr 2010 02:55:28 +0000
Subject: [issue7885] test_distutils fails if Python built in separate directory
In-Reply-To: <1265647953.87.0.513905112062.issue7885@psf.upfronthosting.co.za>
Message-ID: <1270090528.57.0.609480680286.issue7885@psf.upfronthosting.co.za>


Dan Dever <dedded at verizon.net> added the comment:

Adding version 2.6

This fails for me with 2.6.5 in the same way.

----------
nosy: +dedded
versions: +Python 2.6

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

From report at bugs.python.org  Thu Apr  1 05:19:33 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 03:19:33 +0000
Subject: [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: <1270091973.22.0.435495612508.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

@lemburg: "failing byte" seems rather obvious: first byte that you meet that is not valid in the current state. I don't understand your explanation, especially "does not have the high bit set". I think you mean "is a valid starter byte". See example 3 below.

Example 1: F1 80 41 42 43. F1 implies a 4-byte character. 80 is OK. 41 is not in 80-BF. It is the "failing byte"; high bit not set. Required action is to emit FFFD then resync on the 41, causing 0041 0042 0043 to be emitted. Total output: FFFD 0041 0042 0043. Current code emits FFFD 0043.

Example 2: F1 80 FF 42 43. F1 implies a 4-byte character. 80 is OK. FF is not in 80-BF. It is the "failing byte". Required action is to emit FFFD then resync on the FF. FF is not a valid starter byte, so emit FFFD, and resync on the 42, causing 0042 0043 to be emitted. Total output: FFFD FFFD 0042 0043. Current code emits FFFD 0043.

Example 3: F1 80 C2 81 43. F1 implies a 4-byte character. 80 is OK. C2 is not in 80-BF. It is the "failing byte". Required action is to emit FFFD then resync on the C2. C2 and 81 have the high bit set, but C2 is a valid starter byte, and remaining bytes are OK, causing 0081 0043 to be emitted. Total output: FFFD 0081 0043. Current code emits FFFD 0043.

----------

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

From report at bugs.python.org  Thu Apr  1 05:28:29 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 03:28:29 +0000
Subject: [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: <1270092509.14.0.769375033438.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Having the 'high bit set' means that the first bit is set to 1.
All the continuation bytes (i.e. the 2nd, 3rd or 4th byte in a sequence) have the first two bits set to 1 and 0 respectively, so if the first bit is not set to 1 then the byte shouldn't be considered part of the sequence.
I'm trying to work on a patch.

----------

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

From report at bugs.python.org  Thu Apr  1 06:43:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 04:43:51 +0000
Subject: [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: <1270097031.65.0.0391134815921.issue8271@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Thu Apr  1 08:09:01 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 06:09:01 +0000
Subject: [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: <1270102141.43.0.916956714929.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

@ezio.melotti: Your second sentence is true, but it is not the whole truth. Bytes in the range C0-FF (whose high bit *is* set) ALSO shouldn't be considered part of the sequence because they (like 00-7F) are invalid as continuation bytes; they are either starter bytes (C2-F4) or invalid for any purpose (C0-C2 and F5-FF). Further, some bytes in the range 80-BF are NOT always valid as the first continuation byte, it depends on what starter byte they follow.

The simple way of summarising the above is to say that a byte that is not a valid continuation byte in the current state ("failing byte") is not a part of the current (now known to be invalid) sequence, and the decoder must try again ("resync") with the failing byte.

Do you agree with my example 3?

----------

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

From report at bugs.python.org  Thu Apr  1 08:14:56 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 06:14:56 +0000
Subject: [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: <1270102496.1.0.827137476515.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Yes, right now I'm considering valid all the bytes that start with '10...'. C2 starts with '11...' so it's a "failing byte".

----------

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

From report at bugs.python.org  Thu Apr  1 09:29:47 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 07:29:47 +0000
Subject: [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: <1270106987.33.0.884133439023.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

#ezio.melotti: """I'm considering valid all the bytes that start with '10...'"""

Sorry, WRONG. Read what I wrote: """Further, some bytes in the range 80-BF are NOT always valid as the first continuation byte, it depends on what starter byte they follow."""

Consider these sequences: (1) E0 80 80 (2) E0 9F 80. Both are invalid sequences (over-long). Specifically the first continuation byte may not be in 80-9F. Those bytes start with '10...' but they are invalid after an E0 starter byte.

Please read "Table 3-7. Well-Formed UTF-8 Byte Sequences" and surrounding text in Unicode 5.2.0 chapter 3 (bearing in mind that CPython (for good reasons) doesn't implement the surrogates restriction, so that the special case for starter byte ED is not used in CPython). Note the other 3 special cases for the first continuation byte.

----------

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

From report at bugs.python.org  Thu Apr  1 09:33:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 07:33:51 +0000
Subject: [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: <1270107231.55.0.498319675442.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That's why I'm writing tests that cover all the cases, including overlong sequences. If the test will fail I'll change the patch :)

----------

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

From report at bugs.python.org  Thu Apr  1 09:44:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 07:44:15 +0000
Subject: [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: <1270107855.48.0.452383245639.issue8032@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. I have committed it as r79548, with two modifications:
- I added a future import for with_statement, as many installations will still use Python 2.5
- I commented out many of the tests, as they were failing for me. I'll report those as several issues.

Please understand that this commit went to the trunk, which will be 2.7. After 2.7b1, no new features are acceptable, so you can only perform bug fixes on the code that is now committed. Please create new issues for any such bug fixes.

Once the tests all pass, I'll merge this into 3.2.

----------

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

From report at bugs.python.org  Thu Apr  1 09:44:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 07:44:23 +0000
Subject: [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: <1270107863.0.0.571651648372.issue8032@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Thu Apr  1 09:44:50 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Apr 2010 07:44:50 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270091973.22.0.435495612508.issue8271@psf.upfronthosting.co.za>
Message-ID: <4BB44EED.2010300@egenix.com>


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

John Machin wrote:
> 
> John Machin <sjmachin at users.sourceforge.net> added the comment:
> 
> @lemburg: "failing byte" seems rather obvious: first byte that you meet that is not valid in the current state. I don't understand your explanation, especially "does not have the high bit set". I think you mean "is a valid starter byte". See example 3 below.

I just had a quick look at the code and saw that it's testing for the high
bit on the subsequent bytes.

Looking closer, you're right and the situation is a bit more complex,
but the solution still looks simple: only the endinpos
has to be adjusted more carefully depending on what the various
checks find.

That said, I find the Unicode consortium solution a bit awkward.
In UTF-8 the first byte in a multi-byte sequence defines the number
of bytes that make up a sequence. If some of those bytes are invalid,
the whole sequence is invalid and the fact that some of those
bytes may be interpretable as regular code points does not necessarily
result in better results - the reason is that loss of bytes in a
stream is far more unlikely than flipping a few bits in the data.

----------
title: str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 -> str.decode('utf8',	'replace') -- conformance with Unicode 5.2.0

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

From report at bugs.python.org  Thu Apr  1 09:46:06 2010
From: report at bugs.python.org (Ramin Sabet)
Date: Thu, 01 Apr 2010 07:46:06 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>


New submission from Ramin Sabet <ramin.sabet at gmail.com>:

Error Message is:
OverflowError: long int too large to convert to int
---
Python Version:
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
---
Sample Code attached.

----------
components: IO
files: utime_test.py
messages: 102069
nosy: Ramin.Sabet
severity: normal
status: open
title: os.utime doesn't allow a atime (Last Access) which is 27 years in the future.
versions: Python 2.6
Added file: http://bugs.python.org/file16717/utime_test.py

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

From report at bugs.python.org  Thu Apr  1 09:47:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 07:47:41 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>


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

regrtest reports

======================================================================
FAIL: test_basic_command (test.test_gdb.PyListTests)                  
Verify that the "py-list" command works                               
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 518, in test_basic_command
    cmds_after_breakpoint=['py-list'])                                             
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace   
    self.assertEquals(err, '')
AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 535, in test_one_abs_arg
    cmds_after_breakpoint=['py-list 9'])
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 548, in test_two_abs_args
    cmds_after_breakpoint=['py-list 1,3'])
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

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

----------
assignee: dmalcolm
messages: 102070
nosy: dmalcolm, loewis
severity: normal
status: open
title: python-gdb PyListTests fail

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

From report at bugs.python.org  Thu Apr  1 09:49:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 07:49:28 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270108168.3.0.935977082988.issue8279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The other failures look similar, so I'm not reporting them separately for now.

----------

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

From report at bugs.python.org  Thu Apr  1 09:58:27 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Apr 2010 07:58:27 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270108707.92.0.327934296449.issue8193@psf.upfronthosting.co.za>


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

The "I'm not sure" in my comment really was a question, rather than a definite direction to conditionally retain the old test.

I've actually looked at the relevant C code in the zlib module now, and I agree with Antoine that the original suggestion of changing the 0 in the test to a -1 is fine (the test is just checking the handling of a Z_STREAM_ERROR return from the API call rather than anything more sophisticated).

Adding to my to-do list.

----------
assignee:  -> ncoghlan

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

From report at bugs.python.org  Thu Apr  1 10:08:25 2010
From: report at bugs.python.org (Valerio)
Date: Thu, 01 Apr 2010 08:08:25 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270109305.17.0.0629087206828.issue8193@psf.upfronthosting.co.za>


Changes by Valerio <turturici.valerio at gmail.com>:


Removed file: http://bugs.python.org/file16711/8193.patch

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

From report at bugs.python.org  Thu Apr  1 10:08:59 2010
From: report at bugs.python.org (Valerio)
Date: Thu, 01 Apr 2010 08:08:59 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270109339.6.0.230151754902.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

Ok, so here the patch.

----------
Added file: http://bugs.python.org/file16718/8193.patch

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

From report at bugs.python.org  Thu Apr  1 10:18:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 08:18:20 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1270109900.82.0.755057923107.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Other py3k warnings:

lib\distutils\util.py:209: DeprecationWarning: apply() not supported in 3.x; use func(*args, **kwargs)
  return apply(os.path.join, paths)

lib\distutils\command\build_ext.py:679: DeprecationWarning: apply() not supported in 3.x; use func(*args, **kwargs)
  return apply(os.path.join, ext_path) + '_d' + so_ext

lib\platform.py:1035: DeprecationWarning: dict.has_key() not supported in 3.x; use the in operator
  if _default_architecture.has_key(sys.platform):

----------

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

From report at bugs.python.org  Thu Apr  1 10:31:09 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 01 Apr 2010 08:31:09 +0000
Subject: [issue8228] pprint, single/multiple items per line parameter
In-Reply-To: <1269497760.71.0.432450737837.issue8228@psf.upfronthosting.co.za>
Message-ID: <1270110669.07.0.365820462437.issue8228@psf.upfronthosting.co.za>


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

Please generate patches with "context diff", or better "unified diff", with the "diff -u" command.
I've done it, before the source code changes and the patch becomes impossible to apply.

Note that the new version does not respect the width:
len(pprint.pformat([1]*100).splitlines()[0]) == 81

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file16719/issue_8228.patch

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

From report at bugs.python.org  Thu Apr  1 10:33:47 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 08:33:47 +0000
Subject: [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: <1270110827.02.0.3072878206.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is an incomplete patch. It seems to solve the problem but I still have to add more tests and check it better.
I also wonder if the sequences with the first byte in range F5-FD (start of 4/5/6-byte sequences, restricted by RFC 3629) should behave in the same way. Right now they just "eat" the following 4/5/6 chars without checking.

----------
keywords: +patch
Added file: http://bugs.python.org/file16720/issue8271.diff

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

From report at bugs.python.org  Thu Apr  1 10:46:34 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Apr 2010 08:46:34 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270110827.02.0.3072878206.issue8271@psf.upfronthosting.co.za>
Message-ID: <4BB45D66.5080404@egenix.com>


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

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Here is an incomplete patch. It seems to solve the problem but I still have to add more tests and check it better.

Thanks. Please also check whether it's worthwhile unrolling those
loops by hand.

> I also wonder if the sequences with the first byte in range F5-FD (start of 4/5/6-byte sequences, restricted by RFC 3629) should behave in the same way. Right now they just "eat" the following 4/5/6 chars without checking.

I think we need to do this all the way, even though 5 and 6 byte
sequences are not used at the moment.

----------

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

From report at bugs.python.org  Thu Apr  1 11:01:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 01 Apr 2010 09:01:51 +0000
Subject: [issue8277] ElementTree won't parse comments
In-Reply-To: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>
Message-ID: <1270112511.48.0.571492825321.issue8277@psf.upfronthosting.co.za>


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

ElementTree does parse comments, it just omit them in the tree.
A quick search lead me to this page: http://effbot.org/zone/element-pi.htm
which can be further simplified:

from xml.etree import ElementTree
class MyTreeBuilder(ElementTree.TreeBuilder):
   def comment(self, data):
       self.start(ElementTree.Comment, {})
       self.data(data)
       self.end(ElementTree.Comment)
with open('c:/temp/t.xml', 'r') as f:
   xml = ElementTree.parse(
       f, parser=ElementTree.XMLParser(target=MyTreeBuilder()))
ElementTree.dump(xml)


Now, should ElementTree do this by default? It's not certain, see how effbot's sample needs to wrap the entire file into another 'document' element.

----------
nosy: +amaury.forgeotdarc, effbot

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

From report at bugs.python.org  Thu Apr  1 11:29:00 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Thu, 01 Apr 2010 09:29:00 +0000
Subject: [issue8228] pprint, single/multiple items per line parameter
In-Reply-To: <1269497760.71.0.432450737837.issue8228@psf.upfronthosting.co.za>
Message-ID: <1270114140.58.0.617386057817.issue8228@psf.upfronthosting.co.za>


Dmitry Chichkov <dchichkov at gmail.com> added the comment:

Yes. This patch is nowhere near the production level. Unfortunately it works for me. And in the moment I don't have time to improve it further. Current version doesn't check the item's width upfront, there is definitely room for improvement. 

There is also an issue with the included issue_5131.patch - pretty-printed code can not be executed, unless 'defaultdict(' ')' type-specs are removed.

----------

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

From report at bugs.python.org  Thu Apr  1 12:29:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 01 Apr 2010 10:29:27 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1270117767.38.0.780185197164.issue8278@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Apr  1 12:55:14 2010
From: report at bugs.python.org (David Chambers)
Date: Thu, 01 Apr 2010 10:55:14 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1270119314.66.0.353276479542.issue7132@psf.upfronthosting.co.za>


David Chambers <david.chambers.05 at gmail.com> added the comment:

I would find this functionality very useful. While I agree that it's often simpler to extract the relevant information in several steps, there are situations in which I'd prefer to do it all in one go.

The application I'm writing at the moment needs to extract metadata from text files. This metadata actually appears as text at the top of each file. For example:

title: Example title
tags: Django, Python, regular expressions

Example title
=============

Here is the first paragraph.

I had expected something like this to get the job done:

meta = re.match(r'(?ms)(?:^(\S+):\s*(.*?)$\n)+^\s*$', contents_of_file)

Ideally in this case, meta.groups() would return:

('title', 'Example title', 'tags', 'Django, Python, regular expressions')

----------
nosy: +davidchambers

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

From report at bugs.python.org  Thu Apr  1 13:05:53 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 01 Apr 2010 11:05:53 +0000
Subject: [issue1044] tarfile insecure pathname extraction
In-Reply-To: <1188295764.62.0.164889561412.issue1044@psf.upfronthosting.co.za>
Message-ID: <1270119953.14.0.295922434339.issue1044@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +doko

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

From report at bugs.python.org  Thu Apr  1 13:16:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:16:54 +0000
Subject: [issue4577] distutils: -3 warnings (apply)
In-Reply-To: <1228670407.71.0.141400636121.issue4577@psf.upfronthosting.co.za>
Message-ID: <1270120614.66.0.421784791807.issue4577@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Superseded by #7092

----------
nosy: +flox
resolution:  -> out of date
status: open -> closed
superseder:  -> Test suite emits many DeprecationWarnings when -3 is enabled
type: compile error -> behavior
versions: +Python 2.7

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

From report at bugs.python.org  Thu Apr  1 13:26:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:26:16 +0000
Subject: [issue1613130] str.split creates new string even if pattern not found
Message-ID: <1270121176.39.0.68832081284.issue1613130@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with #7622, and USE_FAST flag removed.

----------
nosy: +flox
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Apr  1 13:26:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:26:43 +0000
Subject: [issue1613130] str.split creates new string even if pattern not found
Message-ID: <1270121203.16.0.332453775635.issue1613130@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
superseder:  -> [patch] improve unicode methods: split() rsplit() and replace()

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

From report at bugs.python.org  Thu Apr  1 13:35:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:35:54 +0000
Subject: [issue5290] subprocess.Popen.communicate does not encode unicode
	strings
In-Reply-To: <1234859144.87.0.49854960463.issue5290@psf.upfronthosting.co.za>
Message-ID: <1270121754.15.0.888682759826.issue5290@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

AFAICT 2.6 and 2.7 behave correctly.

----------
nosy: +flox
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Apr  1 13:44:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:44:22 +0000
Subject: [issue5447] future unicode literals and r'\u'
In-Reply-To: <1236543092.99.0.796172268474.issue5447@psf.upfronthosting.co.za>
Message-ID: <1270122262.99.0.536692931383.issue5447@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Duplicate of #2570.

----------
nosy: +flox
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Thu Apr  1 13:45:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:45:37 +0000
Subject: [issue5447] future unicode literals and r'\u'
In-Reply-To: <1236543092.99.0.796172268474.issue5447@psf.upfronthosting.co.za>
Message-ID: <1270122337.83.0.21359262901.issue5447@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
superseder:  -> backport 3.0-style \u/\U processing in raw strings when unicode_literals is imported from __future__

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

From report at bugs.python.org  Thu Apr  1 13:46:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:46:27 +0000
Subject: [issue2570] backport 3.0-style \u/\U processing in raw strings when
	unicode_literals is imported from __future__
In-Reply-To: <1207592942.81.0.864010115323.issue2570@psf.upfronthosting.co.za>
Message-ID: <1270122387.47.0.972814375626.issue2570@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords:  -26backport
nosy: +benjamin.peterson, flox, pooryorick, zhirsch

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

From report at bugs.python.org  Thu Apr  1 13:57:02 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 11:57:02 +0000
Subject: [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: <1270123022.09.0.351284182872.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Unicode has been frozen at 0x10FFFF. That's it. There is no such thing as a valid 5-byte or 6-byte UTF-8 string.

----------

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

From report at bugs.python.org  Thu Apr  1 13:58:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 11:58:26 +0000
Subject: [issue1498930] Generate from Unicode database instead of manualy
	coding.
Message-ID: <1270123106.82.0.641869175364.issue1498930@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with #1571184.

----------
nosy: +flox
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Generate numeric/space/linebreak from Unicode database.

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

From report at bugs.python.org  Thu Apr  1 14:02:35 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 01 Apr 2010 12:02:35 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1270123355.34.0.146210893617.issue6488@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

> As per PEP 257, ?Returns? should become ?Return? (it?s a command, not a description).

Upstream ET uses JavaDoc conventions, where the conventions are
designed by technical writers, not hackers.  In JavaDoc, descriptions
are 3rd person declarative (after all, the documentation describes
what the function does, not what you want it to do).

http://java.sun.com/j2se/javadoc/writingdoccomments/

The incompatibilities with Python's NIH-standards are unfortunate, but
that's the way it is.

----------

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

From report at bugs.python.org  Thu Apr  1 14:20:53 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 01 Apr 2010 12:20:53 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1270124453.57.0.0246734029783.issue6488@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

The missing/extra words in the findtext description is just a case of sloppy copy-editing, most likely after a quick reformatting.  Not sure why you're spending all this energy arguing about commas, though.

----------

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

From report at bugs.python.org  Thu Apr  1 14:59:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 12:59:56 +0000
Subject: [issue7583] [patch] doctest should normalize tabs when comparing
	output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270126796.97.0.122074050142.issue7583@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file16721/issue7583.doctest.tabs.diff

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

From report at bugs.python.org  Thu Apr  1 15:00:20 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 13:00:20 +0000
Subject: [issue7583] [patch] doctest should normalize tabs when comparing
	output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270126820.5.0.283577085424.issue7583@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Removed file: http://bugs.python.org/file16712/issue7583.doctest.tabs.diff

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

From report at bugs.python.org  Thu Apr  1 15:05:18 2010
From: report at bugs.python.org (Josip Djolonga)
Date: Thu, 01 Apr 2010 13:05:18 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1270127118.38.0.826457615698.issue8254@psf.upfronthosting.co.za>


Changes by Josip Djolonga <jdzolonga at gmail.com>:


----------
nosy: +josip

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

From report at bugs.python.org  Thu Apr  1 15:19:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Apr 2010 13:19:05 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270123022.09.0.351284182872.issue8271@psf.upfronthosting.co.za>
Message-ID: <4BB49D46.7010209@egenix.com>


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

John Machin wrote:
> 
> John Machin <sjmachin at users.sourceforge.net> added the comment:
> 
> Unicode has been frozen at 0x10FFFF. That's it. There is no such thing as a valid 5-byte or 6-byte UTF-8 string.

The UTF-8 codec was written at a time when UTF-8 still included
the possibility to have 5 or 6 bytes:

http://www.rfc-editor.org/rfc/rfc2279.txt

Use of those encodings has always raised an error, though. For error
handling purposes it still has to support those possibilities.

----------

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

From report at bugs.python.org  Thu Apr  1 15:35:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Apr 2010 13:35:26 +0000
Subject: [issue8277] ElementTree won't parse comments
In-Reply-To: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>
Message-ID: <1270128926.31.0.790037361381.issue8277@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +flox

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

From report at bugs.python.org  Thu Apr  1 15:47:38 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 13:47:38 +0000
Subject: [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: <1270129658.49.0.127634285615.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

@lemburg: RFC 2279 was obsoleted by RFC 3629 over 6 years ago. The standard now says 21 bits is it. F5-FF are declared to be invalid. I don't understand what you mean by "supporting those possibilities". The code is correctly issuing an error message. The goal of supporting the new resyncing and FFFD-emitting rules might be better met however by throwing away the code in the default clause and instead merely setting the entries for F5-FF in the utf8_code_length array to zero.

----------

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

From report at bugs.python.org  Thu Apr  1 16:10:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 14:10:04 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1270131004.82.0.785558548324.issue6703@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Sure doctests should be crossplatform by default when possible. The patch should fix the behavior for windows. It also cleans the doc and code a bit.

Can you provide some testcases?

----------
keywords: +patch
nosy: +techtonik
Added file: http://bugs.python.org/file16722/6703.silly.abspath.test.diff

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

From report at bugs.python.org  Thu Apr  1 16:12:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 14:12:51 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1270131171.33.0.839791363274.issue6703@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

http://codereview.appspot.com/815042/show

----------

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

From report at bugs.python.org  Thu Apr  1 16:13:01 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Apr 2010 14:13:01 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270129658.49.0.127634285615.issue8271@psf.upfronthosting.co.za>
Message-ID: <4BB4A9EA.7010005@egenix.com>


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

John Machin wrote:
> 
> John Machin <sjmachin at users.sourceforge.net> added the comment:
> 
> @lemburg: RFC 2279 was obsoleted by RFC 3629 over 6 years ago. 

I know.

> The standard now says 21 bits is it. 

It says that the current Unicode codespace only uses 21 bits. In the
early days 16 bits were considered enough, so it wouldn't surprise me,
if they extend that range again at some point in the future - after
all, leaving 11 bits unused in UCS-4 is a huge waste of space.

If you have a reference that the Unicode consortium has decided
to stay with that limit forever, please quote it.

> F5-FF are declared to be invalid. I don't understand what you mean by "supporting those possibilities". The code is correctly issuing an error message. The goal of supporting the new resyncing and FFFD-emitting rules might be better met however by throwing away the code in the default clause and instead merely setting the entries for F5-FF in the utf8_code_length array to zero.

Fair enough. Let's do that.

The reference in the table should then be updated to RFC 3629.

----------

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

From report at bugs.python.org  Thu Apr  1 16:43:24 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 14:43:24 +0000
Subject: [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: <1270133004.19.0.674258327128.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Patch review:

Preamble: pardon my ignorance of how the codebase works, but trunk unicodeobject.c is r79494 (and allows encoding of surrogate codepoints), py3k unicodeobject.c is r79506 (and bans the surrogate caper) and I can't find the r79542 that the patch mentions ... help, please!

length 2 case: 
1. the loop can be hand-unrolled into oblivion. It can be entered only when s[1] & 0xC0 != 0x80 (previous if test).
2. the over-long check (if (ch < 0x80)) hasn't been touched. It could be removed and the entries for C0 and C1 in the utf8_code_length array set to 0.

length 3 case:
1. the tests involving s[0] being 0xE0 or 0xED are misplaced.
2. the test s[0] == 0xE0 && s[1] < 0xA0 if not misplaced would be shadowing the over-long test (ch < 0x800). It seems better to use the over-long test (with endinpos set to 1).
3. The test s[0] == 0xED relates to the surrogates caper which in the py3k version is handled in the same place as the over-long test.
4. unrolling loop: needs no loop, only 1 test ... if s[1] is good, then we know s[2] must be bad without testing it, because we start the for loop only when s[1] is bad || s[2] is bad.

length 4 case: as for the len 3 case generally ... misplaced tests, F1 test shadows over-long test, F4 test shadows max value test, too many loop iterations.

----------

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

From report at bugs.python.org  Thu Apr  1 16:50:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Apr 2010 14:50:13 +0000
Subject: [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: <1270133413.07.0.728583781422.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Even if they are not valid they still "eat" all the 4/5/6 bytes, so they should be fixed too. I haven't see anything about these bytes in chapter 3 so far, but there are at least two possibilities:
1) consider all the bytes in range F5-FD as invalid without looking for the other bytes;
2) try to read the next 4/5/6 bytes and fail if they are no continuation bytes.
We can also look at what others do (e.g. browsers and other languages).

----------

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

From report at bugs.python.org  Thu Apr  1 16:51:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Apr 2010 14:51:53 +0000
Subject: [issue7583] doctest should normalize tabs when comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270133513.28.0.648687373761.issue7583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Removed [patch] from title as patch is set on the keywords.  Removed 2.5 from versions because it is in security fix only mode (we use versions for where things will be fixed, not where they are broken).  Changed component to Library as this is not a bug in the tests themselves but in a library package, doctest.

I didn't set stage to patch review only because I'd like other opinions on the root issue.  Normalizing tabs to 8 spaces sounds wrong to me (including in the source).

----------
components: +Library (Lib) -Tests
nosy: +r.david.murray
priority:  -> normal
title: [patch] doctest should normalize tabs when comparing output -> doctest should normalize tabs when comparing output
type:  -> behavior
versions:  -Python 2.5

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

From report at bugs.python.org  Thu Apr  1 16:55:34 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 14:55:34 +0000
Subject: [issue7583] doctest should normalize tabs when comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270133734.79.0.875953482484.issue7583@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

http://docs.python.org/library/doctest.html#how-are-docstring-examples-recognized

"Changed in version 2.4: Expanding tabs to spaces is new; previous versions tried to preserve hard tabs, with confusing results"

Unfortunately, no confusing results survived to see what was wrong.

----------

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

From report at bugs.python.org  Thu Apr  1 16:57:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Apr 2010 14:57:16 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270133836.52.0.370835411403.issue7585@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +doctest should normalize tabs when comparing output
title: [patch] difflib should separate filename from timestamp with tab -> difflib should separate filename from timestamp with tab

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

From report at bugs.python.org  Thu Apr  1 17:01:39 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Apr 2010 15:01:39 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270133413.07.0.728583781422.issue8271@psf.upfronthosting.co.za>
Message-ID: <4BB4B54E.6060408@egenix.com>


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

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Even if they are not valid they still "eat" all the 4/5/6 bytes, so they should be fixed too. I haven't see anything about these bytes in chapter 3 so far, but there are at least two possibilities:
> 1) consider all the bytes in range F5-FD as invalid without looking for the other bytes;
> 2) try to read the next 4/5/6 bytes and fail if they are no continuation bytes.
> We can also look at what others do (e.g. browsers and other languages).

By marking those entries as 0 in the length table, they would only
use one byte, however, compared to the current state, that would
produce more replacement code points in the output, so perhaps applying
the same logic as for the other sequences is a better strategy.

----------

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

From report at bugs.python.org  Thu Apr  1 17:07:08 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 15:07:08 +0000
Subject: [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: <1270134428.79.0.365637719195.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Chapter 3, page 94: """As a consequence of the well-formedness conditions specified in Table 3-7, the following byte values are disallowed in UTF-8: C0?C1, F5?FF"""

Of course they should be handled by the simple expedient of setting their length entry to zero. Why write code when there is an existing mechanism??

----------

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

From report at bugs.python.org  Thu Apr  1 17:09:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Apr 2010 15:09:59 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270134599.02.0.286171822833.issue8276@psf.upfronthosting.co.za>


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

Right, we can certainly suppress the function definition now and just keep the macro.
(especially given it's 1997, not 2007, there was a typo in my message)

----------
assignee:  -> pitrou
priority:  -> normal
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.2

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

From report at bugs.python.org  Thu Apr  1 17:23:23 2010
From: report at bugs.python.org (John Machin)
Date: Thu, 01 Apr 2010 15:23:23 +0000
Subject: [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: <1270135403.73.0.139390730316.issue8271@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

@lemburg: """perhaps applying the same logic as for the other sequences is a better strategy"""

What other sequences??? F5-FF are invalid bytes; they don't start valid sequences. What same logic?? At the start of a character, they should get the same short sharp treatment as any other non-starter byte e.g. 80 or C0.

----------

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

From report at bugs.python.org  Thu Apr  1 17:53:09 2010
From: report at bugs.python.org (Josip Djolonga)
Date: Thu, 01 Apr 2010 15:53:09 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1270137189.1.0.991603710815.issue8255@psf.upfronthosting.co.za>


Changes by Josip Djolonga <jdzolonga at gmail.com>:


----------
nosy: +josip

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

From report at bugs.python.org  Thu Apr  1 18:05:29 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 01 Apr 2010 16:05:29 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270137929.78.0.467755915831.issue8279@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks for reviewing the gdb work.

I was mistakenly testing using:
   make ; ./python Lib/test/test_gdb.py

which led to path assumptions in the code.

I'm now testing with:
   make ; ./python Lib/test/regrtest.py -v test_gdb

I'm attaching a patch which uses test_support.findfile to locate the test script; the code now works when invoked using either of the above:

$ ./python Lib/test/regrtest.py test_gdb
test_gdb
1 test OK.
[39894 refs]

There was also some breakage of the PyListTests due to significant trailing whitespace within the multiline string containing the expected result.  The trailing whitespace was stripped in test_gdb.py.  I've rewritten these multiline string literals as adjacent single-line string literals, so that this significant whitespace is explicit.  (The output of each line has the line number, then four spaces, then the content of the line from the source file.  An empty source line thus has the number followed by four trailing spaces.)

I've also slightly changed the regex in get_gdb_repr() that carves up what GDB prints, since gdb can insert newlines and spaces in a somewhat arbitrary way, apparently based on the width of the tty that its stdout is connected to.  The tests were passing when run from a full-screen terminal, but some would fail if I resized the terminal to 80 columns (!).  I've tested the new code at both terminal sizes, and piping to "cat" (so that it's not at tty), and all tests now pass for all three cases.

----------
keywords: +patch
Added file: http://bugs.python.org/file16723/fix-test_gdb_sample-path-and-whitespace-issues.patch

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

From report at bugs.python.org  Thu Apr  1 18:07:08 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 01 Apr 2010 16:07:08 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270138028.12.0.382283061425.issue8279@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Thu Apr  1 18:08:33 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 01 Apr 2010 16:08:33 +0000
Subject: [issue8280] urllib2 passes fragment identifier to server
In-Reply-To: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>
Message-ID: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

>>> urllib2.urlopen("http://wave-robot-python-client.googlecode.com/svn/trunk/pydocs/index.html#module-wavelet")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\usr\Python2.6\lib\urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\usr\Python2.6\lib\urllib2.py", line 398, in open
    response = meth(req, response)
  File "C:\usr\Python2.6\lib\urllib2.py", line 511, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\usr\Python2.6\lib\urllib2.py", line 436, in error
    return self._call_chain(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 370, in _call_chain
    result = func(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 519, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Bad Request

This happens when redirected URL contains fragment.

>>> urllib2.urlopen("http://goo.gl/z1d5")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\usr\Python2.6\lib\urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\usr\Python2.6\lib\urllib2.py", line 398, in open
    response = meth(req, response)
  File "C:\usr\Python2.6\lib\urllib2.py", line 511, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\usr\Python2.6\lib\urllib2.py", line 430, in error
    result = self._call_chain(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 370, in _call_chain
    result = func(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 606, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "C:\usr\Python2.6\lib\urllib2.py", line 398, in open
    response = meth(req, response)
  File "C:\usr\Python2.6\lib\urllib2.py", line 511, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\usr\Python2.6\lib\urllib2.py", line 436, in error
    return self._call_chain(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 370, in _call_chain
    result = func(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 519, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Bad Request

urllib2.Request.get_selector() should be:

    def get_selector(self):
        return self.__r_host.split('#')[0]

----------
messages: 102103
nosy: naoki
severity: normal
status: open
title: urllib2 passes fragment identifier to server

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

From report at bugs.python.org  Thu Apr  1 18:09:24 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 01 Apr 2010 16:09:24 +0000
Subject: [issue8280] urllib2 passes fragment identifier to server
In-Reply-To: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>
Message-ID: <1270138164.66.0.448124469061.issue8280@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
components: +Library (Lib)
type:  -> behavior
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/issue8280>
_______________________________________

From report at bugs.python.org  Thu Apr  1 18:12:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Apr 2010 16:12:31 +0000
Subject: [issue8280] urllib2 passes fragment identifier to server
In-Reply-To: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>
Message-ID: <1270138351.5.0.57892252841.issue8280@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +orsenthil
versions:  -Python 2.5, Python 3.3

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

From report at bugs.python.org  Thu Apr  1 18:16:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Apr 2010 16:16:10 +0000
Subject: [issue8280] urllib2 passes fragment identifier to server
In-Reply-To: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>
Message-ID: <1270138570.1.0.90673529546.issue8280@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

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

From report at bugs.python.org  Thu Apr  1 18:44:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Apr 2010 16:44:56 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>


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

This doesn't happen in verbose mode, because stdout isn't checked:


$ ./python -m test.regrtest test_gdb_sample
test_gdb_sample
test test_gdb_sample produced unexpected output:
**********************************************************************
42

**********************************************************************
1 test failed:
    test_gdb_sample

----------
assignee: dmalcolm
components: Library (Lib), Tests
messages: 102104
nosy: dmalcolm, loewis, pitrou
severity: normal
stage: needs patch
status: open
title: test_gdb_sample fails
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  1 18:53:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Apr 2010 16:53:46 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270140826.39.0.260863655196.issue8276@psf.upfronthosting.co.za>


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

Fixed in r79555 (trunk), r79556 (py3k).

----------

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

From report at bugs.python.org  Thu Apr  1 18:53:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Apr 2010 16:53:54 +0000
Subject: [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270140834.52.0.631467981425.issue8276@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Apr  1 18:54:41 2010
From: report at bugs.python.org (cburroughs)
Date: Thu, 01 Apr 2010 16:54:41 +0000
Subject: [issue3073] Cookie.Morsel breaks in parsing cookie values with
	whitespace
In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za>
Message-ID: <1270140881.6.0.0504269112575.issue3073@psf.upfronthosting.co.za>


Changes by cburroughs <chris.burroughs at gmail.com>:


----------
nosy: +cburroughs

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

From report at bugs.python.org  Thu Apr  1 18:58:05 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 16:58:05 +0000
Subject: [issue1659] Tests needing network flag?
In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org>
Message-ID: <1270141085.79.0.697952656035.issue1659@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Updated patch.

    test_socket  - whole suite will be skipped
    test_socket_ssl - no more avail
    test_ssl     - only test that require network will be marked as skipped
    test_urllib2 - untouched, requires fine-grained approach, probably for separate ticket

----------
components: +Tests
keywords: +patch
nosy: +techtonik
versions: +Python 2.7
Added file: http://bugs.python.org/file16724/1659.no_network.diff

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

From report at bugs.python.org  Thu Apr  1 19:01:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 17:01:04 +0000
Subject: [issue1659] Tests needing network flag?
In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org>
Message-ID: <1270141264.33.0.74438164288.issue1659@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I propose to split this issue.

One is to test which tests that marked with `test_support.requires('network')` _really_ need network connection.

Second is annotation of appropriate methods instead of whole test suite to count exact number of tests skipped due to absent resource.

----------

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

From report at bugs.python.org  Thu Apr  1 19:13:11 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 01 Apr 2010 17:13:11 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1270141991.94.0.559037811144.issue8281@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Sorry about that.

"test_gdb_sample.py" is merely a sample script for use by "test_gdb.py" (see issue 8032); it's not intended to do anything useful by itself (though it does need a "print" invocation, since test_gdb.py uses a breakpoint in PyObject_Print).

I would probably be simplest to rename it so it doesn't have a "test_" prefix.

How about "sample_for_test_gdb.py", or somesuch?

----------

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

From report at bugs.python.org  Thu Apr  1 19:14:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 17:14:17 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1270142057.06.0.758289306134.issue8281@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords: +buildbot
priority:  -> normal

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

From report at bugs.python.org  Thu Apr  1 19:21:09 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 01 Apr 2010 17:21:09 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1270142469.03.0.267206005926.issue8278@psf.upfronthosting.co.za>


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

On Windows, time_t is 64bit, but various functions convert it to a 32bit long.
Attached patch uses time_t instead of long in various places, this fixes the proposed test.

Martin, do you think it's a viable approach? If so, I'll go and add some tests for the modified functions.

----------
keywords: +patch
nosy: +amaury.forgeotdarc, loewis
Added file: http://bugs.python.org/file16725/timet_64.patch

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

From report at bugs.python.org  Thu Apr  1 19:24:07 2010
From: report at bugs.python.org (Patrick W.)
Date: Thu, 01 Apr 2010 17:24:07 +0000
Subject: [issue8277] ElementTree won't parse comments
In-Reply-To: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>
Message-ID: <1270142647.82.0.567664076091.issue8277@psf.upfronthosting.co.za>


Patrick W. <poke at BornToLaugh.de> added the comment:

Thanks for your reply, Amaury. That page really might mean that it was not intended for ElementTree to parse such things by default. Although it might be nice if there was some easy way to simply enable it, instead of having to hack it into there and depending on details of some internal code (which might change in the future).

Your code btw. didn't work for me, but based on it and on that effbot page, I came up with the following solution, which works fine.

test.py
-------
from xml.etree import ElementTree

class CommentedTreeBuilder ( ElementTree.XMLTreeBuilder ):
    def __init__ ( self, html = 0, target = None ):
        ElementTree.XMLTreeBuilder.__init__( self, html, target )
        self._parser.CommentHandler = self.handle_comment
    
    def handle_comment ( self, data ):
        self._target.start( ElementTree.Comment, {} )
        self._target.data( data )
        self._target.end( ElementTree.Comment )


with open( 'test.xml', 'r' ) as f:
    xml = ElementTree.parse( f, parser = CommentedTreeBuilder() )
ElementTree.dump( xml )

----------

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

From report at bugs.python.org  Thu Apr  1 19:24:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Apr 2010 17:24:25 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270141991.94.0.559037811144.issue8281@psf.upfronthosting.co.za>
Message-ID: <1270142779.3423.6.camel@localhost>


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

> I would probably be simplest to rename it so it doesn't have a "test_" prefix.

Indeed. Otherwise it gets caught and executed by regrtest as part of the
standard test suite.

> How about "sample_for_test_gdb.py", or somesuch?

Shorter would be better :)
For example gdb_sample.py, gdb_fodder.py...

----------

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

From report at bugs.python.org  Thu Apr  1 19:29:23 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 01 Apr 2010 17:29:23 +0000
Subject: [issue8277] ElementTree won't parse comments
In-Reply-To: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>
Message-ID: <1270142963.96.0.380958505635.issue8277@psf.upfronthosting.co.za>


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

yes, my code uses the newer version of ElementTree which will be included with 2.7 and 3.2

----------

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

From report at bugs.python.org  Thu Apr  1 19:29:36 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 17:29:36 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270142976.66.0.263871338663.issue2810@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I propose to close this as "invalid", because the bug with _winreg.EnumValue can not be confirmed.

However, it seems to be impossible to return unicode data from _winreg.EnumKey, and this deserves a new bug.

----------
nosy: +techtonik
versions: +Python 2.7

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

From report at bugs.python.org  Thu Apr  1 19:32:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Apr 2010 17:32:01 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270143121.97.0.492217366229.issue2810@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Thu Apr  1 19:33:45 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 17:33:45 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270143225.9.0.712932975524.issue2810@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file16726/issue2810_registry.png

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

From report at bugs.python.org  Thu Apr  1 19:50:47 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 01 Apr 2010 17:50:47 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1270144247.17.0.111051770854.issue8281@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

"gdb_sample.py" as a name works for me.  I don't have commit rights to SVN so I can't perform the rename myself.

(Note that due to issue 8279 the file isn't actually used at the moment by test_gdb.py so it should be safe to rename.  I have a patch attached to that latter bug; I'll fix up the patch after that file is renamed).

----------

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

From report at bugs.python.org  Thu Apr  1 19:57:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Apr 2010 17:57:38 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1270144658.31.0.390325588419.issue8281@psf.upfronthosting.co.za>


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

> (Note that due to issue 8279 the file isn't actually used at the moment 
> by test_gdb.py so it should be safe to rename.  I have a patch attached 
> to that latter bug; I'll fix up the patch after that file is renamed).

Thank you, this is done in r79557.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Apr  1 19:59:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 17:59:23 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270144763.54.0.89639549052.issue3778@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Confirmed 2.6.5 installer leaves "HKLM\SOFTWARE\Python\PythonCore\2.6\Modules" on install/uninstall without \2.6\ key.

I propose to mark it as 'low' priority.

----------
nosy: +techtonik
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Apr  1 20:07:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 18:07:23 +0000
Subject: [issue8282] Windows uninstaller requests admin access for
	unindentified program
In-Reply-To: <1270145243.88.0.407783271533.issue8282@psf.upfronthosting.co.za>
Message-ID: <1270145243.88.0.407783271533.issue8282@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Uninstall on Vista requires administrative privileges to "Unindentified program" from "Unindentified publisher".

Tested 2.6.5 and 2.7a4

----------
components: Installation
messages: 102117
nosy: techtonik
severity: normal
status: open
title: Windows uninstaller requests admin access for unindentified program
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Apr  1 20:11:46 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 01 Apr 2010 18:11:46 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270145506.97.0.62524346511.issue8279@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm attaching a revised version of the patch; this is as before, but takes account of the rename of the sample file from "test_gdb_sample.py" to "gdb_sample.py" in r79557.

----------
Added file: http://bugs.python.org/file16727/fix-test_gdb_sample-path-and-whitespace-issues-changing-sample-filename.patch

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

From report at bugs.python.org  Thu Apr  1 20:18:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Apr 2010 18:18:57 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1270145937.03.0.881925995695.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79558, except test_multiprocessing.

----------

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

From report at bugs.python.org  Thu Apr  1 20:26:02 2010
From: report at bugs.python.org (alan hoover)
Date: Thu, 01 Apr 2010 18:26:02 +0000
Subject: [issue8283] series of lamdas in loop sets the paramater on all calls
	to that of the last call
In-Reply-To: <1270146362.25.0.403939205554.issue8283@psf.upfronthosting.co.za>
Message-ID: <1270146362.25.0.403939205554.issue8283@psf.upfronthosting.co.za>


New submission from alan hoover <alan.hoover at gmail.com>:

Background:
building a screen using Tkinter based on information from a database to let user take action on the database rows.  I don't know how many rows there will be, so I'm storing the widgets in arrays for each column.

Code:
for row in getDBrows():
    self.buttons.append(Tkinter.Button(self,text='UnLoad it', command=lambda :self.unload(row[0])))

Problem:
When executing the above code, all the buttons have the key to the database table that belongs to the last row.  I found a work around -- by moving the call to create the button (containing the lambda) to a separate function and call that function to create the button instead of creating the button directly, the buttons then make their callback with a correct database key.

Workaround:
for row in getDBrows():
    self.buttons.append(self.buildbutton(row[0]))
.
.
def buildbutton(self,key):
    return Tkinter.Button(self,text='UnLoad it', command=lambda: self.unload(key))

When using the workaround code instead of the original code, the button
for each row has the appropriate key to the database.

Speculation:
It acts like the lambda definitions don't get solidified until the containing block exits; at that time, the lambda definition(s) get locked in with the current value of the variable getting passed into the lambda as a parameter.  By moving the lambda call to a different block (separate function), the lambda gets "locked" when that block (function) exits instead of when the containing block (loop) exits.

----------
components: IDLE, Tkinter, Windows
messages: 102120
nosy: alan.hoover
severity: normal
status: open
title: series of lamdas in loop sets the paramater on all calls to that of the last call
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr  1 20:26:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Apr 2010 18:26:04 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270146364.42.0.231062643134.issue3778@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I imagine this affects 3.1 and 3.2 as well, but I haven't added them to versions since that hasn't been confirmed.

----------
keywords: +easy
nosy: +brian.curtin, loewis, r.david.murray
priority:  -> low
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.5

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

From report at bugs.python.org  Thu Apr  1 20:28:50 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Apr 2010 18:28:50 +0000
Subject: [issue8283] series of lamdas in loop sets the paramater on all calls
	to that of the last call
In-Reply-To: <1270146362.25.0.403939205554.issue8283@psf.upfronthosting.co.za>
Message-ID: <1270146530.22.0.54991084148.issue8283@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is a defined behavior of closures.

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

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

From report at bugs.python.org  Thu Apr  1 20:28:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Apr 2010 18:28:54 +0000
Subject: [issue8282] Windows uninstaller requests admin access for
	unindentified program
In-Reply-To: <1270145243.88.0.407783271533.issue8282@psf.upfronthosting.co.za>
Message-ID: <1270146534.08.0.497979731339.issue8282@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This is a known issue which is fixed in Windows Installer 5.0. See http://blogs.msdn.com/heaths/archive/2009/02/02/changes-to-package-caching-in-windows-installer-5-0.aspx

One sentence summary snippet: "But during uninstall, packages would display ?Unidentified Publisher? even if they were signed because their embedded cabinets were stripped"

Martin may want to have a look at the blog post to see if we need to make a change (last paragraph in the blog post).

----------
nosy: +brian.curtin, loewis
status: open -> pending

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

From report at bugs.python.org  Thu Apr  1 21:24:03 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 01 Apr 2010 19:24:03 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270149843.23.0.250079240193.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a file that reliably produces the "More data is available" error from _winreg.EnumValue in Python 2.6.

The script triggers the error via a race condition, by modifying the value after PyEnumValue() calls RegQueryInfoKey() but before it calls RegEnumValue().  I don't know if that's what caused the original problem for my end-user, but it certainly is one way to trigger the problem.

I can work on a patch next week for a proper test case and to fix PyEnumValue().

----------
Added file: http://bugs.python.org/file16728/more_data_is_available.py

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

From report at bugs.python.org  Thu Apr  1 21:26:56 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 01 Apr 2010 19:26:56 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270150016.78.0.924042954783.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Here's another script that causes a "More data is available" error.  This one creates a key with a name that's exactly 256 characters long.  (The Windows Registry Editor can't display the key either)

I'm testing this on XP.  Newer versions of Windows might handle long key names better, or have a different magic length that causes failures.

----------
Added file: http://bugs.python.org/file16729/more_data_is_available2.py

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

From report at bugs.python.org  Thu Apr  1 21:30:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Apr 2010 19:30:49 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270150249.65.0.0172228699392.issue3778@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Confirmed on 3.x.

----------
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Apr  1 21:39:23 2010
From: report at bugs.python.org (OMFGROFLMAO)
Date: Thu, 01 Apr 2010 19:39:23 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270150763.27.0.00719913444678.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270150763.27.0.00719913444678.issue8284@psf.upfronthosting.co.za>


New submission from OMFGROFLMAO <benjaminworwa at gmail.com>:

>>> urlparse.urlparse("example.com/directory/file.ext")

ParseResult(scheme='', netloc='', path='example.com/directory/file.ext', params='', query='', fragment='')

Where it should be:

ParseResult(scheme='', netloc='example.com', path='/directory/file.ext', params='', query='', fragment='')

----------
messages: 102127
nosy: OMFGROFLMAO
severity: normal
status: open
title: urlparse incorrect parse
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr  1 21:45:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Apr 2010 19:45:07 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270150763.27.0.00719913444678.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270151107.85.0.0216111530544.issue8284@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Do you have references to back your claim, like RFCs quotations and links? The bahavior seems correct to me off the top of my head; a URI needs a ?://? delimiter after the scheme to mark there is a netloc part.

Regards

----------
nosy: +merwok

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

From report at bugs.python.org  Thu Apr  1 22:05:45 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 20:05:45 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270152345.69.0.153570119325.issue7585@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file16730/issue7585.difflib-tab-separator.diff

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

From report at bugs.python.org  Thu Apr  1 22:10:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Apr 2010 20:10:11 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1270152611.69.0.356321795201.issue8269@psf.upfronthosting.co.za>


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

I'd like to add that a patch would need to modify Doc/data/refcounts.dat, not the .rst files.

----------

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

From report at bugs.python.org  Thu Apr  1 22:12:33 2010
From: report at bugs.python.org (OMFGROFLMAO)
Date: Thu, 01 Apr 2010 20:12:33 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270150763.27.0.00719913444678.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270152753.42.0.607507265399.issue8284@psf.upfronthosting.co.za>


OMFGROFLMAO <benjaminworwa at gmail.com> added the comment:

example.com is a netloc not a path. I agree that it needs a scheme followed by ://, otherwise it will be invalid, from the technical point of view, but still, it's a domain.

----------

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

From report at bugs.python.org  Thu Apr  1 22:21:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Apr 2010 20:21:14 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270151107.85.0.0216111530544.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270153274.57.0.434389972344.issue8284@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------

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

From report at bugs.python.org  Thu Apr  1 22:21:57 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Apr 2010 20:21:57 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270151107.85.0.0216111530544.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270153317.38.0.951496977615.issue8284@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

My apologies for accidentally removing msg102127.

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

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

From report at bugs.python.org  Thu Apr  1 22:22:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Apr 2010 20:22:10 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270151107.85.0.0216111530544.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270153330.96.0.626420068293.issue8284@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Thu Apr  1 22:22:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 20:22:22 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270153342.98.0.781580871255.issue7585@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file16731/issue7585.difflib-tab-separator-no-trail.diff

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

From report at bugs.python.org  Thu Apr  1 22:25:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Apr 2010 20:25:14 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270151107.85.0.0216111530544.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270153514.05.0.972706034127.issue8284@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes and no.

To you, in some contexts, the characters ?example.org? identify a domain from the domain name system. However, from the URI spec viewpoint, netloc has the precise meaning of ?machine to connect to to accomplish the rest of the URI role?. In other words, the URI spec does not call any sequence of characters that is a valid domain name a netloc. In schemes without a netloc part, the part after the colon is called a path, event if it contains a domain name (e.g. mailto:wok at example.org).

In your scheme-less example, the absence of ?://? means that urlparse must assume there is no netloc part. Have you checked that the spec says we should assume an empty scheme (making urlparse right) or refuse to parse and bail?

Regards

----------

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

From report at bugs.python.org  Thu Apr  1 22:34:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Apr 2010 20:34:02 +0000
Subject: [issue8284] urlparse incorrect parse
In-Reply-To: <1270151107.85.0.0216111530544.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270154042.54.0.417983276789.issue8284@psf.upfronthosting.co.za>


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

This will be a release blocker for Python 4.1, but for now I'm closing it.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Apr  1 22:50:22 2010
From: report at bugs.python.org (Tofystedeth)
Date: Thu, 01 Apr 2010 20:50:22 +0000
Subject: [issue8285] IDLE not smart indenting correctly in nested statements
Message-ID: <1270155022.9.0.253546918439.issue8285@psf.upfronthosting.co.za>


Changes by Tofystedeth <nancedr at gmail.com>:


----------
components: IDLE
nosy: Tofystedeth
severity: normal
status: open
title: IDLE not smart indenting correctly in nested statements
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr  1 23:24:40 2010
From: report at bugs.python.org (Tofystedeth)
Date: Thu, 01 Apr 2010 21:24:40 +0000
Subject: [issue8285] IDLE not smart indenting correctly in nested statements
In-Reply-To: <1270157080.33.0.1290049865.issue8285@psf.upfronthosting.co.za>
Message-ID: <1270157080.33.0.1290049865.issue8285@psf.upfronthosting.co.za>


New submission from Tofystedeth <nancedr at gmail.com>:

huh, somehow I submitted this before I was done, sorry bout that.

IDLE (the shell, not the text editor) doubles the indentation when in nested statements.
For instance
while True:
    while True:
        while True:

becomes
>>> while True:
        while True:
                while True:
backspacing removes all 8 spaces as well, so once I'm nested that far I have to manually indent.

----------
type:  -> behavior

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

From report at bugs.python.org  Thu Apr  1 23:34:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Apr 2010 21:34:06 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI with soft floating
	point
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1270157646.29.0.160288531157.issue8265@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>From the values in the report, float.fromhex is giving the correct value here, but MIN-3*TINY is somehow coming out incorrectly.

Correct values (with Python 2.6, so old float repr; OS X 10.6.2):

Python 2.6.5+ (release26-maint:79559:79560, Apr  1 2010, 21:54:0) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> float.fromhex('0x0.ffffffffffffd6p-1022')
2.2250738585071999e-308
>>> MIN = float.fromhex('0x1p-1022')
>>> TINY = float.fromhex('0x0.0000000000001p-1022')
>>> MIN
2.2250738585072014e-308
>>> TINY
4.9406564584124654e-324
>>> 3*TINY
1.4821969375237396e-323
>>> MIN - 3*TINY
2.2250738585071999e-308
>>> from math import ldexp
>>> ldexp(1.0, -1074)
4.9406564584124654e-324

It would be helpful to see the corresponding ARM outputs.  I suspect a platform bug either in ldexp or in the multiplication or subtraction above.

----------

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

From report at bugs.python.org  Thu Apr  1 23:36:53 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 01 Apr 2010 21:36:53 +0000
Subject: [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: <1270157813.48.0.106603505927.issue8032@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +doko

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

From report at bugs.python.org  Fri Apr  2 00:47:15 2010
From: report at bugs.python.org (dauerbaustelle)
Date: Thu, 01 Apr 2010 22:47:15 +0000
Subject: [issue1683368] object.__init__ shouldn't allow args/kwds
Message-ID: <1270162035.17.0.91267039659.issue1683368@psf.upfronthosting.co.za>


dauerbaustelle <jonas at lophus.org> added the comment:

What exactly is the correct solution with Python 2.6 to avoid this warning? My use case is something like

class myunicode(unicode):
  def __init__(self, *args, **kwargs):
    unicode.__init__(self, *args, **kwargs)
    self.someattribute = calculate_attribute_once()

Shall I overwrite __new__ rather than __init__? Or what :-)

----------
nosy: +dauerbaustelle

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

From report at bugs.python.org  Fri Apr  2 00:56:48 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 01 Apr 2010 22:56:48 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1270162608.7.0.0226561926475.issue7443@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Florent, sorry. 
I have no Windows workstation now, so I cannot follow this issue.

----------

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

From report at bugs.python.org  Fri Apr  2 01:16:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Apr 2010 23:16:12 +0000
Subject: [issue1683368] object.__init__ shouldn't allow args/kwds
Message-ID: <1270163772.97.0.509792032879.issue1683368@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

@dauerbaustelle
I believe your question is a separate issue and that it should have been asked on Python list. However, yes, subclasses of immutables must override __new__. For more, do ask on the list, not here.

----------

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

From report at bugs.python.org  Fri Apr  2 01:34:19 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 23:34:19 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1270164859.52.0.986522568088.issue8278@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine to me, please apply.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Fri Apr  2 01:41:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 23:41:22 +0000
Subject: [issue8282] Windows uninstaller requests admin access for
	unindentified program
In-Reply-To: <1270145243.88.0.407783271533.issue8282@psf.upfronthosting.co.za>
Message-ID: <1270165282.35.0.732943446732.issue8282@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IIUC, fixing this would require to split the installer into two files: the msi and the cab. This would not be acceptable, so I'm closing this as "won't fix".

----------
resolution:  -> wont fix
status: pending -> closed

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

From report at bugs.python.org  Fri Apr  2 01:44:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 23:44:09 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270165449.0.0.887860129675.issue3778@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

FWIW: contributions are welcome.

----------

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

From report at bugs.python.org  Fri Apr  2 06:03:00 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 02 Apr 2010 04:03:00 +0000
Subject: [issue8286] distutils: path '[...]' cannot end with '/'
In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>
Message-ID: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I noticed this exception in http://pypm-free.activestate.com/2.6/win32-x86/pool/d/dj/django-navbar-0.2.0_win32-x86_2.6_1.pypm.d/log


[...]

reading manifest file 'django_navbar.egg-info\SOURCES.txt'

reading manifest template 'MANIFEST.in'

Traceback (most recent call last):

  File "setup.py", line 25, in <module>

    zip_safe=False,

  File "C:\ActivePython32Python26\lib\distutils\core.py", line 152, in setup

    dist.run_commands()

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 975, in run_commands

    self.run_command(cmd)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\install.py", line 53, in run

    return _install.run(self)

  File "C:\ActivePython32Python26\lib\distutils\command\install.py", line 577, in run

    self.run_command('build')

  File "C:\ActivePython32Python26\lib\distutils\cmd.py", line 333, in run_command

    self.distribution.run_command(command)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\distutils\command\build.py", line 134, in run

    self.run_command(cmd_name)

  File "C:\ActivePython32Python26\lib\distutils\cmd.py", line 333, in run_command

    self.distribution.run_command(command)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 78, in run

    self.build_package_data()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 133, in build_package_data

    for package, src_dir, build_dir, filenames in self.data_files:

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 90, in __getattr__

    self.data_files = files = self._get_data_files(); return files

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 101, in _get_data_files

    self.analyze_manifest()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 153, in analyze_manifest

    self.run_command('egg_info')

  File "C:\ActivePython32Python26\lib\distutils\cmd.py", line 333, in run_command

    self.distribution.run_command(command)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\egg_info.py", line 179, in run

    self.find_sources()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\egg_info.py", line 254, in find_sources

    mm.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\egg_info.py", line 310, in run

    self.read_template()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\sdist.py", line 204, in read_template

    _sdist.read_template(self)

  File "C:\ActivePython32Python26\lib\distutils\command\sdist.py", line 336, in read_template

    self.filelist.process_template_line(line)

  File "C:\ActivePython32Python26\lib\distutils\filelist.py", line 129, in process_template_line

    (action, patterns, dir, dir_pattern) = self._parse_template_line(line)

  File "C:\ActivePython32Python26\lib\distutils\filelist.py", line 104, in _parse_template_line

    dir = convert_path(words[1])

  File "C:\ActivePython32Python26\lib\distutils\util.py", line 191, in convert_path

    raise ValueError, "path '%s' cannot end with '/'" % pathname

ValueError: path 'examples/templates/' cannot end with '/'

----------
assignee: tarek
components: Distutils
messages: 102142
nosy: srid, tarek
severity: normal
status: open
title: distutils: path '[...]' cannot end with '/'
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  2 06:03:07 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 02 Apr 2010 04:03:07 +0000
Subject: [issue8286] distutils: path '[...]' cannot end with '/'
In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>
Message-ID: <1270180987.87.0.483358886678.issue8286@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
components: +Windows

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

From report at bugs.python.org  Fri Apr  2 10:31:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 08:31:09 +0000
Subject: [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: <1270197069.64.0.240557036949.issue8245@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From report at bugs.python.org  Fri Apr  2 10:35:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 08:35:53 +0000
Subject: [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: <1270197353.54.0.135130649342.issue8261@psf.upfronthosting.co.za>


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

Thanks, should be fixed now.

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

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

From report at bugs.python.org  Fri Apr  2 10:39:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 08:39:41 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1270197581.22.0.835189984697.issue2768@psf.upfronthosting.co.za>


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

I applied the first part of the patch in r79580.  I don't see that the second part is necessary, the other functions don't have such a note.

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

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

From report at bugs.python.org  Fri Apr  2 10:40:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 08:40:38 +0000
Subject: [issue8227] Fix C API documentation: Argument parsing
In-Reply-To: <1269475758.09.0.479187943565.issue8227@psf.upfronthosting.co.za>
Message-ID: <1270197638.27.0.981475751448.issue8227@psf.upfronthosting.co.za>


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

Looks good to me.

----------
assignee: georg.brandl -> haypo
resolution:  -> accepted

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

From report at bugs.python.org  Fri Apr  2 10:41:01 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 08:41:01 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1270197661.71.0.0557582108968.issue7696@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From report at bugs.python.org  Fri Apr  2 10:41:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 08:41:36 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1270197696.47.0.585205088311.issue8257@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> high

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

From report at bugs.python.org  Fri Apr  2 10:47:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 08:47:27 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1270198047.24.0.927636431552.issue8213@psf.upfronthosting.co.za>


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

I've fixed the using/cmdline and manpage to describe the current behavior.

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

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

From report at bugs.python.org  Fri Apr  2 11:03:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 09:03:58 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1270199038.52.0.50813323541.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Float-to-decimal comparisons have been fixed, and the Decimal hash function changed so that numerically equal Decimal and float instances hash equal, in r79583.

The idea of raising an exception for float<->Decimal comparisons was discarded partly for backwards compatibility reasons, and partly because having __eq__ raise an exception causes difficulties for sets and dicts:  for example, if equality checks between floats and Decimals raised an exception then '{-1.0, Decimal(-3)}' would give a valid set (the two values have different hashes, so the Decimal.__eq__ method is never invoked), but '{-1.0, Decimal(-2)}' would raise an exception (because the two set elements have equal hashes, so Decimal.__eq__ is invoked in order to determine whether the two elements are equal or not).

(General principle:  if x and y are hashable, x == y should never raise an exception.)

This is still only a partial fix:  comparisons between Decimal and Fraction instances still behave oddly.  This seems less likely to cause problems in real-life code, though.  The changes needed to make Decimal <-> Fraction comparisons correct are too intrusive and not yet well tested enough to make it into 2.7.  (See issue 8188).

As discussed on python-dev, I'll forward port this to py3k;  with any luck, py3k will also grow valid comparisons for Decimal <-> Fraction.

----------
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Apr  2 11:12:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 09:12:37 +0000
Subject: [issue8012] Revise generator-related Glossary entries
In-Reply-To: <1267028101.75.0.785199066969.issue8012@psf.upfronthosting.co.za>
Message-ID: <1270199557.41.0.639235320656.issue8012@psf.upfronthosting.co.za>


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

I think this patch is not correct: a "generator" really is the same as "generator function".  Both generators and genexps return an iterator; I've fixed that in r79587.

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

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

From report at bugs.python.org  Fri Apr  2 11:17:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 09:17:16 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1270199836.48.0.918975039114.issue8257@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raymond, do you want this to go into 2.7 as well?  I'm assuming that we're not going to allow mixed-type float+decimal operations in 2.7.

Also, if we're doing this, it seems to me that all the reasons you give for the Decimal constructor accepting floats also apply to the Fraction constructor.

The patch looks fine to me.  The new testcase is specific to IEEE 754 binary64 floating-point format, so I'll slap a 'requires_IEEE_754' decorator on it (copying the definition from test_math.py), if that's okay.

----------

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

From report at bugs.python.org  Fri Apr  2 11:17:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 02 Apr 2010 09:17:34 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1270199854.39.0.0280948758966.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Additional fixes: r79576, r79577, r79578 (idlelib package and some test modules)

----------

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

From report at bugs.python.org  Fri Apr  2 11:40:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 09:40:46 +0000
Subject: [issue8267] Tutorial section on dictionary keys recommends sort
	instead of sorted
In-Reply-To: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>
Message-ID: <1270201246.91.0.864078625378.issue8267@psf.upfronthosting.co.za>


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

I'm not sure about this; what is the advantage?  If you already have a list, calling .sort() on it is more efficient since it doesn't have to create a new list.

----------

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

From report at bugs.python.org  Fri Apr  2 12:18:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 10:18:13 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1270203493.89.0.380757907073.issue7279@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Stefan.  Applied to trunk in r79588.  Still needs to be forward ported to py3k.

----------
versions: +Python 3.2

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

From report at bugs.python.org  Fri Apr  2 12:37:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 10:37:00 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1270204620.35.0.305156378836.issue7279@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Allowed hashing of Decimal('nan') in r79589;  Decimal('snan') continues to raise TypeError.

I've also rewritten Decimal.__hash__ a little bit, so that it won't care if float('inf') raises an exception.  This will all be much neater if the unified numeric hash is applied.

----------

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

From report at bugs.python.org  Fri Apr  2 12:49:12 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 10:49:12 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270205352.79.0.927538247038.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Refreshed patches - feel free to apply in any order you want.

Convenience link for reviews:
http://codereview.appspot.com/809043/show

----------

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

From report at bugs.python.org  Fri Apr  2 12:55:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 02 Apr 2010 10:55:39 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1270205739.94.0.855121495968.issue8278@psf.upfronthosting.co.za>


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


----------
assignee:  -> amaury.forgeotdarc

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

From report at bugs.python.org  Fri Apr  2 12:56:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 02 Apr 2010 10:56:20 +0000
Subject: [issue8287] python-gdb.py triggers compile errors on FreeBSD and
	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>


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

The compile step fails on "python-gdb.py" on some buildbots.


# #### sparc solaris 10 gcc ####

running build_scripts
[51847 refs]
./install-sh -c  python-gdb.py
./install-sh: python-gdb.py does not exist
*** Error code 1
make: Fatal error: Command failed for target `python-gdb.py'


# #### x86 FreeBSD ####

running build_scripts
[53576 refs]
/usr/bin/install -c  python-gdb.py
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 file2
       install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 ... fileN directory
       install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** Error code 64

----------
components: Build
keywords: buildbot
messages: 102155
nosy: doko, flox, loewis
priority: high
severity: normal
stage: needs patch
status: open
title: python-gdb.py triggers compile errors on FreeBSD and Solaris
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  2 13:09:19 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 02 Apr 2010 11:09:19 +0000
Subject: [issue8287] python-gdb.py triggers compile errors on FreeBSD and
	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270206559.41.0.42480310596.issue8287@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

David, can you please take a look?

----------
assignee:  -> dmalcolm
nosy: +dmalcolm

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

From report at bugs.python.org  Fri Apr  2 13:18:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 11:18:27 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270207107.57.0.695554556713.issue7585@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file16732/issue7585.difflib-tab-update-docs.diff

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

From report at bugs.python.org  Fri Apr  2 13:20:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 11:20:32 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1270207232.03.0.52250021383.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The backport wasn't as straightforward as I'd hoped, and we've pretty much run out of time for 2.7.

One issue is that long.from_bytes(b, ...) converts b to bytes type using the equivalent of "bytes(b)".  This doesn't work well in 2.7 (consider "bytes([255, 0, 0])" for example.  So different code is needed in 2.7 when interpreting an arbitrary Python object as a sequence of bytes.

Perhaps the 2.7 version could just iterate over the given object, and raise an exception if any of the iterates are not integers in the range [0, 256).

----------

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

From report at bugs.python.org  Fri Apr  2 13:24:08 2010
From: report at bugs.python.org (=?utf-8?q?Kent_Engstr=C3=B6m?=)
Date: Fri, 02 Apr 2010 11:24:08 +0000
Subject: [issue8267] Tutorial section on dictionary keys recommends sort
	instead of sorted
In-Reply-To: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>
Message-ID: <1270207448.21.0.505123820887.issue8267@psf.upfronthosting.co.za>


Kent Engstr?m <kent at lysator.liu.se> added the comment:

Is should have mentioned that we're discussion a section
of the tutorial concerned with dictionaries. It is not a
section on lists, sequences or sorting as such.

My colleague, who asked me for help after getting confused
by sort, was trying to loop over the keys in the dictionary
in sorted order.  In that context, sorted is superior to sort.

----------

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

From report at bugs.python.org  Fri Apr  2 13:29:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 11:29:46 +0000
Subject: [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: <1270207786.21.0.850489419135.issue8259@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The original error, for a 32-bit machine, looks like expected behaviour to me;  at worst, it's a doc bug.  If the right-hand argument doesn't fit into a Py_ssize_t, then I think it's reasonable to refuse to do the shift.

But Antoine's 'outrageous left shift count' comes from the following code, in long_lshift in Objects/longobject.c.

	if ((long)(int)shiftby != shiftby) {
		PyErr_SetString(PyExc_ValueError,
				"outrageous left shift count");
		goto lshift_error;
	}

I think this code dates from the days when the number of 'digits' of a PyLong was held in an int rather than a Py_ssize_t, and I think it's a (minor) bug.  A 64-bit machine with sufficient RAM shouldn't mind shifting something by >= 2**31 places.

----------

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

From report at bugs.python.org  Fri Apr  2 13:35:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 11:35:26 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270208126.35.0.555029200783.issue7585@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Removed file: http://bugs.python.org/file16732/issue7585.difflib-tab-update-docs.diff

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

From report at bugs.python.org  Fri Apr  2 13:41:25 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 11:41:25 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270208485.53.0.421479338209.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

These patches are incrementally add features. Feel free to apply one that suits most. Codereview provides more convenient way to review differences between these.

attaching optional patch that removes recommendation to use ctime format for timestamps

----------
Added file: http://bugs.python.org/file16733/issue7585.difflib-tab-update-docs.diff

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

From report at bugs.python.org  Fri Apr  2 13:43:18 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 11:43:18 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270208598.35.0.893318123384.issue7585@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file16734/issue7585.difflib-tab-updoc-iso8601.diff

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

From report at bugs.python.org  Fri Apr  2 13:48:36 2010
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 02 Apr 2010 11:48:36 +0000
Subject: [issue8235] Support FreeBSD's SO_SETFIB in socketmodule.c
In-Reply-To: <1269560401.06.0.703544255222.issue8235@psf.upfronthosting.co.za>
Message-ID: <1270208916.67.0.64905920666.issue8235@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Committed in Python 2.7 as revision r79592
Committed in Python 3.2 as revision r79594

Thanks for the patch!

----------
assignee:  -> larry
resolution:  -> accepted
status: open -> closed
versions: +Python 3.2

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

From report at bugs.python.org  Fri Apr  2 14:35:41 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 02 Apr 2010 12:35:41 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1270211741.2.0.835901508805.issue7994@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Committed in trunk in r79596. I'll leave this open until I port to py3k, check the old tests for this usage, and create the issue to make it a DeprecationWarning.

----------
stage: patch review -> committed/rejected

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

From report at bugs.python.org  Fri Apr  2 14:44:49 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 12:44:49 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270212289.32.0.372631149172.issue2810@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

If this doesn't relate to multibyte strings anymore, but just to long strings then I'd open new bug.

If even regedit fails to query then maybe its WinAPI flaw? Maybe it will worth to try ctypes.

----------

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

From report at bugs.python.org  Fri Apr  2 14:51:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 02 Apr 2010 12:51:31 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1270212691.79.0.327761287195.issue7992@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The PendingDeprecationWarning is still spit by the bsddb module.

$ ./python -Wd -m test.regrtest test_bsddb
test_bsddb
./Lib/importlib/__init__.py:37: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  __import__(name)h
1 test OK.

----------

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

From report at bugs.python.org  Fri Apr  2 15:20:23 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 02 Apr 2010 13:20:23 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270214423.49.0.228083839136.issue3778@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Isn't there an issue around having multiple versions of Python installed? The top level folder should only be removed if the version of Python being uninstalled is the last installed Python. This means executing code on uninstall and doesn't seem worth the effort.  

If I'm correct in this then I would suggest closing as wontfix.

----------
nosy: +michael.foord

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

From report at bugs.python.org  Fri Apr  2 15:48:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 13:48:23 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270216103.65.0.561912213051.issue3778@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The top level should be removed only when it is empty after Python that is being uninstalled removed its own branch.

----------

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

From report at bugs.python.org  Fri Apr  2 15:50:20 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 02 Apr 2010 13:50:20 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270216220.83.0.0575076838853.issue3778@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

There should be a "function" to remove key if empty.

BTW, what software is used to create (un)installer and where is Python code for it?

----------

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

From report at bugs.python.org  Fri Apr  2 15:52:57 2010
From: report at bugs.python.org (Grigory)
Date: Fri, 02 Apr 2010 13:52:57 +0000
Subject: [issue8288] zipfile module documentation misprint
In-Reply-To: <1270216377.49.0.632972257682.issue8288@psf.upfronthosting.co.za>
Message-ID: <1270216377.49.0.632972257682.issue8288@psf.upfronthosting.co.za>


New submission from Grigory <matpuk at gmail.com>:

Zipfile module documentaion says:
"""
The file-like object is read-only and provides the following methods: read(), readline(), readlines(), __iter__(), next()
"""

But ZipExtFile class doesn't provide next(), it provides __next__().

----------
assignee: georg.brandl
components: Documentation
messages: 102168
nosy: georg.brandl, matpuk
severity: normal
status: open
title: zipfile module documentation misprint
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Apr  2 15:54:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 02 Apr 2010 13:54:09 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270216449.62.0.692068650515.issue3778@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

See PC/_msi.c, Lib/msilib, and Tools/msi

----------

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

From report at bugs.python.org  Fri Apr  2 16:05:10 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 02 Apr 2010 14:05:10 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270217110.57.0.0185989659894.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

It was never 100% clear that it ever related to multi-byte strings, so (as the original reporter) I'd prefer to continue using this bug and just update the title to: _winreg.EnumValue sometimes raises WindowsError ("More data is available").

The patch I have planned will fix the problem regardless of the cause, (except for impossible-to-fix causes, such as if there really is an API flaw).

----------

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

From report at bugs.python.org  Fri Apr  2 16:28:30 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 02 Apr 2010 14:28:30 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270218510.68.0.683801150005.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I just wrote a C program that can read the long key name just fine, so it's not a Windows API bug.

----------

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

From report at bugs.python.org  Fri Apr  2 17:06:49 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 02 Apr 2010 15:06:49 +0000
Subject: [issue8289] multiprocessing.Process.__init__ pickles all arguments
In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za>
Message-ID: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Currently, when you create a Process, all arguments you pass to its __init__ get pickled. I understood this is done because arguments to __init__ almost always become attributes to the Process. Like this:

def MyProcess(multiprocessing.Process):
    def __init__(self, whatever):
         self.whatever = whatever

Of course, attributes must be pickled so they can be accessed from the separate process (on Windows). And indeed in most cases all arguments to __init__ become attributes, so this makes sense.

But, in some cases you pass in arguments to __init__ that do not become attributes. In my case, __init__ takes an object, and takes some attributes of this object as attributes to itself. The object is unpicklable, but the attributes are. So I had to make some ugly workaround to make the program run.

So I think it would be better if Process would be smart enough to pickle only the arguments that get set as attributes.

----------
components: Library (Lib)
messages: 102172
nosy: cool-RR
severity: normal
status: open
title: multiprocessing.Process.__init__ pickles all arguments
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/issue8289>
_______________________________________

From report at bugs.python.org  Fri Apr  2 17:07:46 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 02 Apr 2010 15:07:46 +0000
Subject: [issue8289] multiprocessing.Process.__init__ pickles all arguments
In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za>
Message-ID: <1270220866.01.0.907652096742.issue8289@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Sorry, I accidentally typed "def" instead of "class" in my code sample.

----------

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

From report at bugs.python.org  Fri Apr  2 17:34:45 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 02 Apr 2010 15:34:45 +0000
Subject: [issue8287] python-gdb.py triggers compile errors on FreeBSD and
	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270222485.93.0.642973465461.issue8287@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Sorry about this.

I believe this is the expansion of these fragments from the Makefile.pre.in  (indenting for clarity):

    gdbhooks: $(BUILDPYTHON)-gdb.py

    $(BUILDPYTHON)-gdb.py: Tools/gdb/libpython.py
            $(INSTALL_SCRIPT) $< $(BUILDPYTHON)-gdb.py

It looks like the second of these is being invoked in both cases with "$<" as the empty string, rather than "Tools/gdb/libpython.py" (and each with their own expansion of "INSTALL_SCRIPT").

I'm guessing that the "$<" is a GNU Make-ism that isn't available on all implementations of "make".  If so, the quick fix is probably to replace "$<" with "Tools/gdb/libpython.py" in Makefile.pre.in

I'm attaching a patch which introduces a variable for the path and uses this, rather than "$<".

I only have access to Linux machines; I've tested it on one, and it works.

I don't have commit rights, so I can't fix this directly myself.

$ make -v
GNU Make 3.81

>From "info make":
`$<'
     The name of the first prerequisite.  If the target got its
     commands from an implicit rule, this will be the first
     prerequisite added by the implicit rule (*note Implicit Rules::).


(In my defence, "$<" appeared to be used already in the "Some make's put the object file in the current directory" rule).


Sorry again from breaking the build on those configurations.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16735/introduce-var-for-gdb-hooks.patch

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

From report at bugs.python.org  Fri Apr  2 18:03:51 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Fri, 02 Apr 2010 16:03:51 +0000
Subject: [issue8290] I HAVE A PROBLEM WITH PYTHON
In-Reply-To: <1270224231.7.0.39248878914.issue8290@psf.upfronthosting.co.za>
Message-ID: <1270224231.7.0.39248878914.issue8290@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

I HAVE TO PERFORM A TASK THAT IS CALENDER.PY
in what way it is easier to me please tell

----------
files: day.py
messages: 102175
nosy: krishnalolla
severity: normal
status: open
title: I HAVE A PROBLEM WITH PYTHON
type: performance
Added file: http://bugs.python.org/file16736/day.py

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

From report at bugs.python.org  Fri Apr  2 18:07:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Apr 2010 16:07:00 +0000
Subject: [issue8290] I HAVE A PROBLEM WITH PYTHON
In-Reply-To: <1270224231.7.0.39248878914.issue8290@psf.upfronthosting.co.za>
Message-ID: <1270224420.55.0.305503753086.issue8290@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

HI!
This is the wrong place where to ask help, try http://www.python.org/about/help/#got-a-python-problem-or-question

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Apr  2 18:19:03 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Fri, 02 Apr 2010 16:19:03 +0000
Subject: [issue8291] i have a doubt with using __init__ and .self and classes
In-Reply-To: <1270225143.56.0.0738074047322.issue8291@psf.upfronthosting.co.za>
Message-ID: <1270225143.56.0.0738074047322.issue8291@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

i have a doubt with __init__ and .self how it is useful to us?
are we have to define a class in another class?if it is by what function

----------
messages: 102177
nosy: krishnalolla, skip.montanaro
severity: normal
status: open
title: i have a doubt with using __init__ and .self and classes
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr  2 18:20:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Apr 2010 16:20:16 +0000
Subject: [issue8291] i have a doubt with using __init__ and .self and classes
In-Reply-To: <1270225143.56.0.0738074047322.issue8291@psf.upfronthosting.co.za>
Message-ID: <1270225216.69.0.281410025829.issue8291@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Hi!
This is the wrong place where to ask help, try http://www.python.org/about/help/#got-a-python-problem-or-question

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Apr  2 18:48:38 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 02 Apr 2010 16:48:38 +0000
Subject: [issue8292] Incorrect condition test in platform.py
In-Reply-To: <1270226918.36.0.398729222231.issue8292@psf.upfronthosting.co.za>
Message-ID: <1270226918.36.0.398729222231.issue8292@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

While looking at #4440, I grepped for similar problems and found one in
platform.py in the following line:

if no_os_uname or not filter(None, (system, node, release, version, machine))

In 3.x, filter() returns an object, not a list, so 'not filter()' will always be false.  

One fix is to either convert filter's output by adding list() or tuple(). Another fix could be 'not any ((system, node, release, version, machine))', but I don't know if platform.py is trying to stay compatible with versions of Python that lack any().

----------
assignee: lemburg
keywords: easy
messages: 102179
nosy: akuchling, lemburg
severity: normal
status: open
title: Incorrect condition test in platform.py
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr  2 19:05:12 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 02 Apr 2010 17:05:12 +0000
Subject: [issue4440] "sort" command doesn't work in pstats if run interactively
In-Reply-To: <1227711651.41.0.519645038553.issue4440@psf.upfronthosting.co.za>
Message-ID: <1270227912.94.0.617711409993.issue4440@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Thanks for your bug report and patch!

The original 2.x version was pretty ugly code with a lambda that used default arguments, so I rewrote the line to be more modern; it now does 
' all((x in abbrevs) for x in line.split())'.

Committed my version to trunk to r79603, and to 3.x trunk in r79604.

(A lot of pstats.py is pretty old-looking and could be tied up.)

----------
assignee:  -> akuchling
nosy: +akuchling
resolution:  -> fixed
status: open -> closed
Added file: http://bugs.python.org/file16737/pstats-simplify.diff

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

From report at bugs.python.org  Fri Apr  2 19:06:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Apr 2010 17:06:41 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1270228001.64.0.611081629886.issue8257@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Added the requires decorator as requested.
Committed in r79602.  Will backport to 2.7 this weekend.

And yes, I agree that Fraction(somedecimal) should work too.  It would be weird to have Fraction("1.1") work but not Fraction(Decimal("1.1")).

Mark, I do think we should have decimal+float-->float in 2.7 also.  I don't see any reason to have the two versions diverge on this issue.

----------

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

From report at bugs.python.org  Fri Apr  2 19:08:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 17:08:44 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1270228124.66.0.5664829269.issue8257@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Mark, I do think we should have decimal+float-->float in 2.7 also.

That's fine with me in principle.  But isn't 2.7 in feature freeze from tomorrow?

----------

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

From report at bugs.python.org  Fri Apr  2 19:11:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 17:11:11 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1270228271.5.0.757722505078.issue8257@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> And yes, I agree that Fraction(somedecimal) should work too.

What about Fraction(1.1)?

----------

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

From report at bugs.python.org  Fri Apr  2 19:26:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 02 Apr 2010 17:26:32 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270229192.54.0.23112197594.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

After discussion with Brian it seems like it should be possible for os.kill(...) on Windows to support both pids *and* process handles. This seems ideal.

----------

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

From report at bugs.python.org  Fri Apr  2 19:54:35 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 02 Apr 2010 17:54:35 +0000
Subject: [issue6647] warnings.catch_warnings is not thread-safe
In-Reply-To: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>
Message-ID: <1270230875.87.0.646960273567.issue6647@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Added a warning to 2.x trunk in r79607, and Gabriel's doc change in r79608.  This thread-unsafety seems specialized and rarely of great importance, so I used the note:: directive, not warning::.

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Apr  2 20:58:29 2010
From: report at bugs.python.org (David Andrzejewski)
Date: Fri, 02 Apr 2010 18:58:29 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>


New submission from David Andrzejewski <site+python.org at davidandrzejewski.com>:

Python 2.6.4, Windows XP.

If you run the following code:

import httplib

http_connection = httplib.HTTPConnection("192.168.192.196")
http_connection.request("GET", "/")
http_connection.sock.settimeout(20)
response = http_connection.getresponse()
data = response.read()
http_connection.close()


And then run a netstat -a, you'll see that the connection is no longer established (it'll have a status of TIME_WAIT or something along those lines).

However, if you run the following code:

import httplib

http_connection = httplib.HTTPSConnection("192.168.192.196")
http_connection.request("GET", "/")
http_connection.sock.settimeout(20)
response = http_connection.getresponse()
data = response.read()
http_connection.close()

And run a netstat, the connection will still be in the ESTABLISHED state.  The connection does not end for several minutes (or when you terminate the program).

I can get the connection to end when I want it by doing a del on the connection object and then manually running garbage collection - although that seems a bit wonky.

I'm not really sure what all the differences are between HTTPConnection and HTTPSConnection, but it seems like they should both behave the same way in this regard.

----------
components: Library (Lib)
messages: 102186
nosy: dandrzejewski
severity: normal
status: open
title: HTTPSConnection.close() does not immediately close the connection.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  2 21:01:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Apr 2010 19:01:11 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1270234871.09.0.172577291876.issue8293@psf.upfronthosting.co.za>


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


----------
nosy: +orsenthil
priority:  -> normal

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

From report at bugs.python.org  Fri Apr  2 21:16:39 2010
From: report at bugs.python.org (John Posner)
Date: Fri, 02 Apr 2010 19:16:39 +0000
Subject: [issue8012] Revise generator-related Glossary entries
In-Reply-To: <1267028101.75.0.785199066969.issue8012@psf.upfronthosting.co.za>
Message-ID: <1270235799.09.0.539614084701.issue8012@psf.upfronthosting.co.za>


John Posner <jjposner at optimum.net> added the comment:

Georg, your change (r79587) makes this the main definition:

  generator
      A function which returns an iterator.
  
I'm concerned that this definition does not fit well with the occurrence of "generator object" in the following:

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.
>>> obj1 = (x for x in [1,2])
>>> def gfunc():
...     count = 0
...     while True:
...             count += 1
...             yield count
...
>>> obj2 = gfunc()
>>> obj1
<generator object <genexpr> at 0x00CC6378>
>>> obj2
<generator object gfunc at 0x00CC6328>
>>>


My patch attempted to make "generator" be the same as "generator object" in the above.

----------

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

From report at bugs.python.org  Fri Apr  2 21:22:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 19:22:29 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI with soft floating
	point
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1270236149.35.0.600002620902.issue8265@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I made a couple of experimental checkins to the release26-maint branch (I didn't want to do a temporary checkin to the trunk with a release imminent):  see r79560 (which didn't work :) and its fix in r79601.  Results:

  MIN = 2.2250738585072014e-308
  TINY = 4.9406564584124654e-324
  3*TINY = 1.4821969375237396e-323
  MIN - 3*TINY = 2.2250738585071984e-308
  ldexp(1.0, -1074) = 4.9406564584124654e-324

The values for MIN, TINY and 3*TINY are correct; the value for MIN - 3*TINY (which should be an exact operation) is not:  it's giving something equal to MIN - 6*TINY instead.  This should be easily reproducible at the C level, since the Python subtraction is just a thin wrapper around the corresponding C operation.

So it looks as though the float emulation is buggy on this platform, and this bug should be reported upstream.  Matthias, can you take care of this?

For Python, I'm not sure what the appropriate action is, but I'd rather not skip the test, or otherwise completely silence the error.  Maybe some sort of "expected failure due to platform floating-point bug" output?

----------

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

From report at bugs.python.org  Fri Apr  2 21:36:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 19:36:20 +0000
Subject: [issue8012] Revise generator-related Glossary entries
In-Reply-To: <1267028101.75.0.785199066969.issue8012@psf.upfronthosting.co.za>
Message-ID: <1270236980.65.0.10453480402.issue8012@psf.upfronthosting.co.za>


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

Well, the object returned is "just" an iterator (which happens to be implemented by a generator-iterator).  I wouldn't be so concerned about the repr() of the it.

If you look at the generator PEP, number 255, it says:

"""Note that when the intent is clear from context, the unqualified name
"generator" may be used to refer either to a generator-function or a 
generator-iterator."""

My experience is that most people use "generator" to mean the actual function.  The returned object is mostly called iterator.

----------

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

From report at bugs.python.org  Fri Apr  2 21:54:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 19:54:58 +0000
Subject: [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: <1270238098.0.0.100822858192.issue8032@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A nitpick:  on OS X, the gdb script ends up being called:

python.exe-gdb.py

Is this intentional?  If it is, then I'll add this filename to the svn:ignore property.  (And also to make distclean, I guess.  Is python-gdb.py currently deleted by a 'make distclean'?)

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Fri Apr  2 22:13:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Apr 2010 20:13:15 +0000
Subject: [issue8288] zipfile module documentation misprint
In-Reply-To: <1270216377.49.0.632972257682.issue8288@psf.upfronthosting.co.za>
Message-ID: <1270239195.45.0.471737315574.issue8288@psf.upfronthosting.co.za>


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

Thanks, fixed in r79615 (only applies to py3k.)

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Fri Apr  2 22:15:00 2010
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 02 Apr 2010 20:15:00 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1270239300.07.0.212424028655.issue7992@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Yes.  I was told it was inappropriate for me to change the bsddb module, as it's independently maintained by Jesus Cea.  I sent Mr. Cea a patch last night; I hope he chooses to merge it soon.

Since CObjects are marked Pending Deprecation, and bsddb is using a CObject, this is correct behavior.

Were you mentioning it simply to bring it my attention, or am I missing something important?

----------

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

From report at bugs.python.org  Fri Apr  2 22:15:46 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 02 Apr 2010 20:15:46 +0000
Subject: [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: <1270239346.13.0.696602793435.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> A nitpick:  on OS X, the gdb script ends up being called:
>
> python.exe-gdb.py
>
> Is this intentional?  If it is, then I'll add this filename to the 
> svn:ignore property.  (And also to make distclean, I guess.  Is python-
> gdb.py currently deleted by a 'make distclean'?)


That was unexpected, but re-reading Makefile.pre.in I see where it's coming from.  Please do add it to svn:ignore.

Looks like I forgot to add the removal of the file to the "distclean" target.  Sorry about that.  Presumably adding:
  -rm -f python*-gdb.py
should do the trick (as I understand it, if the glob fails to match, it will happily fail to "rm" the non-existant file named "python*-gdb.py").

Another nit I spotted: the buildbot is "unexpectedly" skipping test_gdb on Win32 (with "gdb not found in path").  Looking at _expectations in Lib/test/regrtest.py it strikes me that test_gdb is likely to be skipped on every configuration other than on "linux2") - should I wire that in with a decorator within test_gdb.py?

To my knowledge, OS X doesn't ship with gdb 7 - though presumably someone could build their own copy, linking with the system Python, and if so, the python.exe-gdb.py file would then be of use in debugging the freshly-built ./python.exe

----------

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

From report at bugs.python.org  Fri Apr  2 22:19:23 2010
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 02 Apr 2010 20:19:23 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1270239563.71.0.30247778619.issue7992@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Oh, and, last night I checked in r79590.  This is the checkin that ameliorates the backwards compatibility issues.  Specifically, I changed four things:

* PyCObject_AsVoidPtr() can now open capsules.  This addresses
  most of the remaining backwards-compatibility concerns about
  the conversion of Python 2.7 from CObjects to capsules.
* CObjects were marked Pending Deprecation.
* Documentation about this pending deprecation was added to
  cobject.h.
* The capsule source files were added to the legacy PC build
  processes.

(Someone had already added them to the current PC build process, a day or two after I committed the previous checkin.)

Sorry for forgetting to update the issue last night, but I was in a bit of a hurry to get this done before Benjamin cut 2.7b1.

----------

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

From report at bugs.python.org  Fri Apr  2 22:24:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 20:24:58 +0000
Subject: [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: <1270239898.62.0.627936680716.issue8032@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added python.exe-gdb.py to svn:ignore in r79616.

----------

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

From report at bugs.python.org  Fri Apr  2 22:25:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 02 Apr 2010 20:25:29 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1270239929.17.0.6912913736.issue7992@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Ok, I put J?sus in the nosy list.

It makes the test___all__ fail on trunk because it checks the warnings raised during import.

AFAIU, the patch is something like:

-#if (PY_VERSION_HEX < 0x03020000)
+#if (PY_VERSION_HEX < 0x02070000)

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

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

From report at bugs.python.org  Fri Apr  2 22:34:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 20:34:54 +0000
Subject: [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: <1270240494.54.0.615551206077.issue8032@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> To my knowledge, OS X doesn't ship with gdb 7

That sounds right.  On my OS X 10.6.3 machine, the system gdb is:

Mark-Dickinsons-MacBook-Pro:py3k dickinsm$ gdb --version
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009)

I have the impression that few people have got gdb 7 working on OS X yet, but I might be wrong.  Certainly macports doesn't seem to offer it yet.  I expect that'll change, though.

[About make distclean]
> Presumably adding:
>   -rm -f python*-gdb.py
> should do the trick

Yes, that seems to work.  Thanks!  Added in r79617.

----------

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

From report at bugs.python.org  Fri Apr  2 22:42:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 20:42:43 +0000
Subject: [issue8294] Allow Fraction constructor to accept float and decimal
	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>


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

Here's a patch that allows direct construction of a Fraction instance from a float or Decimal instance, performing an exact conversion in either case.

>>> from fractions import Fraction
>>> from decimal import Decimal
>>> Fraction(1.1)
Fraction(2476979795053773, 2251799813685248)
>>> Fraction(Decimal('1.1'))
Fraction(11, 10)
>>> Fraction(Decimal(1.1))
Fraction(2476979795053773, 2251799813685248)

----------
assignee: rhettinger
components: Library (Lib)
files: fraction_from_float.patch
keywords: patch
messages: 102198
nosy: mark.dickinson, rhettinger
severity: normal
status: open
title: Allow Fraction constructor to accept float and decimal instances directly.
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16738/fraction_from_float.patch

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

From report at bugs.python.org  Fri Apr  2 22:43:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 20:43:33 +0000
Subject: [issue8294] Allow Fraction constructor to accept float and decimal
	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270241013.6.0.945937520228.issue8294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

(The patch is against trunk, btw.)

----------

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

From report at bugs.python.org  Fri Apr  2 22:48:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 02 Apr 2010 20:48:44 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270241324.26.0.764962429778.issue1220212@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16704/issue1220212.patch

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

From report at bugs.python.org  Fri Apr  2 23:01:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 02 Apr 2010 21:01:27 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270242087.9.0.210083557097.issue1220212@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Michael, do you have an example of something which returns a handle? This current patch doesn't work with handles, but it wouldn't be hard to add it. I could make it work with the _handle object of a Popen object, but you could just as easily call os.kill on the pid of the Popen object. I don't know of any Python-wide handle object...I know subprocess has it's own, and don't really know what other functions are returning handles.


Anyways, this patch includes an additional test script which uses ctypes to setup a console control handler, and CTRL_BREAK_EVENT is tested successfully. However, CTRL_C_EVENT is not. See http://msdn.microsoft.com/en-us/library/ms686016%28v=VS.85%29.aspx for details, but I'm not able to get the subprocess to work with CTRL+C. Calling SetConsoleCtrlHandler(NULL, FALSE) either in the script, test_os, or in _subprocess.c does not change anything, although it seems that it should. The CTRL_C_EVENT test is currently skipped in the patch until I can figure that out.

----------
nosy: +dino.viehland
Added file: http://bugs.python.org/file16739/issue1220212.patch

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

From report at bugs.python.org  Fri Apr  2 23:04:19 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Apr 2010 21:04:19 +0000
Subject: [issue8294] Allow Fraction constructor to accept float and decimal
	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270242259.5.0.65285241535.issue8294@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The patch looks like what I expected.

In the docstring, it would be nice if we kept the line with the spec for decimal strings:  [-+]?[0-9]+((/|.)[0-9]+)?

----------
assignee: rhettinger -> mark.dickinson
resolution:  -> accepted

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

From report at bugs.python.org  Fri Apr  2 23:05:33 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 02 Apr 2010 21:05:33 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270242333.61.0.447469814582.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

According to earlier discussion in this issue os.spawn() return process handles on Windows.

----------

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

From report at bugs.python.org  Fri Apr  2 23:06:17 2010
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 02 Apr 2010 21:06:17 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1270242377.79.0.346700559997.issue7992@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

The patch is a bit more involved than that.  Capsules didn't exist in 3.0, and the bsddb module published a CObject in 3.1.  So bsddb must continue to use CObject for those two releases.

Therefore the patch to the line you were addressing looks like this:

-#if (PY_VERSION_HEX < 0x03020000)
+#if (PY_VERSION_HEX < ((PY_MAJOR_VERSION < 3) ? 0x02070000 : 0x03020000))

However, Jesus's use of capsules has a bug.  The capsule API requires that the string passed in to PyCapsule_New() must "outlive" the capsule; he's passing in a stack buffer.  So my patch also fixes that.

Finally my bsddb patch adds the appropriate text to the header file where it describes how to import the _bsddb C API object (CObject vs capsule).

FWIW, I want to close this issue soon.  How about I close it after 2.7b1 has been out for a week or so--assuming there aren't any new concerns regarding the capsule backport.

----------

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

From report at bugs.python.org  Fri Apr  2 23:07:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 21:07:08 +0000
Subject: [issue8294] Allow Fraction constructor to accept float and decimal
	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270242428.63.0.959783893861.issue8294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Unfortunately, that line is wrong (or at least incomplete), since decimals in exponential form are also accepted:

>>> Fraction('2.3e4')
Fraction(23000, 1)

I could try to reinstate a fixed version.

Attaching a second version of the patch:  same as the first, except for some doc tweaks.  (Rewording, markup fixes.)

----------
Added file: http://bugs.python.org/file16740/fraction_from_float2.patch

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

From report at bugs.python.org  Fri Apr  2 23:13:07 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Apr 2010 21:13:07 +0000
Subject: [issue8294] Allow Fraction constructor to accept float and decimal
	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270242787.04.0.336237240247.issue8294@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Being wrong is a good reason to eliminate that line from the docstring :-)    So, I'm happy with the patch as-is.

----------

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

From report at bugs.python.org  Fri Apr  2 23:19:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 02 Apr 2010 21:19:55 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1270243195.51.0.00483103702536.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed to trunk in r79620. I'll do the forward port after 2.7b1.

----------
stage: patch review -> committed/rejected

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

From report at bugs.python.org  Fri Apr  2 23:25:59 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 02 Apr 2010 21:25:59 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1270243559.28.0.00664398317547.issue8293@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Sat Apr  3 00:15:21 2010
From: report at bugs.python.org (John Posner)
Date: Fri, 02 Apr 2010 22:15:21 +0000
Subject: [issue8012] Revise generator-related Glossary entries
In-Reply-To: <1267028101.75.0.785199066969.issue8012@psf.upfronthosting.co.za>
Message-ID: <1270246521.92.0.568406285789.issue8012@psf.upfronthosting.co.za>


John Posner <jjposner at optimum.net> added the comment:

Fair enough, Georg. Case closed.

----------

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

From report at bugs.python.org  Sat Apr  3 00:22:39 2010
From: report at bugs.python.org (John Ehresman)
Date: Fri, 02 Apr 2010 22:22:39 +0000
Subject: [issue2799] Remove PyUnicode_AsString(),
	rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
In-Reply-To: <1210329112.66.0.505096173761.issue2799@psf.upfronthosting.co.za>
Message-ID: <1270246959.84.0.895382129789.issue2799@psf.upfronthosting.co.za>


John Ehresman <jpe at wingware.com> added the comment:

I'm trying to port an existing C extension to py3k and find myself wanting something like PyUnicode_AsString so I don't need to introduce other objects to do memory management.  PyUnicode_AsString is equivalent to PyArg_Parse w/ a 's' format code, which I find hard to believe will be removed.  Another bug proposes changing the name and passing in a default value, which may be a good idea.

----------
nosy: +jpe

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

From report at bugs.python.org  Sat Apr  3 00:27:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Apr 2010 22:27:18 +0000
Subject: [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: <1270247238.98.0.791005996157.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a new patch. Should be complete but I want to test it some more before committing.
I decided to follow RFC 3629, putting 0 instead of 5/6 for bytes in range F5-FD (we can always put them back in the unlikely case that the Unicode Consortium changed its mind) and also for other invalid ranges (e.g. C0-C1). This lead to some simplification in the code.

I also found out that, according to RFC 3629, surrogates are considered invalid and they can't be encoded/decoded, but the UTF-8 codec actually does it. I included tests and fix but I left them commented out because this is out of the scope of this patch, and it probably need a discussion on python-dev.

----------
stage: test needed -> patch review
versions: +Python 2.6
Added file: http://bugs.python.org/file16741/issue8271v2.diff

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

From report at bugs.python.org  Sat Apr  3 00:28:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 22:28:11 +0000
Subject: [issue8294] Allow Fraction constructor to accept float and decimal
	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270247291.98.0.00357157961797.issue8294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Raymond.  Committed to trunk in r79629.  Will forward port to py3k.

----------
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Apr  3 00:56:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 02 Apr 2010 22:56:18 +0000
Subject: [issue8038] Provide unittest.TestCase.assertNotRegexpMatches
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1270248978.93.0.00882405489308.issue8038@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 79632.

----------

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

From report at bugs.python.org  Sat Apr  3 01:26:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 02 Apr 2010 23:26:00 +0000
Subject: [issue8295] add unpack_archive to shutil
In-Reply-To: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>
Message-ID: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>


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

unpack_archive is the reverse operation of make_archive and works the same way: it has a registery of function for each archive format.

----------
assignee: tarek
components: Library (Lib)
messages: 102212
nosy: tarek
priority: normal
severity: normal
status: open
title: add unpack_archive to shutil
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr  3 01:27:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 02 Apr 2010 23:27:49 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270250869.39.0.587854795789.issue1220212@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed to trunk in r79633 after talking with Michael about it. I'll forward port it after the 2.7 beta goes out.

----------
assignee:  -> brian.curtin
stage:  -> committed/rejected
type:  -> feature request

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

From report at bugs.python.org  Sat Apr  3 02:58:39 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 03 Apr 2010 00:58:39 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1270256319.77.0.488400365643.issue1222585@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file16742/distutils2-C++.patch

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

From report at bugs.python.org  Sat Apr  3 03:16:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 01:16:32 +0000
Subject: [issue8038] Provide unittest.TestCase.assertNotRegexpMatches
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1270257392.56.0.469438223919.issue8038@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Further commit revision 79643. Needs tests and documentation.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Apr  3 03:16:50 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 01:16:50 +0000
Subject: [issue8038] Provide unittest.TestCase.assertNotRegexpMatches
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1270257410.49.0.771323094443.issue8038@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------

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

From report at bugs.python.org  Sat Apr  3 03:17:27 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 01:17:27 +0000
Subject: [issue7780] unittest: allow an 'import_path' as an alternative to
	'top_level_dir' in test discover
In-Reply-To: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>
Message-ID: <1270257447.53.0.959896862683.issue7780@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 79643. Needs test and documentation.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Apr  3 03:58:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 01:58:37 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1270259917.58.0.786714351961.issue1222585@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think python-LDCXXSHARED.patch is fine.

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

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

From report at bugs.python.org  Sat Apr  3 04:37:45 2010
From: report at bugs.python.org (Clovis Fabricio)
Date: Sat, 03 Apr 2010 02:37:45 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1270262265.64.0.825275058996.issue5712@psf.upfronthosting.co.za>


Changes by Clovis Fabricio <nosklo+python at gmail.com>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Sat Apr  3 05:17:52 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Apr 2010 03:17:52 +0000
Subject: [issue7337] Add lossy queue to queue library module
In-Reply-To: <1258454440.69.0.147012340761.issue7337@psf.upfronthosting.co.za>
Message-ID: <1270264672.28.0.060087914434.issue7337@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think it would be better to put this in the ASPN recipes cookbook to let it mature and gather a following.  Right now, it is not at all clear that this is the right thing to do.

----------
resolution:  -> rejected
status: open -> closed
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Apr  3 05:20:19 2010
From: report at bugs.python.org (Grigory)
Date: Sat, 03 Apr 2010 03:20:19 +0000
Subject: [issue8288] zipfile module documentation misprint
In-Reply-To: <1270216377.49.0.632972257682.issue8288@psf.upfronthosting.co.za>
Message-ID: <1270264819.37.0.242953410456.issue8288@psf.upfronthosting.co.za>


Grigory <matpuk at gmail.com> added the comment:

What about 2.7? I see the issue there too.

----------

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

From report at bugs.python.org  Sat Apr  3 05:20:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Apr 2010 03:20:48 +0000
Subject: [issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to
	just	be a LOAD_CONST
In-Reply-To: <1243466391.88.0.68447044966.issue6133@psf.upfronthosting.co.za>
Message-ID: <1270264848.93.0.166116562741.issue6133@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority:  -> low
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Apr  3 05:24:18 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Apr 2010 03:24:18 +0000
Subject: [issue7764] Doc for itertools recipe consume is complicated and less
	efficient
In-Reply-To: <1264254781.04.0.3391109102.issue7764@psf.upfronthosting.co.za>
Message-ID: <1270265058.48.0.616245522379.issue7764@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

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

From report at bugs.python.org  Sat Apr  3 05:37:15 2010
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Sat, 03 Apr 2010 03:37:15 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>


New submission from Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com>:

multiprocessing.Pool methods map, imap, etc. are said to be able to normally handle exceptions. But it seems that it is true only for synchronous exceptions inside their first func arguments.

When (typically during a long-running parallel map) a user hits ^C, an asynchronous KeyboardInterrupt isn't handled properly and leads to the interpreter hangup. More precisely, children processes become <defunct> (on Linux), so the only way to terminate the whole program is to issue the KILL signal.

As stopping a program with ^C while running potentially long parallel computations is probably quite a common scenario, the interpreter should not hang up in such a case.

I'm using Python 2.6.5 (r265:79063, Mar 23 2010, 04:44:21) [GCC 4.4.3] on linux2. I've also tried to use the current multiprocessing.pool module from the current (2.7) trunk with my 2.6.5 installation, but the bug persists.

----------
components: Library (Lib)
messages: 102219
nosy: vlasovskikh
severity: normal
status: open
title: multiprocessing.Pool hangs when issuing KeyboardInterrupt
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Apr  3 05:39:15 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 03 Apr 2010 03:39:15 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270265955.05.0.321760636846.issue8296@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Do you have a test case which can reproduce the issue?

----------
nosy: +brian.curtin
stage:  -> test needed
type: crash -> behavior

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

From report at bugs.python.org  Sat Apr  3 05:45:54 2010
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Sat, 03 Apr 2010 03:45:54 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270266354.76.0.869187089894.issue8296@psf.upfronthosting.co.za>


Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com> added the comment:

Yes, here is my test case.

----------
Added file: http://bugs.python.org/file16743/test_pool_keyboardinterrupt.py

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

From report at bugs.python.org  Sat Apr  3 05:54:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 03 Apr 2010 03:54:03 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270266843.08.0.171052701164.issue8296@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You might want to take a look here: http://jessenoller.com/2009/01/08/multiprocessingpool-and-keyboardinterrupt/

----------

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

From report at bugs.python.org  Sat Apr  3 06:07:49 2010
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Sat, 03 Apr 2010 04:07:49 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270267669.64.0.789039141805.issue8296@psf.upfronthosting.co.za>


Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com> added the comment:

Yes, I've come up with the same solution by myself, but it cannot cover all the cases of the bug. It works only for cases when ^C is hit during a call to the users' function: http://stackoverflow.com/questions/1408356/keyboard-interrupts-with-pythons-multiprocessing-pool/2561809#2561809

If the user is "lucky", he may hit ^C during getting or putting data into the queues in multiprocessing.pool.worker. To reproduce such a case, you may insert `sleep(10)` before `task = get()` or `put((job, i, result))`, for example. I've encountered such cases just by running test examples several times.

----------

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

From report at bugs.python.org  Sat Apr  3 07:30:08 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 03 Apr 2010 05:30:08 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

It would be nice if the error message for an AttributeError could include the module name when getting from a module -- just like it does for getting from a class.

This would make the message more helpful.  For example, it would help in diagnosing issues like the ones mentioned in this report:

http://bugs.python.org/issue7559

EXAMPLE (using latest from trunk Python 2.7a4+):

import sys

class TestClass(object):
    pass

m = sys
c = TestClass

print "CLASS: %s" % c

try:
    c.asdf
except AttributeError, err:
    print err

print "\nMODULE: %s" % m

try:
    m.adsf
except AttributeError, err:
    print err

***
OUTPUT:

CLASS: <class '__main__.TestClass'>
type object 'TestClass' has no attribute 'asdf'

MODULE: <module 'sys' (built-in)>
'module' object has no attribute 'adsf'

***
The latter message could instead be (paralleling the text in the case of a class)--

module object 'sys' has no attribute 'adsf'

----------
components: Library (Lib)
messages: 102224
nosy: cjerdonek
severity: normal
status: open
title: AttributeError message text should include module name
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  3 07:51:50 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Sat, 03 Apr 2010 05:51:50 +0000
Subject: [issue8298] in what way we have to save tha module?
In-Reply-To: <1270273910.06.0.788971475779.issue8298@psf.upfronthosting.co.za>
Message-ID: <1270273910.06.0.788971475779.issue8298@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

what is the process to save the module in python?

----------
messages: 102225
nosy: krishnalolla
severity: normal
status: open
title: in what way we have to save tha module?

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

From report at bugs.python.org  Sat Apr  3 07:54:45 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Sat, 03 Apr 2010 05:54:45 +0000
Subject: [issue8298] in what way we have to save tha module?
In-Reply-To: <1270273910.06.0.788971475779.issue8298@psf.upfronthosting.co.za>
Message-ID: <1270274085.27.0.390374221671.issue8298@psf.upfronthosting.co.za>


Changes by LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:


----------
type:  -> feature request

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

From report at bugs.python.org  Sat Apr  3 08:15:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Apr 2010 06:15:42 +0000
Subject: [issue8288] zipfile module documentation misprint
In-Reply-To: <1270216377.49.0.632972257682.issue8288@psf.upfronthosting.co.za>
Message-ID: <1270275342.3.0.654847702536.issue8288@psf.upfronthosting.co.za>


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

In 2.x, the method is really called next().

----------

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

From report at bugs.python.org  Sat Apr  3 08:22:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 03 Apr 2010 06:22:02 +0000
Subject: [issue8298] in what way we have to save tha module?
In-Reply-To: <1270273910.06.0.788971475779.issue8298@psf.upfronthosting.co.za>
Message-ID: <1270275722.14.0.869268924456.issue8298@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Hi.

Please don't use the bug tracker to ask Python questions. You've already been asked twice to refer to http://www.python.org/about/help/#got-a-python-problem-or-question . Please read and follow those instructions. Your questions have not been about bugs in Python, so this is not the correct place to ask them.

----------
nosy: +eric.smith
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Apr  3 09:07:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Apr 2010 07:07:38 +0000
Subject: [issue1086642] Compile of _socket fails on IRIX with 2.4
Message-ID: <1270278458.37.0.330152937094.issue1086642@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: pending -> closed

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

From report at bugs.python.org  Sat Apr  3 09:08:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Apr 2010 07:08:39 +0000
Subject: [issue1542308] Nested finally in generators don't follow PEP 342
Message-ID: <1270278519.46.0.989232052818.issue1542308@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> languishing

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

From report at bugs.python.org  Sat Apr  3 09:22:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Apr 2010 07:22:00 +0000
Subject: [issue1518617] PEP101/102 out of date
Message-ID: <1270279320.16.0.564112725085.issue1518617@psf.upfronthosting.co.za>


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

PEP 101 is up to date.  I don't know about 102, it should probably be withdrawn, as 101 has all the info.

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

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

From report at bugs.python.org  Sat Apr  3 09:25:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Apr 2010 07:25:34 +0000
Subject: [issue1944] Documentation for PyUnicode_AsString (et al.) missing.
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1270279534.12.0.190657905518.issue1944@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl

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

From report at bugs.python.org  Sat Apr  3 10:34:16 2010
From: report at bugs.python.org (Ray.Allen)
Date: Sat, 03 Apr 2010 08:34:16 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270283656.21.0.6139548327.issue8297@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Yes, I agree with this feature request. And also the super(Class, obj) call should return a reasonable AttributeError message when the requested attribute is not found in one of Class's base classes, not just 'super' object has no attribute 'xxx'.

----------
nosy: +ysj.ray

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

From report at bugs.python.org  Sat Apr  3 10:44:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 08:44:02 +0000
Subject: [issue8227] Fix C API documentation: Argument parsing
In-Reply-To: <1269475758.09.0.479187943565.issue8227@psf.upfronthosting.co.za>
Message-ID: <1270284242.61.0.847322997376.issue8227@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r79654 (trunk), r79655 (2.7), blocked in py3k and 3.1 (see #8215 and #2322)

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

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

From report at bugs.python.org  Sat Apr  3 10:47:29 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 03 Apr 2010 08:47:29 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1270284449.37.0.382435726268.issue1222585@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

LDCXXSHARED added in r79652 and r79657.

Now we can work on distutils2 side

----------
priority: high -> normal
versions: +Python 3.3

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

From report at bugs.python.org  Sat Apr  3 11:17:20 2010
From: report at bugs.python.org (Ray.Allen)
Date: Sat, 03 Apr 2010 09:17:20 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270286240.56.0.529198549222.issue8297@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

In fact, there are only three types of tp_getattro functions:
    1.For type objects, it is type_getattro(), in case of AttributeError, this function give the message format: 
        type object %(type)s has no attribute %(attr)s
    2.For super objects, it is super_getattro(), in case of no attribute found in one of its base class, it calls the 3'th getattr function below.
    3.For the base type 'object' and other new style class, it is PyObject_GenericGetAttr(), and in case of AttributeError, this function give the message format:
        %(type)s object has no attribute %(attr)s

So, there are only tow formats of AttributeError's exception messages:
    1.type object %(type)s has no attribute %(attr)s
    2.%(type)s object has no attribute %(attr)s
The first one is for type objects, the second one is for all the instances objects.

In most cases, these tow formats it is enough for program to display, bu t it is not well enough. Take the module objects for example, in case of AttributeError, we will always hope to know exactly which module has no attribute, not only the message: 'module object has attribute xxx'.

Also for the super() call, take super(A, b).xxx() for example, if the attribute is not found in the class next to the A in b's type's mro list, PyObject_GenericGetAttr() will be called with the two arguments, the super object its self and 'xxx'. But there are only few valid attributes of a super object, like '__thisclass__', '__self__', '__self_class__'. In most cases, we don't need these attributes of a super object, what we need is the attribute of one of b's type's base types. So I think once the AttributeError is raised in PyObject_GenericGetAttr() call in the end of super_getattro(), the exception message should tell us in which base class python can not found the attribte 'xxx', but not the super object itself, although the exception is raised in the PyObject_GenericGetAttr(<super obj>, 'xxx').

For the solution, I think the type_getattro and super_getattro can just return NULL to indicate the attribute is not found, but for a wrapper function of this tow which is the tp_getattro for each type to raise the attribute error, with the reasonable  exception message. For example, mudule type can tell which module has no attribute, super type can tell which base class has no attribute, and so on.

What about others' opinion?

----------

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

From report at bugs.python.org  Sat Apr  3 12:20:11 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 03 Apr 2010 10:20:11 +0000
Subject: [issue1501108] Add write buffering to gzip
Message-ID: <1270290011.66.0.13851394045.issue1501108@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

In the test script, simply changing 

def emit(f, data=snips):
    for datum in data:
        f.write(datum)

to 

def gemit(f, data=snips):
    datas = ''.join(data)
    f.write(datas)

improves direct gzip performance from
[1.1799781322479248, 0.50524115562438965, 0.2713780403137207]
[1.183434009552002, 0.50997591018676758, 0.26801109313964844]
[1.173914909362793, 0.51325297355651855, 0.26233196258544922]

to

[0.43065404891967773, 0.50007486343383789, 0.26698708534240723]
[0.43662095069885254, 0.49983596801757812, 0.2686460018157959]
[0.43778109550476074, 0.50057196617126465, 0.2687230110168457]

which means that you're better off letting the application handle buffering issues. Furthermore, the problem with gzip-level buffering is the choice of the default buffer size.

Time to close ?

----------
nosy: +neologix

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

From report at bugs.python.org  Sat Apr  3 12:27:25 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 03 Apr 2010 10:27:25 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>


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

This patch does several things:
1) Creates a separate lock type PyThread_type_gil and locking functions for that.  This allows tweaking of the GIL without affecting regular lock behaviour.
2) Creates a uniform implementation of the GIL on windows/pthreads using macros, with emulated condition variables on windows (Lifted Antoine's code from py3k, adding own improvements to the slightly problematic windows implementation).  This makes the GIL behave the same on windows and pthreads platforms, if we so choose, and allows cross-platform development.
3) provide three GIL implementations:
 a) legacy gil, which is the same as the one used on pthreads
 b) a roundrobin gil, which fixes the multicore problem on pthreads and    exhibits the same behaviour as the legacy GIL on windows did (no jumping the gil queue)
 c) a priority based gil, with n given priority levels, and optionally, the ability to request immediate GIL drop by the ceval.c loop.

See thread_gil.h for details of the three modes.

In my experiments using David Beazley's scripts from http://www.dabeaz.com/blog/dablog.html, implementation "b" fixed the performance problems encountered on multicore machines.  This is, I believe, the original impetus for Antoine Pitrou's work on the new GIL.
Implementation "c" improved data transfer still, by allowing faster wakeup of completed IO.

Please note that I was not able to test this patch on a pthreads machine, I can only hope that it compiles :)

----------
components: Interpreter Core
files: gil.patch
keywords: patch, patch
messages: 102234
nosy: beazley, krisvale, pitrou
severity: normal
status: open
title: Improve GIL in 2.7
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file16744/gil.patch

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

From report at bugs.python.org  Sat Apr  3 12:58:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Apr 2010 10:58:11 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270292291.36.0.319450835835.issue8299@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this is too late for 2.7. 2.7b1 will be released RSN, and we should not implement such a change after the first beta release.

----------
nosy: +loewis

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

From report at bugs.python.org  Sat Apr  3 13:01:37 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 03 Apr 2010 11:01:37 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270292497.81.0.953286213736.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> I think in both cases the error text should state not just what module was being imported but also what module was being imported from

FYI, I filed the following report partly in response to some of the comments I made above:

http://bugs.python.org/issue8297

(regarding the AttributeError not displaying the name of the module from which the caller is trying to get the attribute)

----------

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

From report at bugs.python.org  Sat Apr  3 13:26:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Apr 2010 11:26:00 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270293960.54.0.389760339065.issue8279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still get failures, after applying file16727. I'm attaching the complete regrtest output.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file16745/failures

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

From report at bugs.python.org  Sat Apr  3 13:40:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:40:57 +0000
Subject: [issue8294] Allow Fraction constructor to accept float and decimal
	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270294857.76.0.950529578289.issue8294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to py3k in r79670.

----------
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Apr  3 13:41:36 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 03 Apr 2010 11:41:36 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270247238.98.0.791005996157.issue8271@psf.upfronthosting.co.za>
Message-ID: <4BB7296C.3050601@egenix.com>


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

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> Here's a new patch. Should be complete but I want to test it some more before committing.
> I decided to follow RFC 3629, putting 0 instead of 5/6 for bytes in range F5-FD (we can always put them back in the unlikely case that the Unicode Consortium changed its mind) and also for other invalid ranges (e.g. C0-C1). This lead to some simplification in the code.

Ok.

> I also found out that, according to RFC 3629, surrogates are considered invalid and they can't be encoded/decoded, but the UTF-8 codec actually does it. I included tests and fix but I left them commented out because this is out of the scope of this patch, and it probably need a discussion on python-dev.

Right, but that idea is controversial. In Python we need to be able to
put those surrogate code points into source code (encoded as UTF-8) as
well as pickle and marshal dumps of Unicode object dumps, so we can't
consider them invalid UTF-8.

----------

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

From report at bugs.python.org  Sat Apr  3 13:43:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:43:25 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1270295005.05.0.674243407563.issue7279@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r79588 and r79589 were merged to py3k in r79668.

----------
resolution: invalid -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Apr  3 13:44:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:44:18 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1270295058.03.0.0717600283821.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this;  it's too late for Python 2.7.

----------
status: open -> closed
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Apr  3 13:45:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:45:04 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1270295104.19.0.421673306256.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to py3k in r79668.

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

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

From report at bugs.python.org  Sat Apr  3 13:47:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 03 Apr 2010 11:47:22 +0000
Subject: [issue2799] Remove _PyUnicode_AsString(),
	rework _PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
In-Reply-To: <1210329112.66.0.505096173761.issue2799@psf.upfronthosting.co.za>
Message-ID: <1270295242.11.0.568743526457.issue2799@psf.upfronthosting.co.za>


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

Updating the ticket title to what we actually have in SVN (I had renamed the APIs to mark them as private to the interpreter some time ago).

----------
title: Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar() -> Remove _PyUnicode_AsString(), rework _PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

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

From report at bugs.python.org  Sat Apr  3 13:47:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:47:31 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1270295251.71.0.85447009601.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this;  a separate feature request should be opened for the idea of adding __index__ awareness to struct.pack in py3k.

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

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

From report at bugs.python.org  Sat Apr  3 13:51:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:51:47 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>


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

In Python 2.7, struct.pack with an integer format can handle non-integers that provide an __int__ method (although this *does* raise a DeprecationWarning).

Python 2.7a4+ (trunk:79659:79661, Apr  3 2010, 11:28:19) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import pack
[35194 refs]
>>> pack('L', 3.1415)
'\x03\x00\x00\x00\x00\x00\x00\x00'
[35210 refs]

This behaviour isn't particularly desirable for floats or Decimal instances, but it's useful for integer-like objects.

In Python 3.x, there's no provision for handling integer-like objects than aren't actually integers.

I propose that in 3.x, struct.pack should try to convert any non-integer to an integer by using its __index__ method, before packing.

----------
assignee: mark.dickinson
messages: 102245
nosy: mark.dickinson
severity: normal
status: open
title: Allow struct.pack to handle objects with an __index__ method.
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr  3 13:52:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:52:08 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270295528.46.0.892130266703.issue8300@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Extension Modules
stage:  -> test needed
type:  -> feature request

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

From report at bugs.python.org  Sat Apr  3 13:52:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:52:53 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1270295573.43.0.483365536579.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've opened issue 8300 for adding the __index__ handling.

----------
superseder:  -> Allow struct.pack to handle objects with an __index__ method.

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

From report at bugs.python.org  Sat Apr  3 14:11:38 2010
From: report at bugs.python.org (Michel Samia)
Date: Sat, 03 Apr 2010 12:11:38 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1270296698.34.0.423152862736.issue4147@psf.upfronthosting.co.za>


Michel Samia <m.samia at seznam.cz> added the comment:

Could you please apply that patch? People are starting to use non-standard libraries to process xml files because of this issue

for example this man is using lxml or pyxml:
http://ronrothman.com/public/leftbraned/xml-dom-minidom-toprettyxml-and-silly-whitespace/

Is there any problem with that patch?

----------
nosy: +m-samia

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

From report at bugs.python.org  Sat Apr  3 14:32:23 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 03 Apr 2010 12:32:23 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270297943.94.0.379303733439.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Without looking at this patch, I think it would wise to proceed with caution on incorporating any kind of GIL patch into 2.X.  If there is anything to be taken away from my own working studying the GIL, it's that the problem is far more tricky than it looks and that any kind of fix has the potential to adversely affect something that you might not expect.

That said, I would only suggest that any kind of "new gil" incorporated in 2.X be disabled by default and enabled with special configuration options for those who want to try it out.

----------
nosy: +dabeaz

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

From report at bugs.python.org  Sat Apr  3 14:33:37 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Apr 2010 12:33:37 +0000
Subject: [issue1501108] Add write buffering to gzip
Message-ID: <1270298017.91.0.9685661804.issue1501108@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

agreed

----------

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

From report at bugs.python.org  Sat Apr  3 14:33:44 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 03 Apr 2010 12:33:44 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270298024.78.0.637170322151.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Martin: Well, this patch was originally conceived more as a demonstration of the GIL problem and an alternative fix proposal.
However, it is possible to configure it so that there is no change from existing functionality, simply by not including thread_gil.h in thread_pthread.h and thread_nt.h.  The only change would then be the presence of the new PyThread_type_gil and associating locking functions which delegate directly to the old PyThread_type_lock functions.

----------

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

From report at bugs.python.org  Sat Apr  3 14:36:15 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 03 Apr 2010 12:36:15 +0000
Subject: [issue8292] Incorrect condition test in platform.py
In-Reply-To: <1270226918.36.0.398729222231.issue8292@psf.upfronthosting.co.za>
Message-ID: <4BB7363A.9040703@egenix.com>


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

A.M. Kuchling wrote:
> 
> New submission from A.M. Kuchling <lists at amk.ca>:
> 
> While looking at #4440, I grepped for similar problems and found one in
> platform.py in the following line:
> 
> if no_os_uname or not filter(None, (system, node, release, version, machine))
> 
> In 3.x, filter() returns an object, not a list, so 'not filter()' will always be false.  
> 
> One fix is to either convert filter's output by adding list() or tuple(). Another fix could be 'not any ((system, node, release, version, machine))', but I don't know if platform.py is trying to stay compatible with versions of Python that lack any().

I'm trying to keep platform.py compatible with all Python versions
since 2.3, so using the list() wrapper appears to be the better
solution.

----------

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

From report at bugs.python.org  Sat Apr  3 14:37:35 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 03 Apr 2010 12:37:35 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270298255.15.0.238983675567.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Antoine:  Please take a look, the change is really simple, particularly the ROUNDROBIN_GIL variant which fixes the originally observed problem.
the GIL is still a lock, implemented using a mutex and a semaphore.  It is modified to work exactly as the lock always has done on windows (which is why the original problem isn't present on that platform).

The simplicity of the change stems from the fact that the gil is still just a mutex-type object, which is aqcuired and released just as it has always been.  The change is in the internal rules of the mutex, making sure that threads queue up properly and (optionally) that they are released in a priority based order.

----------

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

From report at bugs.python.org  Sat Apr  3 14:45:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Apr 2010 12:45:19 +0000
Subject: [issue1501108] Add write buffering to gzip
Message-ID: <1270298719.05.0.0821442317424.issue1501108@psf.upfronthosting.co.za>


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

Additionally, since issue7471 was fixed, you should be able to wrap a GzipFile in a Buffered{Reader,Writer} object for faster buffering.

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

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

From report at bugs.python.org  Sat Apr  3 14:45:38 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 03 Apr 2010 12:45:38 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270298738.45.0.522970291506.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I'm not sure where you're getting your information, but the original GIL problem *DEFINITELY* exists on multicore Windows machines.   I've had numerous participants try it in training classes and workshops they've all observed severely degraded performance for CPU-bound threads on Windows (XP, Vista, and Windows 7).

----------

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

From report at bugs.python.org  Sat Apr  3 14:55:03 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 03 Apr 2010 12:55:03 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270299303.6.0.270259323048.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Just ran the CPU-bound GIL test on my wife's dual core Windows Vista machine.  The code runs twice as slow using two threads as it does using no threads (original observed behavior in my GIL talk).

----------

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

From report at bugs.python.org  Sat Apr  3 15:04:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Apr 2010 13:04:47 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270298255.15.0.238983675567.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270299999.3761.11.camel@localhost>


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

Kristjan, I agree with Martin, it's probably too late to make such
changes for 2.7.
Additionally, your "round-robin" scheme only seems round-robin when
there are two threads competing. Otherwise, you could have three threads
A, B and C, and the GIL bouncing between A and B.

I would advocate opening a separate issue to improve the Windows
condition variable code under 3.x.

----------

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

From report at bugs.python.org  Sat Apr  3 15:24:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 13:24:15 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270301055.08.0.729640352711.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for trunk.  It combines the docs and tests from Meador Inge's patch in issue 1530559 with a C-level change to get_pylong in Modules/struct.c.

----------
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file16746/struct_index_trunk.patch

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

From report at bugs.python.org  Sat Apr  3 15:25:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 13:25:10 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270301110.51.0.79326504187.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Adding Meador Inge to nosy.

----------
nosy: +minge

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

From report at bugs.python.org  Sat Apr  3 15:32:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 13:32:04 +0000
Subject: [issue8301] Putting a function in a unittest.TestSuite doesn't work
In-Reply-To: <1270301524.85.0.299541369901.issue8301@psf.upfronthosting.co.za>
Message-ID: <1270301524.85.0.299541369901.issue8301@psf.upfronthosting.co.za>


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

Putting functions (rather than TestCase instances) directly in TestSuites was never officially supported but it used to work:

>>> from unittest import TestSuite, TestResult
>>> def f(): pass
... 
>>> s = TestSuite()
>>> s.addTest(f)
>>> s.run(TestResult())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/compile/python-trunk/Lib/unittest/suite.py", line 85, in run
    self._wrapped_run(result)
  File "/compile/python-trunk/Lib/unittest/suite.py", line 100, in _wrapped_run
    self._handleClassSetUp(test, result)
  File "/compile/python-trunk/Lib/unittest/suite.py", line 122, in _handleClassSetUp
    currentClass._classSetupFailed = False
TypeError: can't set attributes of built-in/extension type 'function'

----------
assignee: michael.foord
components: Library (Lib)
messages: 102259
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: Putting a function in a unittest.TestSuite doesn't work
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 15:34:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 13:34:12 +0000
Subject: [issue8302] SkipTest exception in setUpClass or setUpModule is marked
	as an error rather than a skip
In-Reply-To: <1270301652.92.0.301047962487.issue8302@psf.upfronthosting.co.za>
Message-ID: <1270301652.92.0.301047962487.issue8302@psf.upfronthosting.co.za>


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

SkipTest exception in setUpClass or setUpModule is marked as an error rather than a skip.

----------
assignee: michael.foord
messages: 102260
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: SkipTest exception in setUpClass or setUpModule is marked as an error rather than a skip
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 15:39:16 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 03 Apr 2010 13:39:16 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1270301956.96.0.536341826844.issue1441530@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

$ cat /tmp/test.py
import socket

SIZE = 1000000000L

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

try:
    s.recv(SIZE)
finally:
    s.close()

$ python /tmp/test.py
Traceback (most recent call last):
  File "/tmp/test.py", line 8, in <module>
    s.recv(SIZE)
MemoryError

$ strace python /tmp/test.py
[...]
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
mmap2(NULL, 1000001536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x4440c000)                         = 0x8a56000
mmap2(NULL, 1000132608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xb79b1000
munmap(0xb79b1000, 323584)              = 0
munmap(0xb7b00000, 724992)              = 0
mprotect(0xb7a00000, 135168, PROT_READ|PROT_WRITE) = 0
mmap2(NULL, 1000001536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
[...]

imaplib is simply requesting too much at a time: the memory error is probably raised in Modules/socketmodule.c:sock_recv
        /* Allocate a new string. */
        buf = PyString_FromStringAndSize((char *) 0, recvlen);
        if (buf == NULL)
                return NULL;

Requesting a 10M read is indeed quite questionable, and will fail no matter what system is used (the limit will depend on the heap usage and OS, though).
The fix should be made at imaplib level, rather than requiring users to redefine IMAP4 read method. A patch is attached (imaplib_read.diff).

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file16747/imaplib_read.diff

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

From report at bugs.python.org  Sat Apr  3 15:51:46 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 03 Apr 2010 13:51:46 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1270302706.21.0.525509303104.issue1222585@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Removed file: http://bugs.python.org/file16519/python-distutils-C++.patch

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

From report at bugs.python.org  Sat Apr  3 15:57:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 13:57:09 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270303029.02.0.885523101722.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That patch was a bit hasty in many respects;  here's a better one.

For 2.7, the scheme is as follows:  when packing a non-integer with an integer format:

(1) First __index__ is tried
(2) If the __index__ method doesn't exist, or the call to __index__ raises TypeError, then the __int__ method is tried.
(3) If the __index__ method raises something other than TypeError, or returns a non-integer, then struct.pack fails.

----------
Added file: http://bugs.python.org/file16748/struct_index_trunk2.patch

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

From report at bugs.python.org  Sat Apr  3 15:58:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 13:58:52 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270303132.3.0.455270483579.issue8300@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Apr  3 16:06:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 14:06:28 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270303588.58.0.956378385843.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed this patch to trunk in r79674.  Will forward port to py3k.

----------

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

From report at bugs.python.org  Sat Apr  3 16:22:03 2010
From: report at bugs.python.org (Andy Buckley)
Date: Sat, 03 Apr 2010 14:22:03 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1270304523.43.0.288930201363.issue4256@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

That sort of idea, yes: just a wild thought, but it would be really nice if this was available so that in combination with a standard bash/zsh function, getting basic automatic command completion for scripts built with optparse (and any other implementer of such a scheme) was as simple as adding

complete -F _optparse -o default mycmdname

to the completion script library.

The simple scheme you laid out seems fine to me, but in the best bikeshedding tradition it would be useful to distinguish between options which take an argument and those which don't, pre-empt the need for a format version, and make the parsing even easier by removing cosmetic whitespace, commas etc.:

gruszczy at gruszczy-laptop:~/Programs/logbuilder$ ./logbuilder --help-options
#OPTPARSE_FORMAT 0
--version
-h --help
-r= --regexp=
-c= --contains=
-s= --start=
-e= --end=
-f= --file=
-t= --template=
-p= --purge=

Maybe this is just a pipe-dream, but the need to hand-write basic completion scripts seems so unnecessary, just for lack of any (even de-facto) standardisation. As optparse already enforces/encourages many good habits and conventions, some system like this would further help the integration with shell completion.

Or maybe the existing --help output is good enough for a rather more fiddly standard bash completion parsing function. I've tried writing one of these, but it would hard for it be generally robust since the descriptive strings can contain any structure that they feel like, and could hence mess up the pattern-matching. I'm very happy if someone can out-sed me and make that work!

----------

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

From report at bugs.python.org  Sat Apr  3 16:43:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 14:43:22 +0000
Subject: [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: <1270305802.77.0.0073241346145.issue8271@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I also found out that, according to RFC 3629, surrogates 
> are considered invalid and they can't be encoded/decoded, 
> but the UTF-8 codec actually does it.

Python2 does, but Python3 raises an error.

Python 2.7a4+ (trunk:79675, Apr  3 2010, 16:11:36)
>>> u"\uDC80".encode("utf8")
'\xed\xb2\x80'

Python 3.2a0 (py3k:79441, Mar 26 2010, 13:04:55)
>>> "\uDC80".encode("utf8")
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 0: surrogates not allowed

Deny encoding surrogates (in utf8) causes a lot of crashs in Python3, because most functions calling suppose that _PyUnicode_AsString() does never fail: see #6687 (and #8195 and a lot of other crashs). It's not a good idea to change it in Python 2.7, because it would require a huge work and we are close to the first beta of 2.7.

----------
nosy: +haypo

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

From report at bugs.python.org  Sat Apr  3 16:53:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 14:53:26 +0000
Subject: [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: <1270306406.84.0.219067507561.issue8215@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The PEP 3118 describes some points about discontigious buffers, but there is no module nor third party libraries supporting them.

PIL 1.1.7 (the last version) doesn't support the buffer API (an image can not be "exported" as a buffer, but PIL accepts a buffer as input in some functions).

----------

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

From report at bugs.python.org  Sat Apr  3 16:54:13 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 14:54:13 +0000
Subject: [issue8303] python -m unittest -h and python -m unittest discover -h
	message slightly incorrect
In-Reply-To: <1270306453.69.0.686553855544.issue8303@psf.upfronthosting.co.za>
Message-ID: <1270306453.69.0.686553855544.issue8303@psf.upfronthosting.co.za>


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

The usage messages for unittest from the command line are slightly incorrect.

They show: "Usage: unittest [options]" when it should be "Usage: python -m unittest [options]" (or even "python -m unittest discover").

----------
assignee: michael.foord
messages: 102267
nosy: michael.foord
severity: normal
status: open
title: python -m unittest -h and python -m unittest discover -h message slightly incorrect
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 17:01:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 15:01:46 +0000
Subject: [issue8303] python -m unittest -h and python -m unittest discover -h
	message slightly incorrect
In-Reply-To: <1270306453.69.0.686553855544.issue8303@psf.upfronthosting.co.za>
Message-ID: <1270306906.14.0.00223995077559.issue8303@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

In TestProgram.usageExit the command name comes from:

        self.progName = os.path.basename(argv[0])

For test discovery the usage message is auto-generated by optparse. Probably using sys.argv[0].

----------

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

From report at bugs.python.org  Sat Apr  3 17:08:44 2010
From: report at bugs.python.org (AndiDog)
Date: Sat, 03 Apr 2010 15:08:44 +0000
Subject: [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>


New submission from AndiDog <AndiDog at web.de>:

There is inconsistent behavior in time.strftime, comparing Python 2.6 and 3.1. In 3.1, non-ASCII Unicode characters seem to get dropped whereas in 2.6 you can keep them using the necessary Unicode-to-UTF8 workaround.

This should be fixed if it isn't intended behavior.

Python 2.6

>>> time.strftime(u"%d\u200F%A".encode("utf-8"), time.gmtime()).decode("utf-8")
u'03\u200fSaturday'
>>> time.strftime(u"%d\u0041%A".encode("utf-8"), time.gmtime()).decode("utf-8")
u'03ASaturday'

Python 3.1

>>> time.strftime("%d\u200F%A", time.gmtime())
''
>>> len(time.strftime("%d\u200F%A", time.gmtime()))
0
>>> time.strftime("%d\u0041%A", time.gmtime())
'03ASaturday'

----------
components: Library (Lib), Unicode
messages: 102269
nosy: AndiDog
severity: normal
status: open
title: strftime and Unicode characters
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Apr  3 17:24:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:24:42 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>


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

memory_item() function creates a new memoryview object if ndim is different than 1. Example with numpy:

   from numpy import array
   y=array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11])
   y.shape = 3,4
   view=memoryview(y)
   view2 = view[0]
   print type(view2)

Result: <type 'memoryview'>. (Without the shape, ndim equals 1, and view2 is a standard str object.)

The problem is that view attribute of the view2 (PyMemoryViewObject) is not initialized. Extract of memory_item():

        /* Return a new memory-view object */
        Py_buffer newview;
        memset(&newview, 0, sizeof(newview));
        /* XXX:  This needs to be fixed so it actually returns a sub-view */
        return PyMemoryView_FromBuffer(&newview);

"This needs to be fixed" :-/

--

view2 is not initialized and so view2.tolist() does crash.

----------
messages: 102270
nosy: haypo
severity: normal
status: open
title: memoview[0] creates an invalid view if ndim != 1
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 17:25:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:25:58 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1270308358.17.0.760607892768.issue8305@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Full example (using numpy) crashing Python: memoryview_crash.py

----------
Added file: http://bugs.python.org/file16749/memoryview_crash.py

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

From report at bugs.python.org  Sat Apr  3 17:26:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:26:35 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1270308395.2.0.731910861085.issue8305@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Interpreter Core
type:  -> crash

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

From report at bugs.python.org  Sat Apr  3 17:26:35 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 15:26:35 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1270308395.73.0.0909964770085.issue7723@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Sat Apr  3 17:26:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 15:26:36 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1270308396.39.0.0691351869224.issue3928@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think this small change can slip in after beta.

----------
nosy: +benjamin.peterson
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sat Apr  3 17:27:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 15:27:14 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1270308434.3.0.462154723885.issue7319@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Lowering priority.

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

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

From report at bugs.python.org  Sat Apr  3 17:27:35 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 15:27:35 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1270308455.81.0.388667628987.issue7092@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Sat Apr  3 17:28:35 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 15:28:35 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1270308515.81.0.260409063208.issue7755@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Lowering priority.

----------
nosy: +benjamin.peterson
priority: release blocker -> critical

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

From report at bugs.python.org  Sat Apr  3 17:34:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Apr 2010 15:34:34 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1270308874.86.0.215812210405.issue3778@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think Installer has features to remove registry keys with no subkeys; we probably would need to declare that we create these keys, and then Installer might remove them automatically.

----------

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

From report at bugs.python.org  Sat Apr  3 17:37:48 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 03 Apr 2010 15:37:48 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270309068.18.0.720455881047.issue8279@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

It looks like all of the failures were due to gdb.Frame not having a "function" method.

I did some digging, and it appears that this attribute may not yet be in the upstream version of gdb.

The gdb/python integration was largely implemented by colleagues of mine at Red Hat, and Fedora's build of gdb is closely tracking their work.

It looks to me like only a subset of their work has been merged into upstream gdb so far. Specifically http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/gdb-archer.patch?revision=1.40&view=markup (warning: large) contains a hunk that applies to gdb/python/py-frame.c which adds "frapy_function".

So it appears that I've unwittingly coded this to a very recent pre-merge version of gdb.

Sorry about this.

What is the output of "gdb --version" on this machine?

What happens if you run:
$ gdb --batch --eval-command "python print gdb.Frame.function" --eval-command "python print dir(gdb.Frame)"

For reference, on Fedora 12 I see:
[david at surprise ~]$ gdb --version
GNU gdb (GDB) Fedora (7.0.1-33.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

[david at surprise ~]$ gdb --batch --eval-command "python print gdb.Frame.function" --eval-command "python print dir(gdb.Frame)"
<method 'function' of 'gdb.Frame' objects>
['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'block', 'find_sal', 'function', 'is_valid', 'name', 'newer', 'older', 'pc', 'read_var', 'select', 'type', 'unwind_stop_reason']



On Fedora 13:
[david at f13 ~]$ gdb --version
GNU gdb (GDB) Fedora (7.0.50.20100203-15.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

[david at f13 ~]$ gdb --batch --eval-command "python print gdb.Frame.function" --eval-command "python print dir(gdb.Frame)"
<method 'function' of 'gdb.Frame' objects>
['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'block', 'find_sal', 'function', 'is_valid', 'name', 'newer', 'older', 'pc', 'read_var', 'select', 'type', 'unwind_stop_reason']


The code works for me on both of these machines; all tests pass.


Assuming that my analysis above is correct, then I'd expect other builds of gdb not to have the gdb.Frame.function method.

This method is critical for the libpython.py:Frame class, and so without it the various extension commands aren't going to be usable.   The pretty-printers ought to still work.

The fix would be to detect the presence of gdb.Frame.function, and enable/disable the commands and their selftests accordingly, assuming that it's OK to add a conditional dependency on code that isn't merged into gdb's trunk yet.

I'll do a patch for this.

----------

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

From report at bugs.python.org  Sat Apr  3 17:39:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:39:00 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1270309140.04.0.0163722659577.issue7433@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I can try to cook up a patch fixing this.

Did you wrote something? I don't see any patch attached to this issue :-/

----------
nosy: +haypo

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

From report at bugs.python.org  Sat Apr  3 17:44:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:44:57 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1270309497.98.0.236552116888.issue8305@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

According to #2394, the implementation of the new buffer API is not complete.

----------
nosy: +teoliphant

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

From report at bugs.python.org  Sat Apr  3 17:45:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Apr 2010 15:45:52 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270309068.18.0.720455881047.issue8279@psf.upfronthosting.co.za>
Message-ID: <4BB762AC.4020104@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What is the output of "gdb --version" on this machine?

GNU gdb (GDB) 7.0.1-debian
This GDB was configured as "x86_64-linux-gnu".

The debian package is 7.0.1-2

> $ gdb --batch --eval-command "python print gdb.Frame.function"
> --eval-command "python print dir(gdb.Frame)"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: type object 'gdb.Frame' has no attribute 'function'
Error while executing Python code.
['__class__', '__delattr__', '__doc__', '__eq__', '__ge__',
'__getattribute__', '__gt__', '__hash__', '__init__', '__le__',
'__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__str__', 'is_valid', 'name', 'newer',
'older', 'pc', 'read_var', 'type', 'unwind_stop_reason']

> The fix would be to detect the presence of gdb.Frame.function, and
> enable/disable the commands and their selftests accordingly, assuming
> that it's OK to add a conditional dependency on code that isn't
> merged into gdb's trunk yet.

That would be fine, I think. Please add a comment saying that gdb 7.0.1
didn't have this feature yet.

----------

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

From report at bugs.python.org  Sat Apr  3 17:46:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:46:06 +0000
Subject: [issue6409] 2to3 -j 4 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1270309566.94.0.551360654969.issue6409@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: 2to3 generates malformed diffs -> 2to3 -j 4 generates malformed diffs

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

From report at bugs.python.org  Sat Apr  3 17:52:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:52:06 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1270309926.7.0.974088802951.issue7696@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

memoryview() function is not documented in library/functions.rst, whereas it's a builtin function.

----------

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

From report at bugs.python.org  Sat Apr  3 18:05:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 03 Apr 2010 16:05:03 +0000
Subject: [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270310703.34.0.195620881745.issue8304@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Sat Apr  3 18:10:16 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 03 Apr 2010 16:10:16 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1270311016.49.0.364995999373.issue4256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I'll take a look at optparse code and try to provide a patch. But first holidays must finish and I must come back to ma usual residence, where I have programming environment.

----------

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

From report at bugs.python.org  Sat Apr  3 18:41:58 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 16:41:58 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270312918.16.0.230205645892.issue8108@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Sat Apr  3 18:57:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 16:57:48 +0000
Subject: [issue8306] ctypes.create_string_buffer should only accept bytes
In-Reply-To: <1270313868.4.0.365365163519.issue8306@psf.upfronthosting.co.za>
Message-ID: <1270313868.4.0.365365163519.issue8306@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

These coercions shouldn't be allowed:

import ctypes
>>> buf = ctypes.create_string_buffer("hi")
>>> buf.value
b'hi'
>>> buf.value = "23"
>>> buf.value
b'23'

----------
assignee: theller
components: ctypes
messages: 102282
nosy: benjamin.peterson, theller
severity: normal
status: open
title: ctypes.create_string_buffer should only accept bytes
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr  3 19:08:50 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 17:08:50 +0000
Subject: [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: <1270314530.66.0.496322112921.issue8032@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Could I request that the python-gdb.py script not be put in the top level directory? It's a little annoying to have another executable script starting with "python" when you're trying to test the "python" executable.

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

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

From report at bugs.python.org  Sat Apr  3 19:19:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Apr 2010 17:19:53 +0000
Subject: [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: <1270315193.53.0.717060981723.issue8032@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That is tricky to do. gdb will consider it automatically only if it is called <exename>-gdb.py.

I agree that there should be a better solution, though. David, is it possible to somehow hook this into .gdbinit, with an arbitrary path?

Benjamin, would a .gdbinit in the top-level build directory still be annoying?

----------

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

From report at bugs.python.org  Sat Apr  3 19:27:14 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 03 Apr 2010 17:27:14 +0000
Subject: [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: <1270315634.43.0.210763919591.issue8032@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

http://sourceware.org/gdb/current/onlinedocs/gdb/Auto_002dloading.html says "If this file exists and is readable, gdb will evaluate it as a Python script." So maybe it doesn't need to be executable?

----------

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

From report at bugs.python.org  Sat Apr  3 19:31:45 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 17:31:45 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1270315193.53.0.717060981723.issue8032@psf.upfronthosting.co.za>
Message-ID: <t2o1afaf6161004031031x9e7d24e1v6fe7bc1893b59927@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/4/3 Martin v. L?wis <report at bugs.python.org>:
> Benjamin, would a .gdbinit in the top-level build directory still be annoying?

That would be fine with me.

----------

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

From report at bugs.python.org  Sat Apr  3 19:39:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Apr 2010 17:39:08 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1270316348.51.0.0718358670517.issue8218@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I do know something about web development, so I did a more extensive edit.  I'm not saying I've brought it completely up to date or fixed any inaccuracies, but I did change the tone here and there, tightened up a bunch of the language, clarified a few things, and updated a few statements.

----------
Added file: http://bugs.python.org/file16750/webservers_howto.patch

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

From report at bugs.python.org  Sat Apr  3 20:58:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Apr 2010 18:58:24 +0000
Subject: [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: <1270321104.86.0.407026309884.issue8032@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now changed Makefile.pre.in to not install python-gdb.py as a script anymore; this seems to work fine. People will still need to remove there existing python-gdb.py (or make clean) to see this change.

----------

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

From report at bugs.python.org  Sat Apr  3 21:03:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 19:03:49 +0000
Subject: [issue7772] test_py3kwarn fails when running the whole test suite
In-Reply-To: <1264358547.08.0.209937802024.issue7772@psf.upfronthosting.co.za>
Message-ID: <1270321429.91.0.279514342149.issue7772@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This still seems to be an issue for OS X.  With the current trunk (r79716), I get:

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe -3 ./Lib/test/regrtest.py test_macostools test_py3kwarn
test_macostools
/Users/dickinsm/python/svn/trunk/Lib/importlib/__init__.py:37: DeprecationWarning: In 3.x, the MacOS module is removed.
  __import__(name)
/Users/dickinsm/python/svn/trunk/Lib/test/test_macostools.py:10: DeprecationWarning: In 3.x, the Carbon package is removed.
  import Carbon.File
/Users/dickinsm/python/svn/trunk/Lib/test/test_macostools.py:11: DeprecationWarning: In 3.x, the macostools module is removed.
  import macostools
test_py3kwarn
test test_py3kwarn failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_py3kwarn.py", line 387, in test_platform_specific_removals
    self.check_removal(module_name, optional=True)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_py3kwarn.py", line 376, in check_removal
    .format(module_name))
AssertionError: DeprecationWarning not raised for MacOS

1 test OK.
1 test failed:
    test_py3kwarn
[40996 refs]

----------
nosy: +mark.dickinson
status: closed -> open

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

From report at bugs.python.org  Sat Apr  3 22:01:45 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Sat, 03 Apr 2010 20:01:45 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270324905.17.0.560782094369.issue8299@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Silly question, I know, but why isn't the GIL just implemented as a lock of the host operating system? After all, we want mutual exclusion, I don't see why condition variables are required for this.

I have to admin that I did not look at the source, so the reason might be documented there.

----------
nosy: +torsten

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

From report at bugs.python.org  Sat Apr  3 22:11:03 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 03 Apr 2010 20:11:03 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270325463.67.0.358156110676.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

It's not a simple mutex because if you did that, you would have performance problems much worse than those described in issue 7946.  http://bugs.python.org/issue7946

----------

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

From report at bugs.python.org  Sat Apr  3 22:15:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Apr 2010 20:15:17 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270325717.77.0.0159123243724.issue8108@psf.upfronthosting.co.za>


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

I don't think this should be a release blocker for the beta, although I agree it should be one for the final release (and RCs).
By the way, it doesn't affect maintenance branches.

----------
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Apr  3 22:16:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Apr 2010 20:16:42 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270325802.96.0.0169081306233.issue8108@psf.upfronthosting.co.za>


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

Giampaolo, which call exactly triggers the "error: [Errno 0] Error"?
It doesn't seem it can be _sslobj.shutdown itself.

----------

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

From report at bugs.python.org  Sat Apr  3 22:44:34 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 20:44:34 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270327474.26.0.797070294421.issue8108@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Sat Apr  3 23:00:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 21:00:21 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>


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

I'm seeing a very peculiar test_pep263 failure when doing 'make test' on OS X 10.6.3.  It's enough to run test___all__ and test_pep263, in that order:

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py test___all__ test_pep263
test___all__
/Users/dickinsm/python/svn/trunk/Lib/test/test___all__.py:3: DeprecationWarning: in 3.x, the bsddb module has been removed; please use the pybsddb project instead
  import bsddb
/Users/dickinsm/python/svn/trunk/Lib/bsddb/__init__.py:67: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  import _bsddb
test_pep263
test test_pep263 failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_pep263.py", line 39, in test_issue7820
    self.assertRaises(SyntaxError, eval, '\xff\x20')
  File "/Users/dickinsm/python/svn/trunk/Lib/unittest/case.py", line 444, in assertRaises
    callableObj(*args, **kwargs)
  File "<string>", line 1, in <module>
NameError: name '?' is not defined

1 test OK.
1 test failed:
    test_pep263
[218378 refs]


The failing test is expecting a SyntaxError, but gets a NameError instead.  I've narrowed down the cause of the failure to a Tkinter import:

Python 2.7a4+ (trunk:79716, Apr  3 2010, 20:30:09) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> eval('\xff\x20')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    ? 
    ^
SyntaxError: invalid syntax
[35036 refs]
>>> import Tkinter
[51314 refs]
>>> eval('\xff\x20')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name '?' is not defined
[51324 refs]

But I'm now mystified:  why does the eval raise a SyntaxError before the import and a TypeError afterwards?

----------
messages: 102294
nosy: mark.dickinson
severity: normal
status: open
title: test_pep263 failure on OS X
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  3 23:00:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 21:00:53 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270328453.06.0.785240501816.issue8307@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That should be "NameError" in the last line of the previous message, not "TypeError".

----------

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

From report at bugs.python.org  Sat Apr  3 23:07:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Apr 2010 21:07:41 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1270328861.8.0.567399582972.issue7696@psf.upfronthosting.co.za>


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

> This is quite obscure because there's no definition of the "buffer 
> protocol".

You can find it at http://www.python.org/dev/peps/pep-3118/#id5 (assuming it is not outdated)

> the memoryview.suboffsets attribute is not documented on the "6.10 
> memoryview Type" page

I don't know what it does.

By the way, I don't really know how to do links and glossary entries. I suppose someone else knows (and enjoys) ReST formatting better than I do.

----------
assignee: pitrou -> teoliphant
nosy: +teoliphant

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

From report at bugs.python.org  Sat Apr  3 23:17:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Apr 2010 21:17:16 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1270329436.02.0.597840180441.issue7696@psf.upfronthosting.co.za>


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

> memoryview() function is not documented in library/functions.rst

You should look more carefully...
See http://docs.python.org/dev/library/functions.html#max
(I don't know why it doesn't have its own anchor, though)

----------

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

From report at bugs.python.org  Sat Apr  3 23:49:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Apr 2010 21:49:48 +0000
Subject: [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270331388.86.0.383357717243.issue8304@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This seems to be fixed now, on both 3.1 and 3.2.
Can you try with 3.1.2 and see if it works?
What operating system are you using?

----------
nosy: +ezio.melotti
priority:  -> normal
status: open -> pending
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Apr  4 00:07:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Apr 2010 22:07:36 +0000
Subject: [issue8208] test_issue7820 fails: "name '?' is not defined"
In-Reply-To: <1269323557.38.0.386457412233.issue8208@psf.upfronthosting.co.za>
Message-ID: <1270332456.08.0.971882854912.issue8208@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Duplicated in Issue8307

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sun Apr  4 00:12:43 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Apr 2010 22:12:43 +0000
Subject: [issue8208] test_issue7820 fails: "name '?' is not defined"
In-Reply-To: <1269323557.38.0.386457412233.issue8208@psf.upfronthosting.co.za>
Message-ID: <1270332763.11.0.81910150877.issue8208@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Apr  4 00:13:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Apr 2010 22:13:33 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270332813.9.0.667699721005.issue8307@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #8208.

----------
components: +Tests
nosy: +ezio.melotti, haypo, l0nwlf, ned.deily
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Sun Apr  4 00:14:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 22:14:01 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270332841.42.0.704748949397.issue8307@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

After some more digging, it looks as though this is due to the Tkinter import (that ends up happening as a result of test___all__) changing the locale(?), and in particular the meaning of isalpha:

Python 2.7a4+ (trunk:79716, Apr  3 2010, 22:06:18) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> str.isalpha(chr(255))
False
[34999 refs]
>>> import Tkinter
[51283 refs]
>>> str.isalpha(chr(255))
True
[51283 refs]


(Is there some way that I can see the locale change more explicitly from Python?)

----------

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

From report at bugs.python.org  Sun Apr  4 00:18:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 22:18:14 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270333094.64.0.0877351596977.issue8307@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> (Is there some way that I can see the locale change more explicitly from Python?)

Found it.  :)

>>> locale.nl_langinfo(locale.CODESET)
'US-ASCII'
[40683 refs]
>>> import Tkinter
[56953 refs]
>>> locale.nl_langinfo(locale.CODESET)
'UTF-8'
[56953 refs]

----------

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

From report at bugs.python.org  Sun Apr  4 00:21:43 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Apr 2010 22:21:43 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270333303.0.0.665271578604.issue8297@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> low
stage:  -> needs patch

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

From report at bugs.python.org  Sun Apr  4 00:23:33 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Apr 2010 22:23:33 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270333413.03.0.298738515752.issue8307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Or this:

Python 2.7a4+ (trunk, Apr  3 2010, 15:18:51) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getlocale()
(None, None)
>>> import Tkinter
>>> locale.getlocale()
('en_US', 'UTF8')

----------

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

From report at bugs.python.org  Sun Apr  4 00:25:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 22:25:45 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270333545.82.0.556420422874.issue8307@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I realize that the above doesn't really explain why the NameError is occurring:

Python's token recognition algorithm, in tok_get in tokenizer.c, uses isalpha, which is locale-aware.  In particular, it seems that chr(255) is considered alphabetic in the UTF-8 codeset, and not in ASCII.

Should this instance of isalpha be replaced by something that's not locale aware?  I'm not sure what the rules are supposed to be in 2.x for recognising identifiers.

----------

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

From report at bugs.python.org  Sun Apr  4 00:26:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 22:26:32 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270333592.24.0.254175384591.issue8307@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ned: yes, that works too.  Thanks!

----------

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

From report at bugs.python.org  Sun Apr  4 00:36:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Apr 2010 22:36:54 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1270334214.74.0.543011722416.issue4256@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please target argparse rather than optparse, or better yet in addition to optparse.  And I'm +1 for making it easier to write completion scripts.

----------
nosy: +bethard, r.david.murray

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

From report at bugs.python.org  Sun Apr  4 01:23:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Apr 2010 23:23:12 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270336992.77.0.068622302609.issue8307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

For the record, the problem here isn't new to trunk and is not limited to OS X 10.6; it's the test that's new.  It's not a problem for py3k where, as expected, the locale is always set and it seems the tokenizer is a little smarter:

Python 3.2a0 (py3k, Apr  3 2010, 16:02:28) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> eval(b'\xff\x20')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    ? 
    ^
SyntaxError: invalid character in identifier

----------

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

From report at bugs.python.org  Sun Apr  4 01:40:18 2010
From: report at bugs.python.org (John Machin)
Date: Sat, 03 Apr 2010 23:40:18 +0000
Subject: [issue8308] raw_bytes.decode('cp932') -- spurious mappings
In-Reply-To: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>
Message-ID: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

According to the following references, the bytes 80, A0, FD, FE, and FF are not defined in cp932:

http://msdn.microsoft.com/en-au/goglobal/cc305152.aspx
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003&s=ALL

However CPython 3.1.2 does this:

 >>> print(ascii(b'\x80\xa0\xfd\xfe\xff'.decode('cp932')))
 '\x80\uf8f0\uf8f1\uf8f2\uf8f3'

(as do 2.5, 2.6. and 2.7 with the appropriate syntax)

This maps 80 to U+0080 (not very useful) and maps the other 4 bytes into the Private Use Area ("PUA")!! Each case should be treated as undefined/unexpected/error/...

----------
components: Unicode
messages: 102308
nosy: sjmachin
severity: normal
status: open
title: raw_bytes.decode('cp932') -- spurious mappings
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Apr  4 01:44:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Apr 2010 23:44:02 +0000
Subject: [issue8308] raw_bytes.decode('cp932') -- spurious mappings
In-Reply-To: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>
Message-ID: <1270338242.48.0.344377548018.issue8308@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Sun Apr  4 02:00:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Apr 2010 00:00:06 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270339206.77.0.583584249098.issue8307@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Verified that r79725 fix to tokenizer.c prevents the original test failure.

----------

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

From report at bugs.python.org  Sun Apr  4 02:08:47 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Apr 2010 00:08:47 +0000
Subject: [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270339727.61.0.347459159593.issue8304@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Actually the bug seems related to Windows.

----------
components: +Windows
nosy: +brian.curtin
status: pending -> open
versions: +Python 3.2

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

From report at bugs.python.org  Sun Apr  4 02:38:07 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 04 Apr 2010 00:38:07 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270341487.66.0.0219258682559.issue8300@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I may be missing something subtle, but how can 'PyNumber_Index(v) != NULL' *and* '!PyInt_Check(v) && !PyLong_Check(v)' both be satisfied in the 'get_pylong' mods?  It seems to me that 'PyNumber_Index' only returns non-NULL when the object being returned is an 'int' or 'long'.  

Attached a patch with the extra check removed and a few more test cases.

----------
Added file: http://bugs.python.org/file16751/struct_index_trunk3.patch

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

From report at bugs.python.org  Sun Apr  4 03:04:34 2010
From: report at bugs.python.org (Derek O'Connor)
Date: Sun, 04 Apr 2010 01:04:34 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>


New submission from Derek O'Connor <derekroconnor at eircom.net>:

Dell Precision 690, Intel 2xQuad-Core E5345  @ 2.33GHz
16GB RAM, Windows7 64-bit Professional.

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) 
[MSC v.1500 32 bit (Intel)] on win32

>>> from math import sin
>>> sin(1e22)
0.41214336710708466   (WRONG)
>>>

Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39)
[MSC v.1500 64 bit (AMD64)] on win32

>>> from math import sin
>>> sin(1e22)
-0.8522008497671888  (CORRECT)

The correct result, rounded to 20 digits is

 sin(10^22) = -8.5220 08497 67188 80177 e-001

Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is

10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22

Hence fl(10^22) = 10^22, whereas fl(10^23) ~= 10^23.

This incorrect result suggests that the range-reduction step, where the argument x is reduced to lie in a small interval around 0, such as [-pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect.

Yours sincerely,

Derek O'Connor

----------
components: Library (Lib)
messages: 102312
nosy: derekroconnor
severity: normal
status: open
title: Sin(x) is Wrong
type: performance
versions: Python 3.1

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

From report at bugs.python.org  Sun Apr  4 03:05:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Apr 2010 01:05:57 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270343157.66.0.890897234323.issue8309@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +mark.dickinson
stage:  -> test needed

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

From report at bugs.python.org  Sun Apr  4 03:25:54 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Apr 2010 01:25:54 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270344354.89.0.252439273721.issue8279@psf.upfronthosting.co.za>


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

This may be related to test_gdb problems I am seeing (test_gdb output attached).


gdb details:

GNU gdb (GDB) 7.0-ubuntu
This GDB was configured as "x86_64-linux-gnu".

After applying Dave's second patch, those original errors go away, but I get a lot of failures of the form:

AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

(Will upload the test output for the second patch shortly - I'm out of town for the next couple of days, so I won't be able to look at this again until next week)

----------
nosy: +ncoghlan
Added file: http://bugs.python.org/file16752/_svn_79729_test_gdb_errors_amd64_ubuntu_9.10.log

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

From report at bugs.python.org  Sun Apr  4 03:26:34 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Apr 2010 01:26:34 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270344394.14.0.0326670577231.issue8279@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file16753/_svn_79729_plus_dm_patch2_test_gdb_errors_amd64_ubuntu_9.10.log

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

From report at bugs.python.org  Sun Apr  4 03:33:36 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Apr 2010 01:33:36 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270344816.38.0.94537069943.issue8279@psf.upfronthosting.co.za>


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

Second error log attached (and the MIME type should finally be set properly to let it display as a text file in the browser)

----------

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

From report at bugs.python.org  Sun Apr  4 03:33:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 04 Apr 2010 01:33:48 +0000
Subject: [issue5479] Add an easy way to provide total ordering now that
	__cmp__ is deprecated/gone
In-Reply-To: <1236845917.79.0.765415316549.issue5479@psf.upfronthosting.co.za>
Message-ID: <1270344828.75.0.496434468444.issue5479@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r79730.

Leaving open until tests are written and all is forward ported to 3.2.

----------
versions:  -Python 3.1

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

From report at bugs.python.org  Sun Apr  4 05:26:18 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 04 Apr 2010 03:26:18 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1270351578.58.0.631291191254.issue4256@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Someone pointed this out to me earlier:

http://pypi.python.org/pypi/genzshcomp

I believe it's trying to solve the same problem, and claims to work with both optparse and argparse, so it might be worth looking into what it's doing and seeing if there's a useful patch that could be proposed for argparse.

----------

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

From report at bugs.python.org  Sun Apr  4 05:26:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Apr 2010 03:26:17 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1270351577.11.0.604262228605.issue4868@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Apr  4 05:30:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 03:30:35 +0000
Subject: [issue7583] doctest should normalize tabs when comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270351835.51.0.451402114701.issue7583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think I can see how it would cause confusion, and in general it shouldn't be necessary to use real tabs in a doctest.  So as you say the output should be fixed to match.

However, I don't think the patch is quite correct.  It looks to me like the expandtabs call should be made unconditionally on the output string just like it is on the string pulled from the file.  The reason is that the tabs in the output should be expanded relative to the start of the output line.  The indentation is meaningless in that context.  The way you did it, the output in your test appears to be indented incorrectly.  If the expandtabs were done on the raw output string, it would be indented eight spaces from the start of the test indent, and that would look correct.

Your change of 'iff' to 'if' is also most likely incorrect.  I'm pretty sure that 'iff' is intentional (it is an abbreviation for "if and only if".)

----------
assignee:  -> r.david.murray
resolution:  -> accepted
stage:  -> patch review

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

From report at bugs.python.org  Sun Apr  4 05:36:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 03:36:59 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270352219.42.0.315980105853.issue7585@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your last patch looks the best to me.  I agree both that a tab should not be emitted if there is no date (which is what git, for example, does), and that ISO 8601 timestamps should be promoted as the preferred format.

As you pointed out, issue 7583 needs to be resolved before this can be applied.

In the meantime it would be nice to add an additional test for the no-tab-if-no-date case.

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
resolution:  -> accepted
stage: patch review -> test needed

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

From report at bugs.python.org  Sun Apr  4 06:36:21 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 04 Apr 2010 04:36:21 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270355781.99.0.394967734102.issue8309@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I believe python is fully at mercy of underlying system math library.

And as a matter of fact, this C program

#include <math.h>
#include <stdio.h>
main() { printf("%.6f\n", sin(1e22)); }

when compiled as 64-bit app (on linux) produces "-0.852201", but when it's compiled as a 32-bit app on the same machine (gcc -m32), it produces "0.462613".

So I don't think this is a bug in python.

----------
nosy: +isandler

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

From report at bugs.python.org  Sun Apr  4 07:41:55 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 04 Apr 2010 05:41:55 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270359715.09.0.704885092784.issue8309@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith
type: performance -> behavior

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

From report at bugs.python.org  Sun Apr  4 07:49:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Apr 2010 05:49:19 +0000
Subject: [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: <1270360159.99.0.657484109192.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This new patch (v3) should be ok. 
I added a few more tests and found another corner case:
'\xe1a'.decode('utf-8', 'replace') was returning u'\ufffd' because \xe1 is the start byte of a 3-byte sequence and there were only two bytes in the string. This is now fixed in the latest patch.

I also unrolled all the loops except the first one because I haven't found an elegant way to unroll it (yet).

Finally, I changed the error messages to make them clearer:
unexpected code byte -> invalid start byte;
invalid data -> invalid continuation byte.
(I can revert this if the old messages are better or if it is better to fix this with a separate commit.)

The performances seem more or less the same, I did some benchmarks without significant changes in the results. If you have better benchmarks let me know. I used a file of 320kB with some ASCII, ASCII mixed with some accented characters, Japanese and a file with a sample of several different Unicode chars.

----------
Added file: http://bugs.python.org/file16754/issue8271v3.diff

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

From report at bugs.python.org  Sun Apr  4 08:59:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Apr 2010 06:59:16 +0000
Subject: [issue8308] raw_bytes.decode('cp932') -- spurious mappings
In-Reply-To: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>
Message-ID: <1270364356.24.0.229106708222.issue8308@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This mapping is in conformance with the de-facto standard of that encoding, Microsoft Windows, see

http://www.autumn.org/etc/unidif.html
http://mail.python.org/pipermail/i18n-sig/2003-June/001598.html
http://homepage1.nifty.com/nomenclator/perl/ShiftJIS-CP932-MapUTF.html

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Apr  4 09:03:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 07:03:07 +0000
Subject: [issue7583] doctest should normalize tabs when comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270364587.42.0.809798352611.issue7583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Having thought about it some more, I see why you did the patch the way you did.

The fact that there are two completely different ways to expand tabs in the output that are equally valid and have their advantages and disadvantages makes me wonder if this should be fixed at all.  Perhaps it is better to just say that you can only handle tabs in output by ignoring whitespace.

----------
resolution: accepted -> 

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

From report at bugs.python.org  Sun Apr  4 09:06:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 07:06:46 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270364806.6.0.553004144813.issue7585@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We could avoid the 7583 problem by making the doctests use NORMALIZE_WHITESPACE and moving the real *tests* into the unittests for the module.  I think that would be a good thing to do anyway.

----------

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

From report at bugs.python.org  Sun Apr  4 10:17:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 08:17:41 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270369061.25.0.344557574619.issue8309@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What Ilya Sandler said!

Computing sin or cos with large arguments requires high precision for the intermediate calculations (e.g., for sin(1e22) you'd need around 40 digits of precision for the reduction step), so most math libraries don't bother.  

This is also the reason that Intel's x87 FSIN instruction (which may or may not be being used here) requires that the argument be in the range -2**63 to 2**63.

Short of Python using its own math library, or adding a dependence on a correctly rounded math library like MPFR or crlibm, there's no real way to fix this.

Out of curiosity, what application do you have that requires evaluating sin for such large arguments?

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Apr  4 10:34:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 08:34:34 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270370074.54.0.299825522165.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Probably both those conditions can't be satisfied;  I'm wasn't sure what happened if something's __index__ method returned something other than an int or long.

But now I bother to look at the source (in Objects/abstract.c) I see that there *is* already an explicit check for the result of nb_index being int or long (with TypeError being raised if the result isn't one of those).  Mea culpa.  I'll remove those lines (though I may leave an assert, just to be on the safe side).

The 2.x behaviour isn't ideal:  I'd prefer to just stop if the __index__ method is present and raises TypeError, rather than going on to check __int__ in that case.  But that presents problems with old-style classes, where PyIndex_Check is true even when no __index__ method is explicitly defined.

Thanks for the extra tests!

----------

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

From report at bugs.python.org  Sun Apr  4 10:44:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 08:44:17 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270370657.93.0.678554026728.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed (with some tabs in test_struct.py changed to spaces) to trunk in r79745.

----------

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

From report at bugs.python.org  Sun Apr  4 10:54:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 08:54:00 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270371240.74.0.622809693452.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to py3k in r79746.

Meador, does this all look okay, now?

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Sun Apr  4 11:20:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 09:20:11 +0000
Subject: [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270372811.67.0.747137403669.issue8307@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, Benjamin's checkin seems to have fixed it for me, too.  Thanks, Benjamin!

There's still the issue of the Tkinter import changing the locale, but that seems to be out of Python's control.  As far as I can tell, it happens when the module initialization calls Tcl_FindExecutable, which is part of the Tcl library itself.  This may well be deliberate:  see

http://www.tcl.tk/cgi-bin/tct/tip/66.html

Closing.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun Apr  4 11:44:52 2010
From: report at bugs.python.org (Derek O'Connor)
Date: Sun, 04 Apr 2010 09:44:52 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270374292.31.0.911570723835.issue8309@psf.upfronthosting.co.za>


Derek O'Connor <derekroconnor at eircom.net> added the comment:

Reply to Mark Dickinson

Python 3.1.2 -- 32 bit gives sin(2^60) = -0.7391806966492228
PariGp 2.3.4           gives sin(2^60) = -0.8306492176372546505752817956

So it seems Intel's x87 FSIN is not being used.

Application? I don't have one, but it is not too hard to imagine that buried deep in a large simulation, sin(x) is presented with a large argument, and whose wrong result is never noticed until ...

I quote from Ng's paper :
http://www.derekroconnor.net/Software/Ng--ArgReduction.pdf
--------------------------
"It is often argued that being concerned  about  large  arguments
is  unnecessary, because sophisticated users simply know better 
than to compute with large  angles.  It  is  our contention that this position is suboptimal, because:

    1. It places an unnecessary burden on the user.

    2. The consequences of producing incorrect (inaccurate)answers
       may be catastrophic;  many people assume that computers can
       do arithmetic very well.  While  numerical  analysts know better,
       not all programmers are numerical analysts, nor should they be.

    3. It is a vendors responsibility  to  provide  answers that
       are as correct as possible."
-------------------

Derek O'Connor

----------

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

From report at bugs.python.org  Sun Apr  4 11:59:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 09:59:12 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270375152.98.0.653333826323.issue8309@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Python 3.1.2 -- 32 bit gives sin(2^60) = -0.7391806966492228

Interesting.  I get 

>>> sin(2.**60)
-0.83064921763725463

On both OS X 10.6.3 (64-bit build) and OS X 10.5.something (32-bit build).  But this is all down to the platform math library, of course.

I agree it's not ideal, but it's not really in Python's power to fix this, without adding a huge extra maintenance burden (from adding the necessary high-precision arithmetic to Python itself) or another external dependency.

You could always try to come up with a patch that adds a configure option for linking Python's math library into MPFR instead of the system math library.  (crlibm would also work, and would be faster;  it doesn't seem to be so well maintained these days though;  Pari/GP isn't such a great option since its floating-point model isn't so compatible with IEEE 754).

----------

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

From report at bugs.python.org  Sun Apr  4 13:18:20 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 04 Apr 2010 11:18:20 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270379900.99.0.210495126821.issue7978@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

A patch to make select calls EINTR-safe is attached, but:
- there are many modules that suffer from the same problem, so maybe a fix at select level would be better
- if not, it could be a good idea to add this EINTR-retry handler to a given module (signal, os?) so that every module doesn't have to reimplement it (I know that at least subprocess does have one).

Thoughts ?

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file16755/SocketServer_eintr.diff

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

From report at bugs.python.org  Sun Apr  4 13:33:13 2010
From: report at bugs.python.org (AndiDog)
Date: Sun, 04 Apr 2010 11:33:13 +0000
Subject: [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270380793.28.0.401096493635.issue8304@psf.upfronthosting.co.za>


AndiDog <AndiDog at web.de> added the comment:

Just installed Python 3.1.2, same problem. I'm using Windows XP SP2 with two Python installations (2.6.4 and now 3.1.2).

----------

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

From report at bugs.python.org  Sun Apr  4 13:47:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Apr 2010 11:47:01 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270381621.22.0.616458871968.issue7978@psf.upfronthosting.co.za>


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

What kind of signals can be received in real-life?
(I'm assuming that most signals are of the kind that you only receive if someone else deliberately sends it to you, in which case you are supposed to be prepared to handle it)

Also, does your patch still allow Python to handle the signal properly (invoke a registered signal handler, or perhaps raise KeyboardInterrupt)?

You could raise the issue on the python-dev mailing-list for more advice.

----------
nosy: +exarkun, pitrou

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

From report at bugs.python.org  Sun Apr  4 13:56:41 2010
From: report at bugs.python.org (John Machin)
Date: Sun, 04 Apr 2010 11:56:41 +0000
Subject: [issue8308] raw_bytes.decode('cp932') -- spurious mappings
In-Reply-To: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>
Message-ID: <1270382201.23.0.862672548581.issue8308@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Thanks, Martin. Issue closed as far as I'm concerned.

----------

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

From report at bugs.python.org  Sun Apr  4 14:07:23 2010
From: report at bugs.python.org (AndiDog)
Date: Sun, 04 Apr 2010 12:07:23 +0000
Subject: [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270382843.11.0.909421678966.issue8304@psf.upfronthosting.co.za>


AndiDog <AndiDog at web.de> added the comment:

Definitely a Windows problem. I did this on Visual Studio 2008:

    wchar_t out[1000];
    time_t currentTime;
    time(&currentTime);
    tm *timeStruct = gmtime(&currentTime);

    size_t ret = wcsftime(out, 1000, L"%d%A", timeStruct);
    wprintf(L"ret = %d, out = (%s)\n", ret, out);

    ret = wcsftime(out, 1000, L"%d\u200f%A", timeStruct);
    wprintf(L"ret = %d, out = (%s)\n", ret, out);

and the output was

    ret = 8, out = (04Sunday)
    ret = 0, out = ()

Python really shouldn't use any so-called standard functions on Windows. They never work as expected ^^...

----------
versions: +Python 3.3

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

From report at bugs.python.org  Sun Apr  4 14:27:09 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 04 Apr 2010 12:27:09 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270384029.83.0.618314714408.issue7978@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

In real life, you can receive for example SIGSTOP (strace, gdb, shell), but mostly SIGCHLD (any process spawning children), etc. The attached patch just restarts calls when EINTR is received, as is done in subprocess module. The mailing list is a good idea.

----------

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

From report at bugs.python.org  Sun Apr  4 14:31:35 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 04 Apr 2010 12:31:35 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270384295.93.0.372649525527.issue7978@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> What kind of signals can be received in real-life?

There are lots of possible answers.  Here's one.  You launch a child process with os.fork() (and perhaps os.exec*() as well).  Eventually you'll get a SIGCHLD in the parent when the child exits.  If you've also installed a Python-level SIGCHLD handler with signal.signal (and not flagged the handler with SA_RESTART using signal.siginterrupt) then if you're in select.select() when the SIGCHLD is received, select.select() will fail with select.error EINTR.

If your Python SIGCHLD handler deals with the SIGCHLD completely before returning, then this lets you support child processes and use SocketServer at the same time.

Changing the behavior of select.select() ("a fix at select level would be better") should be *very* carefully considered, and probably rejected after such consideration.  There are completely legitimate use cases which require select.select() to fail with EINTR, and these should remain supported (not to mention that existing code relying on this behavior shouldn't be broken by a Python upgrade in a quite insidious way).

----------

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

From report at bugs.python.org  Sun Apr  4 14:57:33 2010
From: report at bugs.python.org (Ozgur Dogan Ugurlu)
Date: Sun, 04 Apr 2010 12:57:33 +0000
Subject: [issue8310] dis.dis function skips new-style classes in a module
In-Reply-To: <1270385853.05.0.694104105245.issue8310@psf.upfronthosting.co.za>
Message-ID: <1270385853.05.0.694104105245.issue8310@psf.upfronthosting.co.za>


New submission from Ozgur Dogan Ugurlu <dogeen at gmail.com>:

The documentation says:

dis.dis([bytesource])
Disassemble the bytesource object. bytesource can denote either a module, a class, a method, a function, or a code object. For a module, it disassembles all functions. For a class, it disassembles all methods. For a single code sequence, it prints one line per bytecode instruction. If no object is provided, it disassembles the last traceback.

And the behavior is correct for old-style classes. However, since the if check in the function dis.dis is like this:

if hasattr(x, '__dict__'):
        items = x.__dict__.items()
        items.sort()
        for name, x1 in items:
            if type(x1) in (types.MethodType,
                            types.FunctionType,
                            types.CodeType,
                            types.ClassType):

when given a module (x), it doesn't handle new-style classes which are types.TypeType. (types.ClassType are old-style classes)

A simple addition of types.TypeType to the list used by the inner if clause fixes the problem for me but I don't know if it could introduce another bug.

----------
components: Library (Lib)
messages: 102338
nosy: dogeen
severity: normal
status: open
title: dis.dis function skips new-style classes in a module
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr  4 15:21:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 13:21:54 +0000
Subject: [issue8308] raw_bytes.decode('cp932') -- spurious mappings
In-Reply-To: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>
Message-ID: <1270387314.11.0.53260616794.issue8308@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> wont fix
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Apr  4 15:32:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 13:32:17 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1270387937.59.0.244323130194.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

New patch:

 - document and test sys.hash_info
 - document numeric hash definition (in Doc/library/stdtypes.rst;  I'm
   not sure whether this is the best place for it)
 - document Decimal change (Decimal instances are now comparable
   with instances of float, fraction.Fraction)
 - refresh patch to apply cleanly to current svn.

I think this is close to final form:  I intend to apply this patch (or something very much like it) soon;  any review would be appreciated.

----------
nosy: +rhettinger
stage:  -> commit review
Added file: http://bugs.python.org/file16756/numeric_hash6.patch

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

From report at bugs.python.org  Sun Apr  4 15:33:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Apr 2010 13:33:43 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1270388023.22.0.0913572534116.issue7696@psf.upfronthosting.co.za>


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

> (I don't know why it doesn't have its own anchor, though)

Because that is only a link to the real description:

http://docs.python.org/dev/library/stdtypes.html#memoryview

And I think even you, Mr Potrou, could infer how to add glossary entries from one look at glossary.rst :)

----------

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

From report at bugs.python.org  Sun Apr  4 15:35:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 13:35:40 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1270388140.56.0.0415488362102.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've refreshed the Rietveld patch as well:

http://codereview.appspot.com/660042

----------

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

From report at bugs.python.org  Sun Apr  4 15:36:53 2010
From: report at bugs.python.org (Jeff Pursell)
Date: Sun, 04 Apr 2010 13:36:53 +0000
Subject: [issue8311] wave module sets data subchunk size incorrectly when
	writing wav file
In-Reply-To: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>
Message-ID: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>


New submission from Jeff Pursell <jpursell at gmail.com>:

I tried to create a 4 second file and only heard the first 2 seconds.  The file size was correct for a 44.1 kHz, 16 bit mono file at 4 seconds, but both aplay and audactiy ignored the second half of the file.  I went to this page https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ and opened the output with a hex editor in little endian mode.  I found that at offset 40, the data chunk size was wrong.  It looked like it was just set to the number of samples.  It should be the number of samples times bytes-per-sample (2) times number-of-channels (1 in my case).  I manually set the number from 176400 to 352800 and that solved the problem for that wav file.

I'm guessing this was just an oversight and the fix will be simple.

I'll attach the code I used to generate the test tone.  Just run python -i testTone.py and it will generate out.wav with the incorrect field.

I am using pything 2.6.4 in ubuntu.

----------
components: Extension Modules
files: testTone.zip
messages: 102342
nosy: Jeff.Pursell
severity: normal
status: open
title: wave module sets data subchunk size incorrectly when writing wav file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16757/testTone.zip

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

From report at bugs.python.org  Sun Apr  4 15:48:54 2010
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Apr 2010 13:48:54 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270388934.29.0.259355731244.issue8309@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

At heart, this is really the same kind of thing that eventually prodded Python into adopting David Gay's burdensome ;-) code for correctly rounded double<->string I/O conversions.  We could similarly take on porting and maintaining KC Ng's fdlibm (an open source libm implementation Ng developed while at Sun - it doesn't guarantee correct rounding, but does guarantee max error strictly less than 1 ULP in all cases).

The tradeoffs are roughly similar.  For example, fdlibm is typically much slower than the platform C's libm, and most people using math libraries in anger are much keener about speed than avoiding noise results for inputs in ranges they never intend to use.  Perhaps surprisingly, fdlibm isn't "so slow" primarily because it's aiming at max 1 ULP error, but because it was coded to be as portable as possible.  Platform-specific libm implementations play every trick in the book (& invented many of the tricks in the book to begin with!) to squeeze out every cycle from the specific hardware they're intended to run on.  That makes "fast versus accurate versus portable" very much a "pick at most two" proposition for libm.

----------
nosy: +tim_one

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

From report at bugs.python.org  Sun Apr  4 15:54:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 04 Apr 2010 13:54:05 +0000
Subject: [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270389245.11.0.270713132917.issue8304@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
versions:  -Python 3.3

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

From report at bugs.python.org  Sun Apr  4 16:11:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 14:11:44 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270390304.88.0.446008226837.issue8309@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> We could similarly take on porting and maintaining KC Ng's fdlibm

Gulp.

If we did that, I'd definitely want to push for dropping Python support for non-IEEE 754 systems.

I'm not sure I've fully recovered from the dtoa.c addition yet.  :)

----------

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

From report at bugs.python.org  Sun Apr  4 17:58:50 2010
From: report at bugs.python.org (Paul Smith)
Date: Sun, 04 Apr 2010 15:58:50 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1270396730.78.0.29156032522.issue8154@psf.upfronthosting.co.za>


Changes by Paul Smith <paulsmith at pobox.com>:


----------
nosy: +paulsmith

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

From report at bugs.python.org  Sun Apr  4 18:59:21 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 04 Apr 2010 16:59:21 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1270400361.58.0.478226919691.issue6931@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

This is because difflib.ndiff (called by difflib.HtmlDiff.make_table), contrarily to difflib.unified_diff (and probably kdiff3), doesn't restrict itself to contiguous lines, and searches diff even inside lines, so the complexity is much worse (see how many times _fancy_replace and quick_ratio are being called).
It might be a good idea to allow the user to specify the type of diff needed (ndiff vs unified_diff).

----------
nosy: +neologix

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

From report at bugs.python.org  Sun Apr  4 19:57:12 2010
From: report at bugs.python.org (Jeff Pursell)
Date: Sun, 04 Apr 2010 17:57:12 +0000
Subject: [issue8311] wave module sets data subchunk size incorrectly when
	writing wav file
In-Reply-To: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>
Message-ID: <1270403832.09.0.135814575217.issue8311@psf.upfronthosting.co.za>


Jeff Pursell <jpursell at gmail.com> added the comment:

Here's my fix.  The left file is the original and the right file is my version.  Perhaps someone should check this patch on a big endian machine to make sure there are no issues there.  I do not anticipate any issues.

416c416
<         nframes = len(data) // (self._sampwidth * self._nchannels)
---
>         nframes = len(data) // self._nchannels
427c427
<             self._datawritten = self._datawritten + len(data)
---
>             self._datawritten = self._datawritten + len(data) * self._sampwidth
463c463
<             self._nframes = initlength / (self._nchannels * self._sampwidth)
---
>             self._nframes = initlength // self._nchannels

----------

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

From report at bugs.python.org  Sun Apr  4 20:57:53 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 04 Apr 2010 18:57:53 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1270407473.56.0.378004457714.issue8188@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, very nice concept! - I'm just starting to review the patch, but I
think the unsigned longs in_Py_HashDouble() and long_hash() should be
uint64_t on a 64-bit OS.

For instance, now on Windows 64-bit:

>>> hash(2**61-1)
1073741823

----------

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

From report at bugs.python.org  Sun Apr  4 21:45:34 2010
From: report at bugs.python.org (Derek O'Connor)
Date: Sun, 04 Apr 2010 19:45:34 +0000
Subject: [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270410334.39.0.715534838365.issue8309@psf.upfronthosting.co.za>


Derek O'Connor <derekroconnor at eircom.net> added the comment:

@ Tim Peters

" ... are much keener about speed than avoiding noise results for inputs in ranges they *never intend to use* ".

It is the *unintended use* that worries me. Sadly, "Speed is King". Perhaps that aphorism should be "Speed is Ki(lli)ng".

@ Mark Dickinson

I don't write C but Gay's 4300 line dtoa.c is the most frightening piece of code I've ever seen. 

I think accountants have the right idea: money is in cents, with positives in the left column and negatives in the right. All they need is integer addition and comparison. Multiplication? Only if you have taxation.

Derek O'Connor

----------

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

From report at bugs.python.org  Sun Apr  4 22:31:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 20:31:06 +0000
Subject: [issue8311] wave module sets data subchunk size incorrectly when
	writing wav file
In-Reply-To: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>
Message-ID: <1270413066.1.0.918226801604.issue8311@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Any chance you could create a unit test for this? (The current set of tests is...pretty minimal.)  Also, having the patch in unified diff format relative to the top of the source three would be helpful (although this one is small enough we could certainly apply it by hand, having a unified diff makes it more likely someone will test it).

----------
components: +Library (Lib) -Extension Modules
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Sun Apr  4 22:53:26 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 04 Apr 2010 20:53:26 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1270414406.87.0.173247030952.issue8188@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Actually the current long_hash() is affected as well. On Windows 64-bit:

>>> hash(2**31)
-2147483648

>>> hash(2**32)
1

----------

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

From report at bugs.python.org  Sun Apr  4 23:01:25 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 04 Apr 2010 21:01:25 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <1270414885.23.0.714628903416.issue8035@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Alright, what happens is the following:
- the file you're trying to retrieve is actually redirected, so the server send a HTTP/1.X 302 Moved Temporarily
- in urllib, when we get a redirection, we call redirect_internal:
    def redirect_internal(self, url, fp, errcode, errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)

the fp.read() is there to wait for the remote end to close connection
The problem, in this case, is that with Python 3.1, httplib uses HTTP/1.1 instead of HTTP/1.0 in version 2.6, and with HTTP/1.1 the server doesn't close the connection after sending the redirect (shown by tcpdump).
So, the process remains stuck on fp.read().
Now, in version 3.1, if we simply change Lib/http/client.py:628
from 
class HTTPConnection:

    _http_vsn = 11
    _http_vsn_str = 'HTTP/1.1'

to
class HTTPConnection:

    _http_vsn = 11
    _http_vsn_str = 'HTTP/1.0'

to use HTTP/1.0 instead, the retrieval works fine.

Obviously, this is not a good solution. Since the RFC doesn't seem to require the server to close the connection after sending a redirect, we'd probably better close the connection ourselves.

That's what the attached patch does, it simply removes the call to fp.read() before closing the connection. It also removes this for http_error_default, since if an error occurs, we probably want to close the connection as soon as possible instead of waiting for server to do so.

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file16758/urllib_redirect.diff

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

From report at bugs.python.org  Sun Apr  4 23:25:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Apr 2010 21:25:35 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1270416335.33.0.181491089931.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, hash values are C longs, regardless of platform.  I think that's probably too ingrained to consider changing it (we'd have to change hashes of all the non-numeric types, too).

----------

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

From report at bugs.python.org  Sun Apr  4 23:55:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 04 Apr 2010 21:55:01 +0000
Subject: [issue8312] Add post/pre hooks for distutils commands
In-Reply-To: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>
Message-ID: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>


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

Add hooks to a script can be launched before/after a command.

This will be useful to build pre/post commit hooks for install/uninstall commands for instance

----------
assignee: tarek
components: Distutils2
messages: 102353
nosy: tarek
severity: normal
status: open
title: Add post/pre hooks for distutils commands

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

From report at bugs.python.org  Mon Apr  5 00:31:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 22:31:03 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <1270420263.31.0.891390845301.issue8035@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@andyharrington: No, crash is when the interpreter segfaults.
I'm making it priority high, though, since it is a hang during an operation that is likely to happen fairly frequently.  Senthil may want to bump it up even higher.

@neologix: Thanks for figuring this out.

----------
nosy: +orsenthil, r.david.murray
priority:  -> high
stage:  -> test needed
type: crash -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Mon Apr  5 00:35:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Apr 2010 22:35:28 +0000
Subject: [issue8287] python-gdb.py triggers compile errors on FreeBSD and
	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270420528.36.0.550160246893.issue8287@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  The patch didn't apply to my current trunk checkout.  I'll look into why later.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Apr  5 00:45:39 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 04 Apr 2010 22:45:39 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270421139.45.0.222623349516.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

This patch implements Michael's suggestion (but not the ErrorHolder part):

http://bugs.python.org/issue7559#msg97462

The unit tests all pass with no change.  If this approach looks good to you, I can add a unit test to the patch that checks that this bug has been fixed.

Also, Twisted Matrix's web site doesn't seem to be responding too well at the moment, but if I recall correctly, their code has a permissive (MIT?) license that should allow a small snippet like this to be copied without taking extra steps.

----------
Added file: http://bugs.python.org/file16759/_patch-7559-2.diff

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

From report at bugs.python.org  Mon Apr  5 01:24:01 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Apr 2010 23:24:01 +0000
Subject: [issue8310] dis.dis function skips new-style classes in a module
In-Reply-To: <1270385853.05.0.694104105245.issue8310@psf.upfronthosting.co.za>
Message-ID: <1270423441.9.0.620010501522.issue8310@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r79769.

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

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

From report at bugs.python.org  Mon Apr  5 02:15:42 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 05 Apr 2010 00:15:42 +0000
Subject: [issue8287] python-gdb.py triggers compile errors on FreeBSD and
	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270426542.85.0.847048855695.issue8287@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I believe $(INSTALL_SCRIPT) was changed to $(INSTALL_DATA) in r79716 (see http://bugs.python.org/issue8032#msg102288 )

Attaching refreshed version of the patch.

----------
Added file: http://bugs.python.org/file16760/introduce-var-for-gdb-hooks-002.patch

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

From report at bugs.python.org  Mon Apr  5 02:51:51 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Apr 2010 00:51:51 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270428711.3.0.353592645228.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This latest patch (26) only merges the latest changes from the repo.

----------
Added file: http://bugs.python.org/file16761/windows symlink draft 26.patch

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

From report at bugs.python.org  Mon Apr  5 03:42:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 01:42:34 +0000
Subject: [issue8287] python-gdb.py triggers compile errors on FreeBSD and
	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270431754.03.0.52709441453.issue8287@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r79778.  We'll see how the buildbots fare.

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Apr  5 05:16:40 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 05 Apr 2010 03:16:40 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270437400.75.0.0591464392098.issue8300@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Looks good to me.

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

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

From report at bugs.python.org  Mon Apr  5 06:07:24 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Apr 2010 04:07:24 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1270440444.56.0.42114251486.issue8218@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r79781 (trunk), r79782 (release26-maint), r79783 (py3k) and r79784 (release31-maint).
Thanks to all!

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Apr  5 07:37:00 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Mon, 05 Apr 2010 05:37:00 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270445820.91.0.379499304974.issue7978@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

> What kind of signals can be received in real-life?

We use SIGUSR1 to reopen log files after rotation. sighandler works just fine, but after that Paste crashes.

I suppose that implementing silent syscall restart at select.select() level is a bad idea (explanation is given already), but some helper like untilConcludes in socket module might be useful.

----------

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

From report at bugs.python.org  Mon Apr  5 09:47:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Apr 2010 07:47:47 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270453667.49.0.184910643614.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.

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

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

From report at bugs.python.org  Mon Apr  5 11:38:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 05 Apr 2010 09:38:46 +0000
Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>
Message-ID: <1270460326.87.0.431864765847.issue4683@psf.upfronthosting.co.za>


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

Ping?

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Mon Apr  5 11:43:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 05 Apr 2010 09:43:01 +0000
Subject: [issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
In-Reply-To: <1229523259.96.0.571468029932.issue4683@psf.upfronthosting.co.za>
Message-ID: <1270460581.6.0.567532686338.issue4683@psf.upfronthosting.co.za>


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

Okay, This vaguely got out of my mind. Shall come with the tests for HTTPAuthDigest.

----------

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

From report at bugs.python.org  Mon Apr  5 12:35:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 05 Apr 2010 10:35:59 +0000
Subject: [issue5198] Strange DeprecationWarning behaviour in module struct
In-Reply-To: <1234250088.94.0.680929615779.issue5198@psf.upfronthosting.co.za>
Message-ID: <1270463759.31.0.733169920999.issue5198@psf.upfronthosting.co.za>


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

Both examples now give consistent behavior independent of byteorder in trunk: packing floats with "H" works, packing bytes out of range with "B" raises.

Closing as "out of date".

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Mon Apr  5 12:56:29 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 05 Apr 2010 10:56:29 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>


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

>>> import unittest
>>> class Foo(unittest.TestCase):
...   def test_fffd(self): self.assertEqual(u'\ufffd', u'\ufffd\ufffd')
...
>>> unittest.main(exit=False)
F
======================================================================
FAIL: test_fffd (__main__.Foo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 2, in test_fffd
AssertionError: <unprintable AssertionError object>

----------------------------------------------------------------------
Ran 1 test in 0.001s


The problem with creating unicode tracebacks is that they could fail when being output on terminals not capable of showing the full range of unicode characters (the default terminal on Windows is CP1252).

This can already happen with Unicode messages that aren't part of the traceback.

Detecting the 'unprintable' message before calling into traceback and replacing it with the repr of the unicode is one possibility.

----------
assignee: michael.foord
components: Library (Lib)
messages: 102368
nosy: ezio.melotti, michael.foord
severity: normal
status: open
title: <unprintable AssertionError object> message in unittest tracebacks
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr  5 13:44:35 2010
From: report at bugs.python.org (nik)
Date: Mon, 05 Apr 2010 11:44:35 +0000
Subject: [issue6869] Embedded python crashed on 4th run, if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1270467875.54.0.89260289644.issue6869@psf.upfronthosting.co.za>


nik <nik.lutz at gmail.com> added the comment:

I can confirm that the patch fix this issue. I adapted the patch (variable names changed):

5523a5524
>         Py_INCREF(&Struct_Type);
5529a5531
>         Py_INCREF(&Union_Type);
5535a5538
>         Py_INCREF(&Pointer_Type);
5541a5545
>         Py_INCREF(&Array_Type);
5547a5552
>         Py_INCREF(&Simple_Type);
5553a5559
>         Py_INCREF(&CFuncPtr_Type); 

Platform: Linux (kubuntu 9.10 x64)
Python: 2.6.4-0ubuntu3

----------
nosy: +nik.lutz at gmail.com

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

From report at bugs.python.org  Mon Apr  5 13:48:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 05 Apr 2010 11:48:09 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1270468089.95.0.50694996838.issue7721@psf.upfronthosting.co.za>


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

Thanks, fixed in release26-maint r79796.

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

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

From report at bugs.python.org  Mon Apr  5 13:59:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 05 Apr 2010 11:59:43 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1270468783.38.0.503395689756.issue7490@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +georg.brandl

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

From report at bugs.python.org  Mon Apr  5 14:18:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 12:18:05 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

======================================================================
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

----------
components: Tests
keywords: buildbot
messages: 102371
nosy: r.david.murray, theller
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ctypes fails in test_ulonglong on sparc buildbots
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  5 14:19:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 12:19:00 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1270469940.98.0.607889442643.issue8314@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The ubuntu and debian sparc buildbots show the same failure, none of the other buildbots do.

----------

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

From report at bugs.python.org  Mon Apr  5 14:20:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 05 Apr 2010 12:20:51 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1270470051.38.0.544810205237.issue8314@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This bug is already reported here:
http://bugs.python.org/issue8142#msg101134

----------
nosy: +flox

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

From report at bugs.python.org  Mon Apr  5 15:33:15 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 05 Apr 2010 13:33:15 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270474395.96.0.831694181659.issue8108@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Apr  5 16:36:05 2010
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Mon, 05 Apr 2010 14:36:05 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1270478165.79.0.287587150241.issue7946@psf.upfronthosting.co.za>


Changes by Thouis (Ray) Jones <thouis at gmail.com>:


----------
nosy: +thouis

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

From report at bugs.python.org  Mon Apr  5 16:45:12 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 14:45:12 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1270478712.04.0.919863957336.issue1103213@psf.upfronthosting.co.za>


Irmen de Jong <irmen at razorvine.net> added the comment:

Ok I think I've got the code and doc changes ready. I added a recvall and a recvall_into method to the socket module. Any partially received data in case of errors is returned to the application as part of the args for a new exception, socket.partialdataerror.

Still need to work on some unit tests for these new methods.

----------

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

From report at bugs.python.org  Mon Apr  5 17:04:37 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 15:04:37 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1270479877.5.0.11461121984.issue1103213@psf.upfronthosting.co.za>


Changes by Irmen de Jong <irmen at razorvine.net>:


Removed file: http://bugs.python.org/file6439/patch.txt

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

From report at bugs.python.org  Mon Apr  5 17:07:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Apr 2010 15:07:01 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270480021.33.0.353487513041.issue1220212@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

FAQ should be updated http://www.python.org/doc/faq/windows/#how-do-i-emulate-os-kill-in-windows

----------
nosy: +techtonik

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

From report at bugs.python.org  Mon Apr  5 17:07:48 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 15:07:48 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1270480068.56.0.982893668521.issue1103213@psf.upfronthosting.co.za>


Changes by Irmen de Jong <irmen at razorvine.net>:


Added file: http://bugs.python.org/file16762/socketmodulepatch.txt

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

From report at bugs.python.org  Mon Apr  5 17:08:25 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 15:08:25 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1270480105.03.0.916279246159.issue1103213@psf.upfronthosting.co.za>


Changes by Irmen de Jong <irmen at razorvine.net>:


Added file: http://bugs.python.org/file16763/libpatch.txt

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

From report at bugs.python.org  Mon Apr  5 17:09:00 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 15:09:00 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1270480140.81.0.14719674637.issue1103213@psf.upfronthosting.co.za>


Changes by Irmen de Jong <irmen at razorvine.net>:


Added file: http://bugs.python.org/file16764/docpatch.txt

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

From report at bugs.python.org  Mon Apr  5 17:20:42 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Apr 2010 15:20:42 +0000
Subject: [issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files
In-Reply-To: <1266583937.16.0.516750395183.issue7964@psf.upfronthosting.co.za>
Message-ID: <1270480842.23.0.820418476068.issue7964@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Is there a reason this didn't get reviewed for the 3.1.2 release? What steps need to be taken to see that it makes it into a 3.1.3 release?

----------

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

From report at bugs.python.org  Mon Apr  5 17:36:33 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Apr 2010 15:36:33 +0000
Subject: [issue8315] ./python -m unittest test.test_importlib doesn't work
In-Reply-To: <1270481793.28.0.468676978723.issue8315@psf.upfronthosting.co.za>
Message-ID: <1270481793.28.0.468676978723.issue8315@psf.upfronthosting.co.za>


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

Actually, ./python -m unittest test.test_email doesn't work either and those are two cases where the Lib/test module just forwards to the package's own test suite, so maybe that's the problem.

----------
assignee: michael.foord
components: Library (Lib)
messages: 102377
nosy: barry, michael.foord
severity: normal
status: open
title: ./python -m unittest test.test_importlib doesn't work
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr  5 17:37:36 2010
From: report at bugs.python.org (David Andrzejewski)
Date: Mon, 05 Apr 2010 15:37:36 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1270481856.22.0.732198248885.issue5103@psf.upfronthosting.co.za>


Changes by David Andrzejewski <site+python.org at davidandrzejewski.com>:


----------
nosy: +dandrzejewski

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

From report at bugs.python.org  Mon Apr  5 17:37:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Apr 2010 15:37:41 +0000
Subject: [issue7583] doctest should normalize tabs when comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1270481861.06.0.456560236082.issue7583@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Could you be more specific about why users should not be allowed to use tabs in docstrings. An example use case/user story would help me a lot.

I've made a precondition to check tab existence before expanding tabs for performance reasons.

The indentation of output prior to tab expansion is necessary to correctly format output and show result when test fails.

I agree to close this bug as "won't fix" if we can clear the confusion by describing the situation in more detail and providing examples.

----------

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

From report at bugs.python.org  Mon Apr  5 17:38:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 05 Apr 2010 15:38:28 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270481908.83.0.51875815754.issue1220212@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

How about something like this patch?

----------
Added file: http://bugs.python.org/file16765/faq_update.diff

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

From report at bugs.python.org  Mon Apr  5 17:44:33 2010
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 05 Apr 2010 15:44:33 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1270482273.26.0.710488603838.issue4256@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

Thanks for the pointers to both of these... I wasn't aware of either. I see argparse has been recently approved for Python stdlib inclusion, too: http://www.python.org/dev/peps/pep-0389/ Congratulations!

As far as I can tell, genzshcomp is parsing the output of the help command to reverse-engineer what the allowed flags should be. Assuming that only one space occurs between the arg and its metavar, this should work 99% or the time... I'm not sure if there is any attempt to be clever when the formatting is ambiguous. But given that the opt parser already contains the structured information, life can be made easier by writing out a more readily parseable format.

Here's an example bash parser function and its usage, for a further-simplified form of the above format where each arg (long or short) gets a line of its own and the arguments are indicated by a separate word as in the current output:

Example input:
$ foo --help-options
#OPTPARSE_FORMAT 0
--version
-h
--help
-r REGEXP
--regexp REGEXP
-s N
--start N
-e M
--end M
-f FILE
--file FILE

and the parser/completion functions:

function _optparse_getargs() {
	local opts cur prev
	COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"

    PREVIFS=$IFS
    IFS=$'\n'
    for line in `$1 --help-options | egrep '^-'`; do
        opt=`echo $line | sed 's/^\(-[^ ]\+\).*$/\1/'`
        argeq=`echo $line | sed 's/^--[^ ]\+ \([A-Za-z0-9]*\)$/=/'`
        if [[ $argeq != "=" ]]; then argeq=""; fi
        opts="$opts $opt$argeq";
    done
    IFS=$PREVIFS
    unset PREVIFS
    opts=`echo $opts | sed -e 's/^ *//' -e 's/ *$//'`

    if [[ ${cur} == -* ]] ; then
        COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )        
        if test -n "$COMPREPLY"; then
            return 0
        fi
    fi

    return 0
}


function _foo() {
    _optparse_getargs foo
    return 0
}

complete -F _foo -o default foo

----------

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

From report at bugs.python.org  Mon Apr  5 17:54:59 2010
From: report at bugs.python.org (David Andrzejewski)
Date: Mon, 05 Apr 2010 15:54:59 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1270482899.1.0.918794899061.issue5103@psf.upfronthosting.co.za>


David Andrzejewski <site+python.org at davidandrzejewski.com> added the comment:

I believe this issue may be responsible for causing a very long hang in my application.  Here's an example of it hanging for 30 minutes.  Yes - minutes. 

[UI] 2010-04-03 11:33:34,209 DEBUG: Communicating with GUI on 127.0.0.1:9095 - timeout 10 seconds
[UI] 2010-04-03 12:03:16,118 ERROR: Error in send_gui_command()!
Traceback (most recent call last):
  File "javaui.pyc", line 72, in send_message
  File "client.pyc", line 506, in send_message_with_params
  File "client.pyc", line 230, in call
  File "client.pyc", line 94, in do_request
  File "httplib.pyc", line 1100, in connect
  File "ssl.pyc", line 350, in wrap_socket
  File "ssl.pyc", line 118, in __init__
  File "ssl.pyc", line 293, in do_handshake
error: [Errno 10053] An established connection was aborted by the software in your host machine

This is Python 2.6.4 on Windows.  (This particular time it happened on a 32-bit Server 2008 system). 

My guess is that after that 30 minute time period, Windows is seeing that the connection is hung and it's just aborting it?

----------

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

From report at bugs.python.org  Mon Apr  5 18:01:50 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Apr 2010 16:01:50 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1270483310.18.0.765479731048.issue1103213@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Just a couple comments:

  * If MSG_WAITALL is defined and a signal interrupts recv, will a string shorter than requested will be returned by sock_recvall?
  * Since MSG_WAITALL is already exposed to Python (when the underlying platform provides it), I wonder if this could all be implemented more simply in pure Python.  Can you elaborate on the motivation to use C?

Someone should do another review when there are unit tests.

----------
nosy: +exarkun

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

From report at bugs.python.org  Mon Apr  5 18:10:34 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 05 Apr 2010 16:10:34 +0000
Subject: [issue8316] test_gdb is susceptible to tty width settings
In-Reply-To: <1270483834.31.0.175074168079.issue8316@psf.upfronthosting.co.za>
Message-ID: <1270483834.31.0.175074168079.issue8316@psf.upfronthosting.co.za>


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

test_gdb's get_gdb_repr carves up a gdb backtrace to try to extract how gdb representated the data.

When connected to a tty, gdb will insert additional newlines and spaces based on the width of the tty (internally it has a wrap_here() function to do this), so the test turned out to be somewhat susceptible to whitespace and tty configuration.

I'm attaching a patch against trunk which I believe fixes this.  I've tested it with various tty widths (from 5 columns wide through to 235 columns wide), and redirecting to a file, and all tests pass.

[Seen on buildbot on this run:
http://www.python.org/dev/buildbot/builders/sparc%20Ubuntu%20trunk/builds/37/steps/test/logs/stdio
and I believe this was the cause of all of four of the five failures there.

The remaining one "test_corrupt_tp_name" seems to be a different issue]

----------
assignee: r.david.murray
files: fix-test_gdb-whitespace-issues.txt
keywords: buildbot
messages: 102383
nosy: dmalcolm, r.david.murray
severity: normal
stage: patch review
status: open
title: test_gdb is susceptible to tty width settings
versions: Python 2.7
Added file: http://bugs.python.org/file16766/fix-test_gdb-whitespace-issues.txt

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

From report at bugs.python.org  Mon Apr  5 18:32:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 16:32:15 +0000
Subject: [issue8316] test_gdb is susceptible to tty width settings
In-Reply-To: <1270483834.31.0.175074168079.issue8316@psf.upfronthosting.co.za>
Message-ID: <1270485135.48.0.047344914358.issue8316@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r79803.  I changed the assert_ to an if not m/fail, since assert_ is deprecated and I think the if makes it clearer than the assert_ what it is that is being checked.

----------
components: +Tests
priority:  -> normal
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Mon Apr  5 19:15:57 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Apr 2010 17:15:57 +0000
Subject: [issue1220212] os.kill on windows
In-Reply-To: <1270481908.83.0.51875815754.issue1220212@psf.upfronthosting.co.za>
Message-ID: <v2gd34314101004051015u8f0fb7d1q27cbafdebfe5c98d@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

Seems good to me, even though I'd rewrite some parts like this:

- Prior to Python 2.7 and 3.2, to terminate a process, you can use ctypes::
+ Prior to Python 2.7 and 3.2, you can use linksomehow:`ctypes` to
terminate a process::

...

In newer Python versions :func:`os.kill` works on Windows with the
additional feature of being able to send CTRL+C and CTRL+BREAK to
console subprocesses that understand these signals.

...
-- 
anatoly t.

On Mon, Apr 5, 2010 at 6:38 PM, Brian Curtin <report at bugs.python.org> wrote:
>
> Brian Curtin <curtin at acm.org> added the comment:
>
> How about something like this patch?
>
> ----------
> Added file: http://bugs.python.org/file16765/faq_update.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1220212>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Apr  5 19:24:20 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Apr 2010 17:24:20 +0000
Subject: [issue8317] test_tarfile fails intermittently on Windows
In-Reply-To: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>
Message-ID: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>


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

Using Windows 7 32-bit, and /branches/py3k at 79802.

When I run the test_tarfile from the regrtest script, often the first run will succeed and subsequent runs will fail (though sometimes a first run will fail and rarely a subsequent run will succeed). It appears to be a timing issue. The output from a failed attempt is included below.

Passing -v to the regrtest script prevents the failure from occurring. Also disabling test_extract_hardlink test prevents the failure from occurring in most cases. I found that enabling pdb and setting a trace in test_extract_hardlink prevented the error from occurring. I also attempted closing the tarfile explicitly (including in a finally block) and putting time.sleep(1) at the beginning or end of that test, but that seemed to have no effect.

I am beginning to suspect that this problem is related to an indexer or malware scanner on the system checking the file after it's created, causing it to be locked at the time it's scheduled to be deleted.

PS C:\Users\jaraco\projects\public\python-core-3.x-svn> pcbuild\python .\lib\test\regrtest.py test_tarfile
test_tarfile
test test_tarfile crashed -- <class 'WindowsError'>: [Error 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\jaraco\\projects\\public\\python-core-3.x-svn\\build\\test_python_5196\\@test_5196_tmp\\testtar.tar.gz'
'test_tarfile' left behind directory '@test_5196_tmp' and it couldn't be removed: [Error 32] The process cannot access the file because it is being used by another process: '@test_5196_tmp\\testtar.tar.gz'
1 test failed:
    test_tarfile
Traceback (most recent call last):
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 400, in temp_cwd
    yield os.getcwd()
  File ".\lib\test\regrtest.py", line 1473, in <module>
    main()
  File ".\lib\test\regrtest.py", line 687, in main
    sys.exit(len(bad) > 0 or interrupted)
SystemExit: True

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File ".\lib\test\regrtest.py", line 1473, in <module>
    main()
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 404, in temp_cwd
    rmtree(name)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 184, in rmtree
    shutil.rmtree(path)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 251, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 256, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 254, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\jaraco\\projects\\public\\python-core-3.x-svn\\build\\test_python_5196\\@test_5196_tmp\\testtar.tar.gz'

----------
components: Tests
messages: 102386
nosy: jaraco
severity: normal
status: open
title: test_tarfile fails intermittently on Windows
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr  5 19:24:54 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Apr 2010 17:24:54 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270488294.69.0.771201841077.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

My initial troubleshooting indicated to me that the intermittent test_tarfile problem exists independent of the symlink patch, so it was not relevant to this issue.

I've tried to do some more thorough troubleshooting, and this continues to be my finding, and somewhat consistent with Brian's finding.

I've created issue8317 to track the trouble with test_tarfile.

----------

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

From report at bugs.python.org  Mon Apr  5 19:33:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 05 Apr 2010 17:33:44 +0000
Subject: [issue8317] test_tarfile fails intermittently on Windows
In-Reply-To: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>
Message-ID: <1270488824.41.0.546753943592.issue8317@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

So far I've only seen this with os.symlink from #1578269 applied, but I will try more runs on a vanilla py3k to see if I can catch it.

----------
components: +Windows
nosy: +brian.curtin
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Mon Apr  5 19:40:28 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Apr 2010 17:40:28 +0000
Subject: [issue8317] test_tarfile fails intermittently on Windows
In-Reply-To: <1270488824.41.0.546753943592.issue8317@psf.upfronthosting.co.za>
Message-ID: <7A7DF54C-12BE-4525-83C2-5FD9730A1534@jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> To be clear, all of my tests were without any patches applied.

----------

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

From report at bugs.python.org  Mon Apr  5 19:42:02 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 05 Apr 2010 17:42:02 +0000
Subject: [issue8318] Deprecation of multifile inappropriate or incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>


New submission from Tres Seaver <tseaver at agendaless.com>:

Import of the multifile module emits a DeprecationWarning, but the
warning is either incomplete:

- The documentation[1] states that the 'email' module is to be
  preferred, but doesn't describe what APIs should be used from that
  module.

- In fact, the 'email' module doesn't appear to provide an equivalent
  API to the 'multifile' module.

or perhaps inappropriate, as not all handling of 'multipart' MIME is
email related (e.g., processing HTTP form POSTs which include file uploads).

At a minimum, the docs for 'multifile' should include examples showing
the "preferred" way to implement its own native examples using
the'email' module's APIs.


[1] http://docs.python.org/library/multifile.html

----------
components: Library (Lib)
messages: 102390
nosy: barry, tseaver
severity: normal
status: open
title: Deprecation of multifile inappropriate or incomplete
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Apr  5 19:58:23 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 17:58:23 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1270490303.5.0.971826588172.issue1103213@psf.upfronthosting.co.za>


Irmen de Jong <irmen at razorvine.net> added the comment:

Currently if MSG_WAITALL is defined, recvall() just calls recv() internally with the extra flag. Maybe that isn't the smartest thing to do because it duplicates recv's behavior on errors. Which is: release the data and raise an error.
Would it be nicer to have recvall() release the data and raise an error, or to let it return the partial data? Either way, I think the behavior should be the same regardless of MSG_WAITALL being available. This is not yet the case.

Why C: this started out by making the (very) old patch that I once wrote for socketmodule.c up to date with the current codebase, and taking Martin's comments into account.
The old patch was small and straightforward. Unfortunately the new one turned out bigger and more complex than I thought. For instance I'm not particularly happy with the way recvall returns the partial data on fail. It uses a new exception for that but the code has some trickery to replace the socket.error exception that is initially raised. I'm not sure if my code is the right way to do this, it needs some review. I do think that putting it into the exception object is the only safe way of returning it to the application, unless the semantics on error are changed as mentioned above. Maybe it could be made simpler then.
In any case, it probably is a good idea to see if a pure python solution (perhaps just some additions to Lib/socket.py?) would be better. Will put some effort into this.

----------

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

From report at bugs.python.org  Mon Apr  5 20:08:55 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Mon, 05 Apr 2010 18:08:55 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains nor data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmail.com>:

When parsing HTML and having a string along the lines of <td></td>, a call to handle_data is not issued between handle_starttag and handle_endtag, but afterwards. The problem is in HTMLparser.goahead, where the position i and j are calculated. The code reads
if i < j: self.handle_data(rawdata[i:j]) but it should be
if i <= j: self.handle_data(rawdata[i:j])

If there is data between <td> and </td>, everything works fine.

I just checked the trunk of 2.6, this occurs in line 142 of Lib/HTMLParser.py. The size of HTMLParser.py is 13407 bytes, and is dated 'Feb 26 19:25'.

----------
components: Library (Lib)
messages: 102392
nosy: wplappert
severity: normal
status: open
title: HTMLparser does not handle call to handle_data when a tag contains nor data.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr  5 20:13:36 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 18:13:36 +0000
Subject: [issue8320] docs on socket.recv_into doesn't mention the return value
In-Reply-To: <1270491216.65.0.230513280348.issue8320@psf.upfronthosting.co.za>
Message-ID: <1270491216.65.0.230513280348.issue8320@psf.upfronthosting.co.za>


New submission from Irmen de Jong <irmen at razorvine.net>:

Doc/library/socket.rst doesn't mention the return value for recv_into. Adding a simple "Returns the number of bytes received." should fix this. 
(note that recvfrom_into does mention its return value)

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 102393
nosy: georg.brandl, irmen
severity: normal
status: open
title: docs on socket.recv_into doesn't mention the return value
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Apr  5 20:25:40 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 18:25:40 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270491940.54.0.0683316125037.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Yes, it's the _sslobj.shutdow() call:

  File "test_ftplib.py", line 332, in handle_close
    self.socket = self.socket.unwrap()
  File "/usr/local/lib/python2.7/ssl.py", line 258, in unwrap
    s = self._sslobj.shutdown()
error: [Errno 0] Error

Since it's not clear to me where exactly this comes from, whether it's from the Python C binding or OpenSSL itself, I tried to put some debugging printf() calls in Modules/_ssl.c, but it seems that  after installing OpenSSL 0.9.8m I'm no longer able to compile Python 2.7 from sorces.
This is what I get when I run ./configure; make:

gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/home/giampaolo/svn/python-2.7/Include -I/home/giampaolo/svn/python-2.7 -c /home/giampaolo/svn/python-2.7/Modules/_ssl.c -o build/temp.linux-i686-2.7/home/giampaolo/svn/python-2.7/Modules/_ssl.o
gcc -pthread -shared build/temp.linux-i686-2.7/home/giampaolo/svn/python-2.7/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-i686-2.7/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-i686-2.7/_ssl.so: undefined symbol: inflate

----------
nosy:  -jcea
versions: +Python 2.6, Python 3.1

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

From report at bugs.python.org  Mon Apr  5 20:28:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 05 Apr 2010 18:28:47 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270492127.9.0.734169375855.issue8108@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


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

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

From report at bugs.python.org  Mon Apr  5 20:28:49 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Mon, 05 Apr 2010 18:28:49 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270492129.06.0.599785961954.issue8319@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmail.com>:


----------
title: HTMLparser does not handle call to handle_data when a tag contains nor data. -> HTMLparser does not handle call to handle_data when a tag contains no data.

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

From report at bugs.python.org  Mon Apr  5 20:30:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 18:30:55 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1270491940.54.0.0683316125037.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270492372.3446.0.camel@localhost>


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

> Since it's not clear to me where exactly this comes from, whether it's
> from the Python C binding or OpenSSL itself, I tried to put some
> debugging printf() calls in Modules/_ssl.c, but it seems that  after
> installing OpenSSL 0.9.8m I'm no longer able to compile Python 2.7
> from sorces.

Have you tried `make distclean`?

----------

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

From report at bugs.python.org  Mon Apr  5 20:37:06 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 18:37:06 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270492626.35.0.503042416152.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

No I haven't, but I tried just now and I get the same error.

----------

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

From report at bugs.python.org  Mon Apr  5 21:21:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 19:21:07 +0000
Subject: [issue8318] Deprecation of multifile inappropriate or incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1270495267.44.0.807333659995.issue8318@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's not inappropriate, since the facilities *in* the email package are supposed to support other MIME use cases (such as HTML).  That it isn't clear how to convert is certainly a doc bug at the very least.  However, I wouldn't be entirely surprised to find that there are things you can do with multifile that you can't (yet) do with the facilities from the email package.  If so, these will most likely be considered bugs in the email package.

(Now, whether or not 'email' is an appropriate package name for this bundle of facilities is a different question, and not one I'm going to address :)

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Mon Apr  5 21:24:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 19:24:27 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270495467.04.0.550319997263.issue8319@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
nosy: +orsenthil
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Mon Apr  5 21:28:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 19:28:18 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1270492626.35.0.503042416152.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270495815.3446.11.camel@localhost>


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

> No I haven't, but I tried just now and I get the same error.

I think "inflate" is a function exported by the zlib. Perhaps you can
add "-lz" to the linking flags.
(Googling hints that OpenSSL can depend on the zlib if compression is
enabled)

----------

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

From report at bugs.python.org  Mon Apr  5 21:42:38 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 05 Apr 2010 19:42:38 +0000
Subject: [issue8318] Deprecation of multifile inappropriate or incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1270496558.8.0.376238955365.issue8318@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

> [T]here [may be] things you can do with multifile that you can't (yet)
> do with the facilities from the email package.  If so, these will most > likely be considered bugs in the email package.

Surely the presence of such a feature would make the deprecation premature.

----------

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

From report at bugs.python.org  Mon Apr  5 21:46:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Apr 2010 19:46:46 +0000
Subject: [issue5479] Add an easy way to provide total ordering now that
	__cmp__ is deprecated/gone
In-Reply-To: <1236845917.79.0.765415316549.issue5479@psf.upfronthosting.co.za>
Message-ID: <1270496806.52.0.498722922143.issue5479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Small documentation question: Does the expression ?total ordering? have established usage in maths or computer science? Its meaning is not obvious to the non-maths person that I am.

Regards

----------

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

From report at bugs.python.org  Mon Apr  5 21:48:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Apr 2010 19:48:40 +0000
Subject: [issue5479] Add an easy way to provide total ordering now that
	__cmp__ is deprecated/gone
In-Reply-To: <1236845917.79.0.765415316549.issue5479@psf.upfronthosting.co.za>
Message-ID: <1270496920.14.0.0835037902134.issue5479@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, it's a standard mathematics term.

http://en.wikipedia.org/wiki/Total_order

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Mon Apr  5 21:48:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Apr 2010 19:48:56 +0000
Subject: [issue5479] Add an easy way to provide total ordering now that
	__cmp__ is deprecated/gone
In-Reply-To: <1236845917.79.0.765415316549.issue5479@psf.upfronthosting.co.za>
Message-ID: <1270496936.13.0.537980722036.issue5479@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

http://en.wikipedia.org/wiki/Total_order

----------

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

From report at bugs.python.org  Mon Apr  5 21:53:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Apr 2010 19:53:58 +0000
Subject: [issue5479] Add an easy way to provide total ordering now that
	__cmp__ is deprecated/gone
In-Reply-To: <1236845917.79.0.765415316549.issue5479@psf.upfronthosting.co.za>
Message-ID: <1270497238.45.0.268130556423.issue5479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the link. Please include it in the future doc if you judge it useful for a large number of users.

I?m still wondering if ?total_ordering? is the best name for a decorator that fills the blanks to provide total ordering.

Regards

----------

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

From report at bugs.python.org  Mon Apr  5 22:03:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 20:03:35 +0000
Subject: [issue8318] Deprecation of multifile inappropriate or incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1270497815.88.0.91659552956.issue8318@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Depending on the feature, I might agree with that, but I wasn't involved in that decision.

If email only supports something structured with proper MIME headers and multifile is more general (which I *think* is the case, but I haven't actually tried to run any tests to confirm it), does that mean we should have kept multifile in py3?  I'm inclined to say no.  Should we make email support the more general case?  I'll at least keep it in the back of my mind as I/we work on email6.

Multifile is still there in 2.7, at the moment.

I presume you have a use case for the multifile module.  Could you do me a favor and add that use case the set of use cases in the email wiki?
(http://wiki.python.org/moin/Email%20SIG/UseCases).  It would be a good idea to mention there that email is supposed to supersede multifile.

----------

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

From report at bugs.python.org  Mon Apr  5 22:04:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 20:04:03 +0000
Subject: [issue8287] python-gdb.py triggers compile errors on FreeBSD and
	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270497843.4.0.948945993449.issue8287@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The buildbots seem happy.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Apr  5 22:42:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 20:42:55 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>


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

This patch gives access to the OpenSSL version the _ssl module is linked against, through three attributes: one gives the raw integer, another the decoded 5-tuple of ints, the last one the version string as returned by OpenSSL.

----------
components: Library (Lib)
files: sslversion.patch
keywords: patch
messages: 102406
nosy: benjamin.peterson, flox, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Give access to openssl version number
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16767/sslversion.patch

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

From report at bugs.python.org  Mon Apr  5 22:43:18 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 20:43:18 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270500198.36.0.685367035418.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

As suggested in this thread:
http://mirt.net/pipermail/stunnel-users/2005-July/000661.html
...I made the following change to the Makefile:

- LIBS=       -lpthread -ldl  -lutil
+ LIBS=       -lpthread -ldl  -lutil -lz

That made the error change as follows:

running build_ext

INFO: Can't locate Tcl/Tk libs and/or headers

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             _curses            _curses_panel   
_sqlite3           _tkinter           bsddb185        
bz2                dbm                gdbm            
readline           sunaudiodev

----------

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

From report at bugs.python.org  Mon Apr  5 22:44:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 20:44:03 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270500243.38.0.763599644048.issue8321@psf.upfronthosting.co.za>


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

(note: tested with OpenSSL 0.9.8k and 1.0.0)

----------

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

From report at bugs.python.org  Mon Apr  5 22:45:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 20:45:36 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>


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

When I compile and link against a local build of OpenSSL 1.0.0 (vanilla), I get the following errors in test_ssl:

======================================================================
ERROR: testProtocolSSL2 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 869, in testProtocolSSL2
    tryProtocolCombo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv23, True)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 736, in tryProtocolCombo
    CERTFILE, CERTFILE, client_protocol, chatty=False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 688, in serverParamsTest
    raise test_support.TestFailed("Unexpected exception:  " + str(x))
TestFailed: Unexpected exception:  [Errno 104] Connection reset by peer

======================================================================
ERROR: testProtocolSSL3 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 903, in testProtocolSSL3
    tryProtocolCombo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 745, in tryProtocolCombo
    ssl.get_protocol_name(server_protocol)))
TestFailed: Client protocol SSLv23 succeeded with server protocol SSLv3!

======================================================================
ERROR: testProtocolTLS1 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 914, in testProtocolTLS1
    tryProtocolCombo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 745, in tryProtocolCombo
    ssl.get_protocol_name(server_protocol)))
TestFailed: Client protocol SSLv23 succeeded with server protocol TLSv1!

----------
components: Library (Lib)
messages: 102409
nosy: flox, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl failures with OpenSSL 1.0.0
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr  5 22:46:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 20:46:53 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270500413.66.0.732627370583.issue8108@psf.upfronthosting.co.za>


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

I've tried to build against OpenSSL 1.0.0, and I get further failures in test_ssl. Since I don't know whether they are related, I've created a separate issue for them: issue8322

----------

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

From report at bugs.python.org  Mon Apr  5 22:46:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 05 Apr 2010 20:46:57 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270500417.52.0.0197670986945.issue8321@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please add documentation as well?

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Apr  5 22:48:54 2010
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 05 Apr 2010 20:48:54 +0000
Subject: [issue5479] Add an easy way to provide total ordering now that
	__cmp__ is deprecated/gone
In-Reply-To: <1270496806.52.0.498722922143.issue5479@psf.upfronthosting.co.za>
Message-ID: <1270500530.4142.42.camel@lambertdw>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

http://en.wikipedia.org/wiki/Total_order

For pair of items from a set,  (that's the total)
if  a <= b  and  b <= c  then  a <= c  (part of the order)
if  a <= b  and  b <= a  then  a compares the same as b, a == b, (the
other part of the order)

On Mon, 2010-04-05 at 19:46 +0000, ?ric Araujo wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Hello
> 
> Small documentation question: Does the expression ?total ordering? have established usage in maths or computer science? Its meaning is not obvious to the non-maths person that I am.
> 
> Regards
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5479>
> _______________________________________

----------

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

From report at bugs.python.org  Mon Apr  5 23:10:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 21:10:26 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270501826.84.0.772222411059.issue8321@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file16767/sslversion.patch

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

From report at bugs.python.org  Mon Apr  5 23:10:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 21:10:55 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270501855.15.0.931517846673.issue8321@psf.upfronthosting.co.za>


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

New patch with doc.

----------
Added file: http://bugs.python.org/file16768/sslversion.patch

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

From report at bugs.python.org  Mon Apr  5 23:11:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 21:11:57 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270501917.7.0.318126513639.issue8321@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file16768/sslversion.patch

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

From report at bugs.python.org  Mon Apr  5 23:12:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 21:12:16 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270501936.31.0.698567216466.issue8321@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file16769/sslversion.patch

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

From report at bugs.python.org  Mon Apr  5 23:19:59 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Mon, 05 Apr 2010 21:19:59 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270502399.97.0.656192351373.issue8319@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmail.com> added the comment:

The same code can be found in the 3.1 distribution.

----------
versions: +Python 3.1

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

From report at bugs.python.org  Mon Apr  5 23:20:57 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 21:20:57 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270502457.95.0.158541517212.issue8321@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I was about to open a request for this.
Thanks.

----------

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

From report at bugs.python.org  Mon Apr  5 23:33:11 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 05 Apr 2010 21:33:11 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270503191.08.0.129234495336.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Sorry, what I meant with the "original problem" was the phenomenon observed by Antoine (IIRC) that the same CPU thread tends to hog the gil, even when releaseing it in ceval.c.
What I have been looking at up to now is chiefly IO performance using David's iotest.py, and improving the poor performance of IO.  IO will not suffer as badly on windows because the IO thread will get its fair slice of execution time.  Promted by you, I added this bit of code to the iotest.py:
spins = 0
laststat = 0
def spin():
    global spins, laststat
    task,args = task_pidigits()
    while True:
       r= task(*args)
       spins += 1
       t = time.clock()
       if t-laststat > 1:
           print spins/(t-laststat)
           spins = 0
           laststat = t
       

You are right, however that cpu throughput of multiple cpu bound thread suffers.  And in fact, on windows, it appears to suffer the least using the LEGACY_GIL implementation.  This is, I conjecture, because there are far fewer context switches (because relinqushing the GIL fails).  My conjecture is that context switches between threads on two cores are so expensive as to dramatically affect performance.  Normal multithreaded programs don't suffer from this because the threads are kept busy.  But in our case, we are stopping one thread on one core, and starting another on a separate core, and this causes latency.

Now, I've improved my patch somewhat.  First off, I fixed some minor errors in the PRIORITY_GIL implementation.  But more importantly, I added something called FIFOCOND.  It is a condition variable that guarantees the FIFO property.  This was prompted by my observation that even Windows' Semaphore doesn't do that, rather the windows scheduler may allow the currently executing thread to jump ahead in the semaphore queue.  The FIFOCOND condition variable fixes that using explicit scheduling, and is intended as a diagnostic tool.
(Antoine, your comment from 13:04 about "roundrobin" inasfar as that we don't know anything about the condition variable behaviour.  I was assuming FIFO behaviour for the sake of argument, and I thought I? put it in to the comments that we assume a general 'fairness' there.  Put in the FIFOCOND and you will have that fairness guaranteed.)


At any rate, I believe my patch provides a useful platform for further experimentation.
1) Factoring out the gil as a separate type of lock (which it must be)
2) allowing for different implementation of the GIL
3) shoring up the Condition variable implementation on Windows
4) Providing a FIFOCOND_T type to enforce a particular scheduling order, and demonstrating how we can be explicit about thread scheduling.

I have already demonstrated that using the PRIORITY_GIL method fixes the problem with IO threads in the presence of CPU bound threads.  Your iotest.py script is perfect for this, using 2 worker threads.  On windows, the problem with IO wasn't so grave as I have explained (windows by default works as the ROUNDROBIN_GIL implementation, not the LEGACY_GIL mode used on pthreads).  The PRIORITY_GIL solution is particularly effective with multicore on Windows, but it also improves IO throughput if cpu affinity of the server is fixed to one CPU, i.e. on singlecore.

I have no fix for CPU bound threads, and I honestly don't think such a fix exists, except by causing switches to happen far less frequently, e.g. by raising the checkinterval, and so mitigating the problem (which is what the new gil in py3k does with its timeout implementation)  But the IO fix for pthreads

To summarise then:
1) The GIL has two problems on multicore machines
 a) performance of CPU threads goes down
 b) performance of IO in the presence of CPU threads is abysmal, but not on Windows
2) We can fix problem b) on pthreads with the ROUNDROBIN_GIL implementation.
3) We can improve IO performance in the presence of CPU threads on pthreads and Windows using the PRIORITY_GIL implementation, even to become faster than on a single core.
4) We cannot do anything about decreased performance of co-operatively switching CPU threads on multicore except switching less frequently.   But this is quite feasible now with the PRIORITY_GIL implementation because it can request an immediate gil drop when IO is ready.  So raising the checkinterval will not affect IO performance in a negative way.


Please have a look at the latest patch with IO thread performance in mind.  It is currently configured to enable the PRIORITY_GIL implementation without the FIFOCOND on windows and pthreads.

----------
Added file: http://bugs.python.org/file16770/gil2.patch

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

From report at bugs.python.org  Mon Apr  5 23:46:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 21:46:21 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270503981.77.0.295419545556.issue8321@psf.upfronthosting.co.za>


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

Committed, with Benjamin's permission, in r79812 (trunk) and r79813 (py3k).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Apr  5 23:55:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 05 Apr 2010 21:55:10 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270504510.08.0.984892509853.issue8299@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

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

From report at bugs.python.org  Mon Apr  5 23:57:18 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 21:57:18 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270504638.15.0.362581309407.issue8321@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

>>> import ssl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/ssl.py", line 62, in <module>
    from _ssl import OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_INFO, OPENSSL_VERSION
ImportError: cannot import name OPENSSL_VERSION_NUMBER



Just in case it's my fault, here's what I've done before importing ssl module:

> svn up 
Updated to revision 79814.
> make distclean
...
> ./configure ; make ; make install
...

----------

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

From report at bugs.python.org  Tue Apr  6 00:05:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 22:05:39 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270504638.15.0.362581309407.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270505256.3446.18.camel@localhost>


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

> >>> import ssl
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/local/lib/python2.7/ssl.py", line 62, in <module>
>     from _ssl import OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_INFO, OPENSSL_VERSION
> ImportError: cannot import name OPENSSL_VERSION_NUMBER

This looks rather unlikely.
Can you type "import _ssl" and then check _ssl.__file__ to see if it's
the one that's just been compiled?
Or did compilation fail?

----------

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

From report at bugs.python.org  Tue Apr  6 00:15:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 22:15:15 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270505715.24.0.99512587151.issue8321@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

The ./configure -> make -> make install process went fine, or at least, I think so, as it completed without reporting errors or exiting.
...But maybe I'm doing something wrong as just a little while ago I was modifying _ssl.c but wasn't able to see those changes applied.

So I'm gonna ask: when I modify *.c files, do I have to do something else other than "./configure; make; make install" in order to see the changes applied?

Anyway, here's what you asked:


root at ubuntu:/home/giampaolo/svn/python-2.7# python
Python 2.7a4+ (trunk:79814, Apr  5 2010, 23:53:01) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _ssl
>>> _ssl
<module '_ssl' from '/usr/local/lib/python2.7/lib-dynload/_ssl.so'>
>>> _ssl.__file__
'/usr/local/lib/python2.7/lib-dynload/_ssl.so'
>>>

----------

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

From report at bugs.python.org  Tue Apr  6 00:21:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 22:21:45 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270505715.24.0.99512587151.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270506222.3446.23.camel@localhost>


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

> So I'm gonna ask: when I modify *.c files, do I have to do something
> else other than "./configure; make; make install" in order to see the
> changes applied?

No.

If you run the Python binary from the SVN checkout directory (rather
than from an installation), _ssl should come from the build
subdirectory, not from /usr/local/lib.
Example here:

$ pwd
/home/antoine/cpython/newssl
$ ./python -c "import _ssl; print _ssl.__file__"
/home/antoine/cpython/newssl/build/lib.linux-x86_64-2.7/_ssl.so

If _ssl is coming from "/usr/local/lib/...", it means that something
modifies your sys.path so as to put that path before the path to the
just built extension modules. I can't really investigate this point for
you, but try using "python -E" instead.

----------

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

From report at bugs.python.org  Tue Apr  6 00:29:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 22:29:50 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270505715.24.0.99512587151.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270506708.3446.25.camel@localhost>


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

> So I'm gonna ask: when I modify *.c files, do I have to do something
> else other than "./configure; make; make install" in order to see the
> changes applied?

Oh, sorry, I had overlooked the "make install" bit.
Well then I don't know. But you can run the interpreter without
installing :-) (just "./python")

And check the output of "make" after you have touched Modules/_ssl.c

----------

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

From report at bugs.python.org  Tue Apr  6 00:45:18 2010
From: report at bugs.python.org (Robin Schoonover)
Date: Mon, 05 Apr 2010 22:45:18 +0000
Subject: [issue8323] multiprocessing.Queue ignores pickle restrictions in
	.put()
In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>
Message-ID: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>


New submission from Robin Schoonover <end at cornhooves.org>:

The multiprocessing module's version of the Queue class, which causes objects to be pickled for process to process transfer, ignores pickle restrictions when objects are added to the queue.  Example code (buffer isn't pickleable):

    from multiprocessing import Queue

    q = Queue()
    q.put(buffer("this is a buffer"))
    print(q.get())

It results in an exception, which is expected, but the exception is confusing, after the problem has already occurred, and if I were actually using multiple processes, not in the process that tried to send an unsendable object:

Traceback (most recent call last):                                                           
  File "mppkbuffer.py", line 5, in <module>                                                
    print(q.get())
  File "/usr/lib/python2.6/multiprocessing/queues.py", line 91, in get
    res = self._recv()
TypeError: buffer() takes at least 1 argument (0 given)

Expected result would be a thrown exception when we attempt to put the object into the queue using .put(), NOT when we attempt pull it out of the queue using .get(), when it gets unpickled.  Basically, while pickle fails when it tries to dump, Queue succeeds the dump (somehow) and fails to load.

I have tested with python 2.6.4 and 2.7a4.  3.1 doesn't appear to have this bug (but it does have a different one which I will report later).

----------
components: Library (Lib)
messages: 102423
nosy: rschoon
severity: normal
status: open
title: multiprocessing.Queue ignores pickle restrictions in .put()
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Apr  6 00:52:08 2010
From: report at bugs.python.org (Robin Schoonover)
Date: Mon, 05 Apr 2010 22:52:08 +0000
Subject: [issue8323] multiprocessing.Queue ignores pickle restrictions in
	.put()
In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>
Message-ID: <1270507928.01.0.484372545683.issue8323@psf.upfronthosting.co.za>


Robin Schoonover <end at cornhooves.org> added the comment:

Since these sort of buffer objects don't exist in 3.x (so far as I know), I came up with a different way to test in 3.x (basically, trying to pickle bound or unbound methods).

It turns out that using this method to test it in 2.6 seems to fail where it should (in .put()), so if there's some sort of object that isn't pickleable in the same way as buffer that exists in 3.x, it should be tested to see if this specific problem is actually confined to 2.6 or not.

----------

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

From report at bugs.python.org  Tue Apr  6 00:53:58 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 05 Apr 2010 22:53:58 +0000
Subject: [issue8323] multiprocessing.Queue ignores pickle restrictions in
	.put()
In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>
Message-ID: <1270508038.79.0.702311380445.issue8323@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

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

From report at bugs.python.org  Tue Apr  6 00:56:28 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 22:56:28 +0000
Subject: [issue8321] Give access to openssl version number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270508188.08.0.45722319069.issue8321@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

You were right: make output had an error involving ssl I didn't notice. My bad.

----------

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

From report at bugs.python.org  Tue Apr  6 01:19:34 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Apr 2010 23:19:34 +0000
Subject: [issue8324] add a test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>


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

Add a test command in distutils, ala setuptools

----------
assignee: tarek
components: Distutils2
keywords: gsoc
messages: 102426
nosy: tarek
priority: normal
severity: normal
status: open
title: add a test command
type: feature request

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

From report at bugs.python.org  Tue Apr  6 01:31:30 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 05 Apr 2010 23:31:30 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1270510290.24.0.229163440627.issue8324@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Should default to test discovery if no arguments are supplied.

Valid arguments: "testrunner", "tests" or "testsuite".
Default testrunner is unittest of course. "tests" / "testsuite" to be of the form: "package.module.suitename" (or just "package.module").

----------
nosy: +michael.foord
title: add a test command -> add a distutils test command

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

From report at bugs.python.org  Tue Apr  6 01:45:22 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Apr 2010 23:45:22 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1270511122.51.0.799790046887.issue8324@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Tue Apr  6 02:44:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 06 Apr 2010 00:44:59 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1270514699.16.0.0434375413417.issue7026@psf.upfronthosting.co.za>


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

Sridhar, I am unable to reproduce this bug in the 3.x (py3k and release31-maint) on 64 bit linux. I glance at the code to see any underpinnings for this RuntimeError and could not find any at the place the exception occurred.

Is it anyway related to other buildout issue you had mentioned? Can you provide the steps to reproduce?

----------

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

From report at bugs.python.org  Tue Apr  6 04:22:17 2010
From: report at bugs.python.org (Tres Seaver)
Date: Tue, 06 Apr 2010 02:22:17 +0000
Subject: [issue8318] Deprecation of multifile inappropriate or incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1270520537.56.0.551705979337.issue8318@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

> Could you do me a favor and add that use case the set of use cases in
> the email wiki?

Done.  The code in Zope which still uses 'multifile' is in the tests
for HTTP 'Range' support:

  http://svn.zope.org/*checkout*/Zope/trunk/src/OFS/tests/testRanges.py?content-type=text%2Fplain

----------

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

From report at bugs.python.org  Tue Apr  6 05:01:14 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 06 Apr 2010 03:01:14 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270522874.65.0.713824755239.issue8319@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmail.com> added the comment:

Here is a test program (shannon_data.py), some sample data (Shannon-2010.0.02-extract.html) and two output files (correct.out and wrong.out).

----------
Added file: http://bugs.python.org/file16771/shannon_data.py

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

From report at bugs.python.org  Tue Apr  6 05:01:47 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 06 Apr 2010 03:01:47 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270522907.02.0.962383771763.issue8319@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmail.com>:


Added file: http://bugs.python.org/file16772/Shannon-2010.0.02-extract.html

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

From report at bugs.python.org  Tue Apr  6 05:02:33 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 06 Apr 2010 03:02:33 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270522953.93.0.437305218137.issue8319@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmail.com>:


Added file: http://bugs.python.org/file16773/correct.out

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

From report at bugs.python.org  Tue Apr  6 05:03:24 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 06 Apr 2010 03:03:24 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270523004.27.0.330760707662.issue8319@psf.upfronthosting.co.za>


Changes by Winfried Plappert <Winfried.Plappert at gmail.com>:


Added file: http://bugs.python.org/file16774/wrong.out

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

From report at bugs.python.org  Tue Apr  6 05:12:43 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Apr 2010 03:12:43 +0000
Subject: [issue8317] test_tarfile fails intermittently on Windows
In-Reply-To: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>
Message-ID: <1270523563.13.0.20886279973.issue8317@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've tried reproducing this on a clean system and have thusfar been unable to. I'll try to eliminate variables on the failing system and perhaps this will elicit some information about what's causing the intermittent failures with the symlink patch.

----------

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

From report at bugs.python.org  Tue Apr  6 05:21:29 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 06 Apr 2010 03:21:29 +0000
Subject: [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: <1270524089.2.0.362541413744.issue8262@psf.upfronthosting.co.za>


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

Yes, the proposed wording is more suitable in the scenarios when the error is encountered. Also saw there is already a test (test_start_thread_again), which covers this. There is no harm in changing the wording.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

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

From report at bugs.python.org  Tue Apr  6 05:21:36 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Tue, 06 Apr 2010 03:21:36 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270524096.05.0.741623226848.issue8319@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmail.com> added the comment:

in short the correct output should be
2/4/2010;6.3;11.1;0.8;6.5;;7.8;-5
versus
2/4/2010;6.3;11.1;0.8;6.5;7.8;-5

which implies that one element is missing in the output stream :)

----------

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

From report at bugs.python.org  Tue Apr  6 05:36:49 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 06 Apr 2010 03:36:49 +0000
Subject: [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: <1270525009.63.0.0512691860221.issue8262@psf.upfronthosting.co.za>


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

Fixed in r79817, r79819 and r79821.
Thanks for the report and the patch, Gabriel.

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

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

From report at bugs.python.org  Tue Apr  6 06:13:14 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Apr 2010 04:13:14 +0000
Subject: [issue8317] test_tarfile fails intermittently on Windows
In-Reply-To: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>
Message-ID: <1270527194.7.0.376422259074.issue8317@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After grabbing a clean checkout, I'm unable to reproduce this problem where I was seeing it earlier, so I suspect the problem is in fact related to one or more lingering patches that were applied to the source. Please close this ticket as invalid.

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

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

From report at bugs.python.org  Tue Apr  6 06:24:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 06 Apr 2010 04:24:36 +0000
Subject: [issue8317] test_tarfile fails intermittently on Windows
In-Reply-To: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>
Message-ID: <1270527876.19.0.456901952018.issue8317@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid

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

From report at bugs.python.org  Tue Apr  6 06:29:53 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 06 Apr 2010 04:29:53 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270528193.02.0.496419720867.issue8319@psf.upfronthosting.co.za>


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

But changing the HTMLParser.goahead's way to treating tags from
if i < j: self.handle_data(rawdata[i:j]) TO
if i <= j: self.handle_data(rawdata[i:j]

is not the correct way to deal with this problem. Theoretically, whatever it is doing seems correct. As there is no data, don't call handle_data.

I can understand your testcase, and I think there is some other way to handle the test you are mentioning.

If you change the above line, many of the existing tests may fail, so that *may not be* way to go.

----------

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

From report at bugs.python.org  Tue Apr  6 07:08:14 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 06 Apr 2010 05:08:14 +0000
Subject: [issue8280] urllib2 passes fragment identifier to server
In-Reply-To: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>
Message-ID: <1270530494.04.0.851213030754.issue8280@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
resolution:  -> accepted

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

From report at bugs.python.org  Tue Apr  6 09:54:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Apr 2010 07:54:48 +0000
Subject: [issue6090] zipfile DeprecationWarning Python 2.5/2.6
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1270540488.19.0.361649738794.issue6090@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This code is broken in 2.7alpha4 - it doesn't add file at all.

Traceback (most recent call last):
  File "test.py", line 5, in <module>
    new.writestr(zi,'fgh')
  File "C:\~env\Python27\lib\zipfile.py", line 1099, in writestr
    self.fp.write(zinfo.FileHeader())
  File "C:\~env\Python27\lib\zipfile.py", line 342, in FileHeader
    len(filename), len(extra))
struct.error: ushort format requires 0 <= number <= USHRT_MAX

----------
components: +Library (Lib) -Extension Modules
nosy: +techtonik
title: zipfile DeprecationWarning Python 2.6.2 -> zipfile DeprecationWarning Python 2.5/2.6
versions: +Python 2.5, Python 2.7
Added file: http://bugs.python.org/file16775/test6090.py

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

From report at bugs.python.org  Tue Apr  6 10:17:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Apr 2010 08:17:42 +0000
Subject: [issue6090] zipfile DeprecationWarning Python 2.5/2.6
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1270541862.18.0.729518353573.issue6090@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.5

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

From report at bugs.python.org  Tue Apr  6 10:18:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 06 Apr 2010 08:18:38 +0000
Subject: [issue8320] docs on socket.recv_into doesn't mention the return value
In-Reply-To: <1270491216.65.0.230513280348.issue8320@psf.upfronthosting.co.za>
Message-ID: <1270541918.13.0.224346552365.issue8320@psf.upfronthosting.co.za>


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

Thanks, fixed in r79822.

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

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

From report at bugs.python.org  Tue Apr  6 10:41:12 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Apr 2010 08:41:12 +0000
Subject: [issue2824] zipfile to handle duplicate files in archive
In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
Message-ID: <1270543272.46.0.488956220131.issue2824@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Still an issue for Python 2.7

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file16776/test2824.py

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

From report at bugs.python.org  Tue Apr  6 10:57:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Apr 2010 08:57:36 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1270544256.1.0.783316136627.issue8322@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of SSL_CTX_new manual page:


SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)

  A TLS/SSL connection established with these methods will understand
  the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
  client hello messages and will indicate that it also understands
  SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1
  client hello messages. This is the best choice when compatibility
  is a concern.

I don't think that "Client protocol SSLv23 succeeded with server protocol SSLv3" or "Client protocol SSLv23 succeeded with server protocol TLSv1" are errors.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Apr  6 11:05:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 09:05:25 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1270544725.38.0.467763027631.issue8322@psf.upfronthosting.co.za>


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

It begs the question of why the tests succeed with previous OpenSSL versions.
The only possibly relevant entry I could find in the OpenSSL changelog (but I'm not an expert) is the following:

  *) If no SSLv2 ciphers are used don't use an SSLv2 compatible client hello:
     this allows the use of compression and extensions. Change default cipher
     string to remove SSLv2 ciphersuites. This effectively avoids ancient SSLv2
     by default unless an application cipher string requests it.
     [Steve Henson]

----------

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

From report at bugs.python.org  Tue Apr  6 11:10:32 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Apr 2010 09:10:32 +0000
Subject: [issue2228] Imaplib speedup patch
In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za>
Message-ID: <1270545032.34.0.754082143181.issue2228@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
components: +Library (Lib)
type: resource usage -> performance
versions: +Python 2.7

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

From report at bugs.python.org  Tue Apr  6 11:24:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 09:24:20 +0000
Subject: [issue7772] test_py3kwarn fails when running the whole test suite
In-Reply-To: <1264358547.08.0.209937802024.issue7772@psf.upfronthosting.co.za>
Message-ID: <1270545860.69.0.624280320768.issue7772@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I very much appreciate flox's efforts here, but IMO we really need some more robust solution to the problem of (testing + global warning state).

See also issue 4180.

----------

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

From report at bugs.python.org  Tue Apr  6 11:35:14 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Apr 2010 09:35:14 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

regrtest command line help can be greatly improved to encourage users run tests.

----------
components: Tests
messages: 102443
nosy: techtonik
severity: normal
status: open
title: improve regrtest command line help
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  6 11:39:25 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 06 Apr 2010 09:39:25 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1270546765.34.0.394333342052.issue8325@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Any suggestions for what these changes would be?

----------
nosy: +eric.smith
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.2

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

From report at bugs.python.org  Tue Apr  6 11:44:21 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Tue, 06 Apr 2010 09:44:21 +0000
Subject: [issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP
	sockets
In-Reply-To: <1265069614.13.0.295096684445.issue7834@psf.upfronthosting.co.za>
Message-ID: <1270547061.18.0.150807745455.issue7834@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

I wouldn't mind producing the patch, if Mathew is OK with this.

----------
nosy: +Yaniv.Aknin

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

From report at bugs.python.org  Tue Apr  6 11:56:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Apr 2010 09:56:17 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1270547777.09.0.698236476988.issue8322@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

All errors concern SSLv23 at server side, and another protocol at client side (SSLv23 for client and server works as expected).

----------

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

From report at bugs.python.org  Tue Apr  6 12:29:51 2010
From: report at bugs.python.org (David Coconut)
Date: Tue, 06 Apr 2010 10:29:51 +0000
Subject: [issue8326] Cannot import name SemLock
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>


New submission from David Coconut <coconut at redbrick.dcu.ie>:

Operating system: Ubuntu 10.04 Lucid Lynx (Beta)

This worked with Python 3.1 on 9.10 Karmic Koala. The same error appears on two separate installations of Lucid.

Issue 3770 does not seem to be relevant here.

Traceback (most recent call last):
File "/usr/lib/python3.1/multiprocessing/synchronize.py", line 28, in <module>
from _multiprocessing import SemLock
ImportError: cannot import name SemLock

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
                                                                        File "main.py", line 16, in <module>
q = JoinableQueue()
File "/usr/lib/python3.1/multiprocessing/__init__.py", line 218, in JoinableQueue
from multiprocessing.queues import JoinableQueue

File "/usr/lib/python3.1/multiprocessing/queues.py", line 22, in <module>
from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition

File "/usr/lib/python3.1/multiprocessing/synchronize.py", line 33, in <module>
" function, see issue 3770.")
                                                                    ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.

----------
messages: 102447
nosy: coconutrb
severity: normal
status: open
title: Cannot import name SemLock
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue Apr  6 12:36:15 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Apr 2010 10:36:15 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1270550175.61.0.211254153705.issue8325@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This should be enough for now. Is HG diff against trunk ok?

----------
keywords: +patch
versions: +Python 2.6
Added file: http://bugs.python.org/file16777/8325.improve-regrtest-help.diff

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

From report at bugs.python.org  Tue Apr  6 12:45:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 10:45:43 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270550743.62.0.183437786159.issue8108@psf.upfronthosting.co.za>


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

Ok, here is a patch fixing all test_ftplib failures (tested with openssl 0.9.8k and 1.0.0).
There are a couple of fixes here:
- a workaround for the strange SSL_shutdown() error return, also witnessed by LightHTTPd users (see URL in comments)
- an auto-retry for SSLSocket.unwrap() in blocking mode
- a bizarre issue in test_ftplib where DTPHandler.handle_close() gets called many times in a test (test_data_connection)

I think the SSL_shutdown() issue should be checked on the OpenSSL mailing-list.

----------

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

From report at bugs.python.org  Tue Apr  6 12:46:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 10:46:05 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270550765.89.0.272398299182.issue8108@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file16778/newssl.patch

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

From report at bugs.python.org  Tue Apr  6 13:05:36 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 06 Apr 2010 11:05:36 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270551936.79.0.470749857386.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

def handle_error(self):
-            raise
+            # Ignore errors while closing, because the remote end could have
+            # abruptly shut down the TCP connection while we are still
+            # waiting for SSL shutdown to finish.
+            if not self._ssl_closing:
+                raise


I don't like this.
I should have said that I think my original patch is wrong as it attempts to shutdown() the SSL layer in asyncore's close() method.
I think that I should have done that in handle_close() instead of close() because the two methods are called in different circumstances and have different meanings:

- handle_close() is supposed to be called when the connection is a about to be closed "in a clean way" (for example: the other end properly finished to transmit all the data).

- close() may be called in different situations, also when the connection gets closed abruptly. In this case we should avoid to shutdown() the SSL layer as we might be dealing with a "dead" connection. The right thing to do in this case is just close() the socket without doing anything else.

IMHO, what we should try to avoid to do here is silently ignoring any error condition as you did in handle_error() method.
What happens if you move the SSL shutdown() call in handle_close() method and leave handle_error() unchanged?

----------

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

From report at bugs.python.org  Tue Apr  6 13:11:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 11:11:16 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1270551936.79.0.470749857386.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270552393.3518.19.camel@localhost>


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

> What happens if you move the SSL shutdown() call in handle_close()
> method and leave handle_error() unchanged?

I get occasional crashes such as the following:

Exception in thread Thread-60:
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 229, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 211, in loop
    poll_fun(timeout, map)
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 154, in poll
    write(obj)
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 88, in write
    obj.handle_error()
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 84, in write
    obj.handle_write_event()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 313, in handle_write_event
    super(SSLConnection, self).handle_write_event()
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 440, in handle_write_event
    self.handle_write()
  File "/home/antoine/cpython/newssl/Lib/asynchat.py", line 174, in handle_write
    self.initiate_send()
  File "/home/antoine/cpython/newssl/Lib/asynchat.py", line 215, in initiate_send
    self.handle_close()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 352, in handle_close
    self._do_ssl_shutdown()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 290, in _do_ssl_shutdown
    self.socket.unwrap()
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 264, in unwrap
    s = self._sslobj.shutdown()
error: [Errno 32] Broken pipe

----------

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

From report at bugs.python.org  Tue Apr  6 13:15:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 11:15:11 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1270552393.3518.19.camel@localhost>
Message-ID: <1270552628.3518.21.camel@localhost>


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

By the way, this "broken pipe" error could be due to the fact that the
FTP_TLS client never tries to call unwrap() on its SSL socket. Perhaps
the close() method should be overriden?

----------

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

From report at bugs.python.org  Tue Apr  6 13:20:41 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 06 Apr 2010 11:20:41 +0000
Subject: [issue1572968] release GIL while doing I/O operations in the mmap
	module
Message-ID: <1270552841.96.0.0746486216743.issue1572968@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

As soon as you're dealing with files (not anonymous mapping), you can get the same type of latency than when using open/read/write...
While it's probably not worth the trouble to release the GIL for every operation involving mmaped-files, there are a couple places where it should be considered, for example:
Modules/mmapmodule.c:new_mmap_object
#ifdef HAVE_FSTAT
#  ifdef __VMS
	/* on OpenVMS we must ensure that all bytes are written to the file */
	if (fd != -1) {
	        fsync(fd);
	}
#  endif

fsync() can take up to a couple seconds, so we should probably allow threads here (this is done only on VMS).
Another place worth looking at is when using msync(), like in mmap_object_dealloc():
	if (m_obj->data!=NULL) {
		msync(m_obj->data, m_obj->size, MS_SYNC);
		munmap(m_obj->data, m_obj->size);
	}

or in mmap_flush_method():
	if (-1 == msync(self->data + offset, size, MS_SYNC)) {
		PyErr_SetFromErrno(mmap_module_error);
		return NULL;
	}

msycn too can take quite a long time to complete.

I can write a patch if someone's willing to review it.

----------
nosy: +neologix

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

From report at bugs.python.org  Tue Apr  6 13:24:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 06 Apr 2010 11:24:44 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1270553084.91.0.243131198032.issue8325@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

That diff format looks fine to me. I'll review the content of your changes in the next day or so.

----------
keywords: +easy, needs review
priority:  -> normal
stage: needs patch -> patch review

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

From report at bugs.python.org  Tue Apr  6 13:39:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 11:39:28 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270553968.02.0.913671675079.issue8108@psf.upfronthosting.co.za>


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

Here is a new patch. It doesn't change handle_error() but instead ignores abruptly closed sockets when doing the SSL shutdown.

The underlying problem seems to be an asyncore limitation: close() can be called after an error such as EPIPE or ECONNABORTED, but asyncore doesn't give us any way to know in advance.

----------
Added file: http://bugs.python.org/file16779/newssl2.patch

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

From report at bugs.python.org  Tue Apr  6 13:40:33 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Tue, 06 Apr 2010 11:40:33 +0000
Subject: [issue8312] Add post/pre hooks for distutils commands
In-Reply-To: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>
Message-ID: <1270554033.19.0.632172718891.issue8312@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

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

From report at bugs.python.org  Tue Apr  6 13:41:29 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Tue, 06 Apr 2010 11:41:29 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1270554089.89.0.0445543121455.issue8324@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

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

From report at bugs.python.org  Tue Apr  6 13:43:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 06 Apr 2010 11:43:11 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270554191.85.0.178087480902.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> By the way, this "broken pipe" error could be due to the fact that the
> FTP_TLS client never tries to call unwrap() on its SSL socket. Perhaps
> the close() method should be overriden?

ftplib.FTP_TLS class already calls unwrap() but only when closing a "secured" *data* connection.
This is never done for the *control* connection as the examples shown in RFC-4217 do that only when dealing with the CCC command which is intended to switch the control connection back to clear text.
Since ftplib.py does not implement the CCC command I would avoid to override its close() method.

As for our test server we are currently shutting down the SSL layer for both connections (control and data) so this might be the cause of EPIPE.
At this proposal I suggest to move the shutdown() call from SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close() and see what happens.
If EPIPE keeps being raised then I would investigate on what EPIPE means in terms of OpenSSL itself. It might mean that the socket is supposed to be closed in which case it's perfectly legitimate.

I'd have a few questions:

> a workaround for the strange SSL_shutdown() error return, also
> witnessed by LightHTTPd users (see URL in comments)

What happens now? I mean... what do we get instead of socket.error: 0?

> an auto-retry for SSLSocket.unwrap() in blocking mode

Wasn't SSL_MODE_AUTO_RETRY option applied in issue 8222 supposed to already do that for us?

> I think the SSL_shutdown() issue should be checked on the OpenSSL 
> mailing-list.

If socket.error: 0 comes from OpenSSL then yes. I was suspecting something like this.

----------

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

From report at bugs.python.org  Tue Apr  6 13:54:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 11:54:32 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270554872.54.0.713163544355.issue8108@psf.upfronthosting.co.za>


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

> As for our test server we are currently shutting down the SSL layer for
> both connections (control and data) so this might be the cause of EPIPE.

I don't understand your reasoning. These are separate connections, closing one shouldn't affect the other.

> At this proposal I suggest to move the shutdown() call from
> SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close() and 
> see what happens.

What happens is that you are taking shortcuts with SSL since you aren't trying to do a proper shutdown :)
If you really think this is a good idea, feel free to give it a try.
But please see newssl2.patch as well.

(of course this is only a test server but AFAIU you would like to make it right)

> What happens now? I mean... what do we get instead of socket.error: 0?

A normal successful return.

> Wasn't SSL_MODE_AUTO_RETRY option applied in issue 8222 supposed to 
> already do that for us?

SSL_MODE_AUTO_RETRY deals with SSL negotiation. SSL_shutdown() has its own separate semantics, which have changed *even in blocking mode*. If I disable auto-retry I get failures such as:

======================================================================
ERROR: test_storbinary (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 505, in test_storbinary
    self.client.storbinary('stor', f)
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 727, in storbinary
    conn.unwrap()
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 264, in unwrap
    s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1374: The operation did not complete (read)

(note how "the operation did not complete" seems to mean that the socket is non-blocking, but the error is happening with the regular blocking FTP client)

----------
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Apr  6 14:00:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Apr 2010 12:00:15 +0000
Subject: [issue8326] Cannot import name SemLock
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1270555215.04.0.824423787071.issue8326@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why do you think issue 3770 is not relevant?  It looks from the traceback like the built version of multiprocessing decided that sem_open wasn't functional.  So this sounds like a lucid packaging problem to me.

----------
components: +Extension Modules
nosy: +r.david.murray
priority:  -> normal
type: crash -> behavior

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

From report at bugs.python.org  Tue Apr  6 14:23:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 06 Apr 2010 12:23:15 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270556595.45.0.70363335826.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> I don't understand your reasoning. These are separate connections, 
> closing one shouldn't affect the other.

I meant another thing. I was talking about the fact that the test server attempts to shutdown() both control and data connections while the client only shutdown() the latter one. Maybe that's why you get EPIPE.

> If you really think this is a good idea, feel free to give it a try.

I whish but I'm having serious setup problems problems because I attempted to install different OpenSSL versions and now I'm no longer able to compile Python.
Anyway, I'll give another try later today. =)

> But please see newssl2.patch as well.

- ftplib.FTP_TLS.quit: I wouldn't call unwrap() here as RFC-4217 does that only when dealing with CCC command which is not implemented by ftplib.py.

- I'd be for calling _do_ssl_shutdown() from handle_close() instead of from close() (reasons explained in my previous message)

- If EPIPE is still raised I'd try to move the shutdown() code from SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close().

----------

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

From report at bugs.python.org  Tue Apr  6 14:23:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Apr 2010 12:23:51 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1270556631.3.0.15166817951.issue8326@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm guessing Matthias might have some insight into this on the Ubuntu side. so I'm adding him as nosy.  I'm thinking this isn't a Python problem, but I could be wrong.

----------
nosy: +doko
title: Cannot import name SemLock -> Cannot import name SemLock on Ubuntu lucid

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

From report at bugs.python.org  Tue Apr  6 14:33:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Apr 2010 12:33:55 +0000
Subject: [issue6090] zipfile DeprecationWarning Python in 2.6, failure in 2.7
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1270557235.81.0.781446731005.issue6090@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Making the stage test needed, since we need to get the test into the test suite as a unit test.

----------
nosy: +r.david.murray
stage: needs patch -> test needed
title: zipfile DeprecationWarning Python 2.5/2.6 -> zipfile DeprecationWarning Python in 2.6, failure in 2.7

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

From report at bugs.python.org  Tue Apr  6 15:10:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 13:10:57 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1270556595.45.0.70363335826.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270559574.3518.25.camel@localhost>


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

> - ftplib.FTP_TLS.quit: I wouldn't call unwrap() here as RFC-4217 does
> that only when dealing with CCC command which is not implemented by
> ftplib.py.

Ok.

> - I'd be for calling _do_ssl_shutdown() from handle_close() instead of
> from close() (reasons explained in my previous message)

This provokes test failures such as:

======================================================================
ERROR: test_dir (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 537, in test_dir
    self.client.dir(lambda x: l.append(x))
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 511, in dir
    self.retrlines(cmd, func)
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 714, in retrlines
    return self.voidresp()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 224, in voidresp
    resp = self.getresp()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 210, in getresp
    resp = self.getmultiline()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 196, in getmultiline
    line = self.getline()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 183, in getline
    line = self.file.readline()
  File "/home/antoine/cpython/newssl/Lib/socket.py", line 445, in readline
    data = self._sock.recv(self._rbufsize)
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 98, in <lambda>
    self.recv = lambda buflen=1024, flags=0: SSLSocket.recv(self, buflen, flags)
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 217, in recv
    return self.read(buflen)
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 138, in read
    return self._sslobj.read(len)
SSLError: The read operation timed out

I have already tested quite a bunch of possibilities (handle_close or
close, silencing EPIPE or not...)

> - If EPIPE is still raised I'd try to move the shutdown() code from
> SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close().

This only makes the server less respectful of the protocol...
I think it is fine to silence EPIPE and friends during SSL shutdown
since, as I've said, asyncore will call handle_close() when the remote
ends has closed the TCP connection.

----------

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

From report at bugs.python.org  Tue Apr  6 15:14:45 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 06 Apr 2010 13:14:45 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270559685.06.0.466778820975.issue8297@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

This patch makes the AttributeError message generated from getting attributes from module object more helpful, that is, print the module name. Now the error message is:
  module object 'mod_name' has no attribute 'xxx'
Instead of:
  'module' object has no attribute 'xxx'

In this patch, I add a function PyObject_GenericFindAttr(), which is almost the same as PyObject_GenericGetAttr(), except that return NULL instead of setting the exception, and make PyObject_GenericGetAttr() call this function and setting exception in the case of NULL return value. Through this, each type can custom its own AttributeError message, while using the uniform process of getting the attribute in PyObject_GenericFindAttr(). For example, PyModuleType's tp_getattro is set to a new function PyModule_GetAttr(), which calls the PyObject_GenericFindAttr() can set the customed AttributeError message.

Besides, I think the super object's AttributeError message should also be improved, but I didn't include that in the patch. I don't know weather it is suitable.

----------
keywords: +patch
Added file: http://bugs.python.org/file16780/issue_8297.diff

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

From report at bugs.python.org  Tue Apr  6 15:17:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 13:17:03 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270559823.5.0.507654514546.issue8108@psf.upfronthosting.co.za>


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

New patch without the quit() method change.

----------
Added file: http://bugs.python.org/file16781/newssl3.patch

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

From report at bugs.python.org  Tue Apr  6 15:56:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 13:56:06 +0000
Subject: [issue1572968] release GIL while doing I/O operations in the mmap
	module
Message-ID: <1270562166.2.0.25123646283.issue1572968@psf.upfronthosting.co.za>


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

This shouldn't really care about VMS here. As for the rest, feel free to propose a patch :)
Please note that most non-trivial system calls, such as ftruncate(), mremap(), even mmap() itself, deserve to be enclosed in Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS pairs.

However, you'll have to be careful that the internal state of the mmap object remains consistent, such that using it from several threads doesn't crash the interpreter.
(you can even add multi-threaded unit tests if you want to be sure of this)

----------

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

From report at bugs.python.org  Tue Apr  6 15:58:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 13:58:18 +0000
Subject: [issue1572968] release GIL while doing I/O operations in the mmap
	module
In-Reply-To: <1270562166.2.0.25123646283.issue1572968@psf.upfronthosting.co.za>
Message-ID: <1270562416.3518.40.camel@localhost>


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

> This shouldn't really care about VMS here.

Correction: /we/ shouldn't really care about VMS here.
And the reason being, of course, that we have neither developers nor
known testers under VMS.
(we don't even know if the current trunk builds there or not)

----------

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

From report at bugs.python.org  Tue Apr  6 16:09:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 06 Apr 2010 14:09:09 +0000
Subject: [issue1572968] release GIL while doing I/O operations in the mmap
	module
Message-ID: <1270562949.66.0.545737248339.issue1572968@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Tue Apr  6 16:20:47 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 06 Apr 2010 14:20:47 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1270563647.28.0.584516670779.issue8188@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I've finished reviewing the patch and I think it's quite ready to be
applied.

The documentation in stdtypes.rst says that P = 2**61-1 on 64-bit
machines. This should be changed to reflect the fact that actually
sizeof long is the deciding factor. I attach a patch that also fixes
the typo pointed out by Christophe Simonis.

----------
Added file: http://bugs.python.org/file16782/doc_stdtypes.patch

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

From report at bugs.python.org  Tue Apr  6 16:32:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 14:32:57 +0000
Subject: [issue6090] zipfile DeprecationWarning Python in 2.6, failure in 2.7
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1270564377.33.0.76274045441.issue6090@psf.upfronthosting.co.za>


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


----------
priority: normal -> critical

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

From report at bugs.python.org  Tue Apr  6 16:34:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 14:34:05 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1270564445.05.0.0432675517416.issue8257@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The decimal changes were implemented by Raymond in r79609 (trunk) and r79602 (py3k).  For the fractions module changes, see issue 8294.

----------
assignee: mark.dickinson -> 
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr  6 16:50:15 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 06 Apr 2010 14:50:15 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1270565415.07.0.0693746515565.issue8322@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Apr  6 17:23:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 15:23:17 +0000
Subject: [issue5198] Strange DeprecationWarning behaviour in module struct
In-Reply-To: <1234250088.94.0.680929615779.issue5198@psf.upfronthosting.co.za>
Message-ID: <1270567397.26.0.7551967059.issue5198@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The wrong location for the DeprecationWarnings was also fixed in trunk in r78690.  I've backported the fix to release26-maint in r79834.

I don't dare mess further with the warnings in a bugfix release;  as Georg points out, the issues are fixed in trunk.  BTW, one of the 2.6 issues (again fixed in trunk) that wasn't mentioned above is that some packs produce *two* overflow-related warnings:

>>> import struct
>>> struct.pack('<L', -1)
__main__:1: DeprecationWarning: struct integer overflow masking is deprecated
__main__:1: DeprecationWarning: 'L' format requires 0 <= number <= 4294967295
'\xff\xff\xff\xff'

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Apr  6 17:45:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 15:45:57 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1270568757.35.0.336259603097.issue8014@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Backported to 3.1 in r79838.

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

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

From report at bugs.python.org  Tue Apr  6 18:08:36 2010
From: report at bugs.python.org (David Andrzejewski)
Date: Tue, 06 Apr 2010 16:08:36 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1270570116.31.0.150490188659.issue8293@psf.upfronthosting.co.za>


David Andrzejewski <site+python.org at davidandrzejewski.com> added the comment:

Now, it turns out that if you send the HTTP "Connection: close" header, the connection does close at the end (because the server closes it).

Still, it seems like this should behave the same regardless of whether it's HTTPConnection or HTTPSConnection.

----------

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

From report at bugs.python.org  Tue Apr  6 18:17:01 2010
From: report at bugs.python.org (Mathew Martineau)
Date: Tue, 06 Apr 2010 16:17:01 +0000
Subject: [issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP
	sockets
In-Reply-To: <1265069614.13.0.295096684445.issue7834@psf.upfronthosting.co.za>
Message-ID: <1270570621.82.0.112658354879.issue7834@psf.upfronthosting.co.za>


Mathew Martineau <mat at martineau.name> added the comment:

Yaniv - Please proceed!

----------

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

From report at bugs.python.org  Tue Apr  6 18:26:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 16:26:59 +0000
Subject: [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: <1270571219.49.0.848847805706.issue8259@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch that unoutrages Python attached:  it allows shift counts of up to sys.maxsize in both left shift and right shift.  I don't have a test for this, since the only tests I can think of (e.g. actually doing 1 << (2**31)) require > 270Mb of RAM, and that may be too much for some of the buildbots.  (We could add a 'largemem' special resource to regrtest, I suppose, but it doesn't seem worth the effort just for this.)

This patch doesn't solve the OPs problem, though.  The PyLong code *could* be modified to accept larger shift counts (e.g., up to 8*PY_SSIZE_T_MAX;  beyond this you'll get a MemoryError anyway), but this seems like a significant effort for little gain.  It might make more sense for right shifting, though.  Anyway, I'd definitely call that a feature request.

----------
assignee:  -> mark.dickinson
keywords: +patch
Added file: http://bugs.python.org/file16783/no_outrage.patch

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

From report at bugs.python.org  Tue Apr  6 18:33:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 16:33:45 +0000
Subject: [issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP
	sockets
In-Reply-To: <1265069614.13.0.295096684445.issue7834@psf.upfronthosting.co.za>
Message-ID: <1270571625.58.0.24413074308.issue7834@psf.upfronthosting.co.za>


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

By the way, even better if you find a way of having unit tests for bluetooth sockets. Is there some kind of "dummy" device which gives predictable results (? la /dev/zero, for example)?

----------

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

From report at bugs.python.org  Tue Apr  6 18:53:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 16:53:58 +0000
Subject: [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: <1270572838.77.0.034766063462.issue8259@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch applied in r79843 (and added forgotten Misc/NEWS entry in r79844);  merged to py3k in r79845.

----------
assignee: mark.dickinson -> 
type:  -> feature request

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

From report at bugs.python.org  Tue Apr  6 19:12:29 2010
From: report at bugs.python.org (Mike Kelly)
Date: Tue, 06 Apr 2010 17:12:29 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270573949.4.0.0984064615848.issue8193@psf.upfronthosting.co.za>


Changes by Mike Kelly <pioto at pioto.org>:


----------
nosy: +pioto

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

From report at bugs.python.org  Tue Apr  6 19:12:30 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 06 Apr 2010 17:12:30 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1270573950.98.0.00321614826329.issue1553375@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

What's the status of this (imo quite useful) new traceback function ?
Shall I provide some help ?

----------

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

From report at bugs.python.org  Tue Apr  6 19:21:06 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 06 Apr 2010 17:21:06 +0000
Subject: [issue8327] unintuitive behaviour of logging message propagation
In-Reply-To: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
Message-ID: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

Crawling into the logging module, I've just discovered its behaviour was actually far from the one I expected, in a consequent gap that the documentation had left.

I thought that depending on the "propagate" parameter of each logger, a message would always try to propagate up the logger hierarchy, and that if that message matched the level of a logger (as well as the global disable() level), then this message would be tested against each handler of that logger.

But it's not at all the way it is : actually, only the level of the "entrance" logger is checked ; if the message is blocked by it, it's the end, parent loggers will never hear about it (even thoiugh they might have a lower level set). On the contrary, if that entrance logger accepts the message, then ALL handlers from the hierarchy are snet the message, without caring about the own level of their related logger.

That's really not the behaviour I would have expected, considering the global_disable > logger_level > handler_level precedence that the doc implicitly showed. Are there rationales behind this that I'm lacking ?

So I'd advocate either (if possible) a patching of the logging system, to reflect that semantic ; or the adding of comprehensive paragraphs to teh doc, to explain what the exact relationship between levels and propagation attribuets are.
Just tell me if a patch is conceivable B-)

----------
components: Library (Lib)
messages: 102477
nosy: pakal
severity: normal
status: open
title: unintuitive behaviour of logging message propagation
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  6 19:27:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 17:27:31 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270574851.55.0.173805217466.issue8193@psf.upfronthosting.co.za>


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

Committed in r79848 (trunk), r79849 (py3k), r79850 (2.6), r79851 (3.1). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr  6 20:19:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 06 Apr 2010 18:19:49 +0000
Subject: [issue8327] unintuitive behaviour of logging message propagation
In-Reply-To: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
Message-ID: <1270577989.08.0.476664922323.issue8327@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Tue Apr  6 20:21:43 2010
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Tue, 06 Apr 2010 18:21:43 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270578103.44.0.541590143208.issue8296@psf.upfronthosting.co.za>


Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com> added the comment:

Despite of several workarounds available on the Web, the problem persists. Almost any exception that is rised in `worker` function while putting or getting tasks from queues result in Pool hang up. Currently, `worker` is only aware of Exception descendants rised inside of the map function parameter.

I've written a unit test that checks if KeyboardInterrupts are handled normally. The source code may be included in `Lib/test/test_multiprocessing.py`.

----------
Added file: http://bugs.python.org/file16784/test_map_keyboard_interrput.py

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

From report at bugs.python.org  Tue Apr  6 20:23:24 2010
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Tue, 06 Apr 2010 18:23:24 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270578204.2.0.575199530361.issue8296@psf.upfronthosting.co.za>


Changes by Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com>:


Removed file: http://bugs.python.org/file16743/test_pool_keyboardinterrupt.py

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

From report at bugs.python.org  Tue Apr  6 20:24:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 18:24:39 +0000
Subject: [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: <1270578279.54.0.796846272642.issue8259@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

By the way, this has nothing to do with int versus long (unless I'm misunderstanding the original issue);  it's simply that large shift counts cause an OverflowError.

I've added a note about this to the docs in r79852.

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

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

From report at bugs.python.org  Tue Apr  6 20:32:05 2010
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Tue, 06 Apr 2010 18:32:05 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270578725.55.0.0278281659748.issue8296@psf.upfronthosting.co.za>


Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com> added the comment:

Here is a patch that fixes this problem. Basically, it catches all the BaseExceptions that could happen during: a) getting a task from the `inqueue`, b) calling a user function, c) putting a task into the `outqueue`. The exception handler puts the exception to the `outqueue`.

It can be cleanly applied on top of revision 78790.

----------
keywords: +patch
Added file: http://bugs.python.org/file16785/fix-sigint.diff

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

From report at bugs.python.org  Tue Apr  6 20:38:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 06 Apr 2010 18:38:29 +0000
Subject: [issue8328] longobject.c: silence warnings (Visual Studio)
In-Reply-To: <1270579109.17.0.48402121763.issue8328@psf.upfronthosting.co.za>
Message-ID: <1270579109.17.0.48402121763.issue8328@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Mark, are you ok with silencing these conversion warnings?

----------
components: Build
files: longobject_vs_warnings_py3k.patch
keywords: patch
messages: 102482
nosy: mark.dickinson, skrah
severity: normal
status: open
title: longobject.c: silence warnings (Visual Studio)
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16786/longobject_vs_warnings_py3k.patch

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

From report at bugs.python.org  Tue Apr  6 20:38:54 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 06 Apr 2010 18:38:54 +0000
Subject: [issue8328] longobject.c: silence warnings (Visual Studio)
In-Reply-To: <1270579109.17.0.48402121763.issue8328@psf.upfronthosting.co.za>
Message-ID: <1270579134.97.0.498140070295.issue8328@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file16787/longobject_vs_warnings_trunk.patch

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

From report at bugs.python.org  Tue Apr  6 20:52:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 18:52:34 +0000
Subject: [issue8328] longobject.c: silence warnings (Visual Studio)
In-Reply-To: <1270579109.17.0.48402121763.issue8328@psf.upfronthosting.co.za>
Message-ID: <1270579954.55.0.706161570457.issue8328@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

These all look fine to me.  Please apply!

----------
assignee:  -> skrah
resolution:  -> accepted

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

From report at bugs.python.org  Tue Apr  6 21:00:23 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 06 Apr 2010 19:00:23 +0000
Subject: [issue8327] unintuitive behaviour of logging message propagation
In-Reply-To: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
Message-ID: <1270580423.28.0.67606833154.issue8327@psf.upfronthosting.co.za>


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

Please see the following link for a rationale of the logging package's design:

http://plumberjack.blogspot.com/2009/09/python-logging-101.html

No patch to the logging system's code is planned, as it is working according to its design. The documentation will be gradually attended to as time allows, and patches will be considered.

----------
assignee:  -> vinay.sajip
components: +Documentation -Library (Lib)
nosy: +vinay.sajip

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

From report at bugs.python.org  Tue Apr  6 21:02:39 2010
From: report at bugs.python.org (Valerio Turturici)
Date: Tue, 06 Apr 2010 19:02:39 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270580559.62.0.13493093621.issue8193@psf.upfronthosting.co.za>


Valerio Turturici <turturici.valerio at gmail.com> added the comment:

Thanks to you! This was my first patch, i'm very happy to contribute :)

----------

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

From report at bugs.python.org  Tue Apr  6 21:26:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 19:26:11 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1270581971.84.0.483759412857.issue7947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Proposed update to math docs.

----------
keywords: +patch
Added file: http://bugs.python.org/file16788/math_docs.patch

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

From report at bugs.python.org  Tue Apr  6 21:39:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 06 Apr 2010 19:39:39 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1270582779.06.0.0802042923091.issue7947@psf.upfronthosting.co.za>


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

Looks good to me.  Is it intentional that the paragraph about signaling NaNs is gone completely?

And is it intentional that you changed behavior -> behaviour? :)

----------

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

From report at bugs.python.org  Tue Apr  6 21:41:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 19:41:03 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1270582863.56.0.165919587036.issue7947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Georg.

Yes and No.

Yes:  Perhaps I should say something about signaling nans, but what was there was just nonsense.

No:  I'll drop the 'u' from behaviour, for the sake of consistency.

----------

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

From report at bugs.python.org  Tue Apr  6 21:48:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 06 Apr 2010 19:48:50 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1270583330.81.0.198225781208.issue7947@psf.upfronthosting.co.za>


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

You don't need to :)

----------

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

From report at bugs.python.org  Tue Apr  6 21:56:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 19:56:48 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1270583808.24.0.375085951226.issue7947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Too late!  Committed in r79858 (trunk) through r79861 (release31-maint).
I added a couple of sentences about signaling nans.

Thanks for reviewing!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr  6 22:15:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 06 Apr 2010 20:15:55 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1270584955.46.0.476972137457.issue7947@psf.upfronthosting.co.za>


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

You didn't give me the chance to review the new sentences!  Now I have to tell you that there is now "NaN", "*NaN*" and "nan" which looks inconsistent... :)

----------

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

From report at bugs.python.org  Tue Apr  6 22:19:35 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 06 Apr 2010 20:19:35 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1270585175.25.0.800144897782.issue7472@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I am submitting the patch as suggested by Yukihiro

----------
keywords: +patch
nosy: +l0nwlf
Added file: http://bugs.python.org/file16789/encoders.diff

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

From report at bugs.python.org  Tue Apr  6 22:35:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 06 Apr 2010 20:35:08 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270586108.94.0.572320110577.issue8296@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +jnoller

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

From report at bugs.python.org  Tue Apr  6 22:46:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Apr 2010 20:46:00 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1270586760.54.0.821945684934.issue7472@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, as I said, I think it would be better to delete the conditional instead.  (That is, that fixing the typo is more likely to lead to a bug).

----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Tue Apr  6 23:10:33 2010
From: report at bugs.python.org (Chris Grebeldinger)
Date: Tue, 06 Apr 2010 21:10:33 +0000
Subject: [issue1303434] Please include pdb with windows distribution
Message-ID: <1270588233.45.0.301334297931.issue1303434@psf.upfronthosting.co.za>


Chris Grebeldinger <cgrebeld at gmail.com> added the comment:

Hi Martin,
  As an aside to the request, is the pdb for the python dll currently available anywhere?

----------
nosy: +cgrebeld

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

From report at bugs.python.org  Tue Apr  6 23:16:50 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 06 Apr 2010 21:16:50 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1270588610.56.0.923045983615.issue2643@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I don't think that calling msync() or FlushViewOfFile() when closing the mmap object or deallocating it is a good idea.
sync()ing dirtied pages to disk is very expensive, blocks the process for a long time, and the OS does a much better job at it (it can be done asynchronously, sync()ing can be grouped, re-ordered, etc).
For example, it took around 7 seconds to msync() a mmap-filed of 300Mb in a quick test I've done.
Furthermore, we don't do this for regular files: when a file object is closed or deallocated, we don't call fsync(), and the documentation makes it clear:

os.fsync(fd)
Force write of file with filedescriptor fd to disk. On Unix, this calls the native fsync() function; on Windows, the MS _commit() function.

If you?re starting with a Python file object f, first do f.flush(), and then do os.fsync(f.fileno()), to ensure that all internal buffers associated with f are written to disk. Availability: Unix, and Windows starting in 2.2.3.

The reason is the same: fsync(), like msync(), is not usually what you want, because of latencies and performance penalties it incurs.
Any application requiring the data to be actually written to disk _must_ call fsync() for file objects, and call the flush() method of mmap objects (which is done just for that reason).

So, for performance and consistency with files, I'd suggest to remove calls to msync() and FlushViewOfFile() from close() and dealloc().
If agreed, I can submit the patch.

> A test could explicitly close a dirtied mmaped file and then open()
> it to check that everything was written, no?

The problem is that when you open() your file, you'll read the data from cache. You have no way to read the data directly from disk (well, there may be, but are higly non portable, like O_DIRECT file or raw IO).
The only check that can be done is tracing the process and checking that msync() is indeed called.

----------
nosy: +neologix

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

From report at bugs.python.org  Tue Apr  6 23:19:39 2010
From: report at bugs.python.org (Mike Kent)
Date: Tue, 06 Apr 2010 21:19:39 +0000
Subject: [issue8329] select.select() can return lists with identical id()'s
In-Reply-To: <1270588778.99.0.319971832918.issue8329@psf.upfronthosting.co.za>
Message-ID: <1270588778.99.0.319971832918.issue8329@psf.upfronthosting.co.za>


New submission from Mike Kent <mike.kent at sage.com>:

If select.select() returns two or more empty lists, these empty lists will all refer to the same list; that is, they will have identical id()'s.  If you then have reason to alter one of the returned empty lists, you are altering all of the returned empty lists.  This can result in some significant debugging time spent, and curse words uttered.

I encountered this in Python 2.5.4, but have not yet verified it on a more recent version.  Searching through the Issue Tracker showed nothing similar.

----------
components: Library (Lib)
messages: 102496
nosy: mrmakent
severity: normal
status: open
title: select.select() can return lists with identical id()'s
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  6 23:20:05 2010
From: report at bugs.python.org (Mike Kent)
Date: Tue, 06 Apr 2010 21:20:05 +0000
Subject: [issue8329] select.select() can return lists with identical id()'s
In-Reply-To: <1270588778.99.0.319971832918.issue8329@psf.upfronthosting.co.za>
Message-ID: <1270588805.78.0.467665743984.issue8329@psf.upfronthosting.co.za>


Changes by Mike Kent <mike.kent at sage.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Tue Apr  6 23:25:34 2010
From: report at bugs.python.org (Kelda)
Date: Tue, 06 Apr 2010 21:25:34 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1270589134.94.0.464069789427.issue4570@psf.upfronthosting.co.za>


Kelda <keldas at gmail.com> added the comment:

Replaced unused variable assignment with a call to set() for illustrative purposes.

----------
keywords: +patch
nosy: +autometa
Added file: http://bugs.python.org/file16790/datastructures.diff

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

From report at bugs.python.org  Tue Apr  6 23:50:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 06 Apr 2010 21:50:40 +0000
Subject: [issue8329] select.select() can return lists with identical id()'s
In-Reply-To: <1270588778.99.0.319971832918.issue8329@psf.upfronthosting.co.za>
Message-ID: <1270590640.96.0.142703609385.issue8329@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r79867.

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

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

From report at bugs.python.org  Wed Apr  7 00:21:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Apr 2010 22:21:45 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1270592505.63.0.417285034518.issue7947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Rats.

nan->NaN in r79871 through r79874.

Then I reread your message...

*NaN* -> Nan in r79875 (trunk);  will merge to other branches tomorrow when my brain might be working again.

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

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

From report at bugs.python.org  Wed Apr  7 00:22:18 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Apr 2010 22:22:18 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270592538.55.0.790564762224.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I just did some profiling.  I?m using visual studio team edition which has some fancy built in profiling.  I decided to compare the performance of the iotest.py script with two cpu threads, running for 10 seconds with processor affinity enabled and disabled.  I added this code to the script:
if affinity:
    import ctypes
    i = ctypes.c_int()
    i.value = 1
    ctypes.windll.kernel32.SetProcessAffinityMask(-1, 1)

Regular instruction counter sampling showed no differences.  There were no indications of excessive time being used in the GIL or any strangeness with the locking primitives.  So, I decided to sample on cpu performance counters.  Following up on my conjecture from yesterday, that this was due to inefficiencies in switching between cpus, I settled on sampling the instruction fetch stall cycles from the instruction fetch unit.  I sample every 1000000 stalls.  I get interesting results.

With affinity:
Functions Causing Most Work
Name	Samples	%
_PyObject_Call	403	99,02
_PyEval_EvalFrameEx	402	98,77
_PyEval_EvalCodeEx	402	98,77
_PyEval_CallObjectWithKeywords	400	98,28
call_function	395	97,05

affinity off:
Functions Causing Most Work
Name	Samples	%
_PyEval_EvalFrameEx	1.937	99,28
_PyEval_EvalCodeEx	1.937	99,28
_PyEval_CallObjectWithKeywords	1.936	99,23
_PyObject_Call	1.936	99,23
_threadstartex	1.934	99,13

When we run on both cores, we get four times as many L1 instruction cache hits!  So, what appears to be happening is that each time that a switch occurs the L1 instruction cache for each core must be repopulated with the python evaluation loop, it having been evacuated on that core during the hiatus.

Note that for this effect to kick in we need a large piece of code excercising the cache, such as the evaluation loop.  Earlier today, I wrote a simple (python free) C program to do similar testing, using a GIL, and found no performance degradation due to multi core, but that program only had a very simple "work" function.

So, this confirms my hypothesis:  The downgrading of the performance of python cpu bound threads on multicore machines stems from the shuttling about of the python evaluation loop between the instruction caches of the individual cores.

How best to combat this?  I'll do some experiments on Windows.  Perhaps we can identify cpu-bound threads and group them on a single core.

----------

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

From report at bugs.python.org  Wed Apr  7 00:33:06 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 06 Apr 2010 22:33:06 +0000
Subject: [issue8327] unintuitive behaviour of logging message propagation
In-Reply-To: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
Message-ID: <1270593186.92.0.642745422197.issue8327@psf.upfronthosting.co.za>


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

Documentation updated (r79876).

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

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

From report at bugs.python.org  Wed Apr  7 00:35:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Apr 2010 22:35:16 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270592538.55.0.790564762224.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270593434.3518.62.camel@localhost>


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

[...]
> _PyObject_Call	403	99,02
[...]
> affinity off:
> Functions Causing Most Work
> Name	Samples	%
[...]
> _PyObject_Call	1.936	99,23
[...]
> _threadstartex	1.934	99,13
> 
> When we run on both cores, we get four times as many L1 instruction cache hits!

You mean we get 4x the number of cache /misses/, right?

This analysis is gratuitous if you can't evaluate/measure/calculate the
actual cost (in proportion of total elapsed or CPU time) of the
instruction cache misses. Perhaps it is actually negligible and the
slowdown is caused by something else.

> How best to combat this?  I'll do some experiments on Windows.
> Perhaps we can identify cpu-bound threads and group them on a single
> core.

IMHO, the OS should handle this. I don't think ad-hoc platform-specific
CPU affinity tweaks belong in the Python core.

----------

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

From report at bugs.python.org  Wed Apr  7 00:47:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Apr 2010 22:47:54 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1270594074.45.0.641834032672.issue8324@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

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

From report at bugs.python.org  Wed Apr  7 00:48:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Apr 2010 22:48:08 +0000
Subject: [issue8312] Add post/pre hooks for distutils commands
In-Reply-To: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>
Message-ID: <1270594088.09.0.402279605736.issue8312@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

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

From report at bugs.python.org  Wed Apr  7 00:56:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 06 Apr 2010 22:56:47 +0000
Subject: [issue1303434] Please include pdb with windows distribution
In-Reply-To: <1270588233.45.0.301334297931.issue1303434@psf.upfronthosting.co.za>
Message-ID: <4BBBBC2C.4010509@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>   As an aside to the request, is the pdb for the python dll currently available anywhere?

Only on my hard disk, and then only for the very last release. The
status of the issue is the same as in 2006: without patches, nothing
will happen.

----------

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

From report at bugs.python.org  Wed Apr  7 01:03:19 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 06 Apr 2010 23:03:19 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1270594999.71.0.641653257571.issue7301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Looks good to me. Updated patch with a couple whitespace changes

----------
Added file: http://bugs.python.org/file16791/issue7301-2.diff

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

From report at bugs.python.org  Wed Apr  7 01:14:52 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 06 Apr 2010 23:14:52 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1270595692.51.0.934237944061.issue7301@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Patch looks good to me too.  Do any of you have commit privileges?  If so, please commit this.  If not assign the issue to me and I'll do it.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Wed Apr  7 01:53:10 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Apr 2010 23:53:10 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270597990.96.0.191599968356.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

The counter is "stall cycles".
During the 10 second run on my 2.4Ghz cpu, we had instruction cache miss stalls for 2 billion cycles (2000 samples of 1000000 cycles per sample).  That does account for around 10% of the availible cpu.

I'm observing something like 20% slowdown, though, so there are probably other causes.

Profiling another counter, "instruction fetches", I see this, for a "fast run":
Functions Causing Most Work
Name	Samples	%
Unknown Frame(s)	10.733	99,49

and for a slow run:
Functions Causing Most Work
Name	Samples	%
Unknown Frame(s)	8.056	99,48

This shows a 20% drop in fetched instructions in the interval (five seconds this time).  Ideally, we should see 12000 samples in the fast case (2.4 ghz, 5s) but we see 10000 due to what cache misses there are in this case.  The cache misses in the "slow" case causes effective instruction fetches to drop by 20% on top of that.

I think that this is proof positive that the slowdown is due to instruction cache misses, at least on this dual core intel machine that I am using.

As for "the OS should handle this", I agree.  But it doesn't.  We are doing something unusual:  Convoying two (or more) threads allowing only one to run at a time.  The OS scheduler isn't built for that.  It can only assume that there will be some parallel execution and so it thinks that it is best to put the two sequential threads on different cpus.  But it is wrong, so the cost associated with cache misses outweighs the benefit of running on another core (zero, in our case).

So, the OS won't handle it, no matter how hard we wish that it would.  It is us that know how these gridlocked threads behave, and we do so much better than any OS scheduler can guess.  So, rather than beat our heads against the rock, I'm going to try to come up with a useful heuristic as to when to switch cores, and when not.  It would be useful as a diagnostic tool, if nothing more.

Ok, so we have established two things, I think:
1) the poor response of IO threads in the presence of CPU threads on thread_pthreads.h implementations (on multicore) is because of greedy gil wait semantics in the current gil.  It's easily fixable by using the implementation ROUNDROBIN_GIL implementation I've shown.
2) The poor performance of competing CPU threads on multicore machines is due to the instruction cache behaviour of non-overlapping thread execution on different cores.

We can fix 1) easily, even with a much less invasive patch than the ones I have put in here.  I'm a bit surprised at the apparent disinterest in such an obvious bug / fix.

As for 2), well, see above.  Nothing we can do, really, except identify those cases where we are releasing GIL just to yield (one case, actually, ceval.c) and try to instruct the OS not to switch cores in that case.  I'll see what I can come up with.

Cheers.

----------

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

From report at bugs.python.org  Wed Apr  7 02:08:21 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 07 Apr 2010 00:08:21 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270598901.29.0.167972116991.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

The analysis of instruction cache behavior is interesting---I could definitely see that coming into play given the heavy penalty that one sees going to multiple cores (it's a side effect in addition everything else that goes wrong such as a huge increase in the number of system calls).

I will only point out that messing around with processor affinities is going to be problematic.  There are C/C++ extensions to Python that intentionally release the GIL and want to run fully multithreaded across as many cores as might be available.  Setting a processor affinities is going to be the exact opposite of what you want for code like that.

----------

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

From report at bugs.python.org  Wed Apr  7 02:11:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Apr 2010 00:11:58 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270597990.96.0.191599968356.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270599234.3518.65.camel@localhost>


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

> The counter is "stall cycles".
> During the 10 second run on my 2.4Ghz cpu, we had instruction cache
> miss stalls for 2 billion cycles (2000 samples of 1000000 cycles per
> sample).  That does account for around 10% of the availible cpu.

Ok, thanks.

> 2) The poor performance of competing CPU threads on multicore machines
> is due to the instruction cache behaviour of non-overlapping thread
> execution on different cores.

Have you tried your measurement approach with ccbench?

> We can fix 1) easily, even with a much less invasive patch than the
> ones I have put in here.  I'm a bit surprised at the apparent
> disinterest in such an obvious bug / fix.

As already said, it's too late for 2.7. And the fix in 3.2 is most
probably better.

----------

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

From report at bugs.python.org  Wed Apr  7 02:45:26 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 07 Apr 2010 00:45:26 +0000
Subject: [issue8330] Failures seen in test_gdb on buildbots
In-Reply-To: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>
Message-ID: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/trunk/builders/alpha%20Debian%20trunk/builds/52/steps/test/logs/stdio
shows some failures in test_gdb:

======================================================================
FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 361, in test_corrupt_ob_type
    'set op->ob_type=0xDEADBEEF')
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 341, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '< at remote 0x1202cf5a8>'
Breakpoint 1 at 0x12007a9e8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x200002f87b0, flags=1)
    at Objects/object.c:330
330		return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=< at remote 0x1202cf5a8>, fp=0x200002f87b0, flags=1)
    at Objects/object.c:330
#1  0x000000012003eaa0 in file_PyObject_Print (op=< at remote 0x1202cf5a8>, f=
    0x20000326280, flags=1) at Objects/fileobject.c:110
#2  0x0000000120045bc8 in PyFile_WriteObject (v=< at remote 0x1202cf5a8>, f=
    <file at remote 0x20000326280>, flags=1) at Objects/fileobject.c:2470
#3  0x000000012010bb90 in PyEval_EvalFrameEx (f=
    Frame 0x1203a0ba0, for file <string>, line 1, in <module> (), throwflag=0)
    at Python/ceval.c:1769
#4  0x00000001201134bc in PyEval_EvalCodeEx (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x0000000120107294 in PyEval_EvalCode (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x0000000120152e08 in run_mod (mod=0x12038b848, filename=
    0x12021cf00 "<string>", globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f48b4d8, arena=0x1203406b0)
    at Python/pythonrun.c:1340
#7  0x0000000120152c2c in PyRun_StringFlags (str=0x1202b2010 "print 42\n", 
    start=257, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f48b4d8)
    at Python/pythonrun.c:1303
#8  0x0000000120150f50 in PyRun_SimpleStringFlags (command=
    0x1202b2010 "print 42\n", flags=0x11f48b4d8) at Python/pythonrun.c:962
#9  0x00000001200185a0 in Py_Main (argc=4, argv=0x11f48b6b8)
    at Modules/main.c:525
#10 0x0000000120016e88 in main (argc=4, argv=0x11f48b6b8)
    at ./Modules/python.c:23


======================================================================
FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 372, in test_corrupt_tp_name
    'set op->ob_type->tp_name=0xDEADBEEF')
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 341, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '42'
Breakpoint 1 at 0x12007a9e8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x200002f87b0, flags=1)
    at Objects/object.c:330
330		return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=42, fp=0x200002f87b0, flags=1) at Objects/object.c:330
#1  0x000000012003eaa0 in file_PyObject_Print (op=42, f=0x20000326280, flags=1)
    at Objects/fileobject.c:110
#2  0x0000000120045bc8 in PyFile_WriteObject (v=42, f=
    <file at remote 0x20000326280>, flags=1) at Objects/fileobject.c:2470
#3  0x000000012010bb90 in PyEval_EvalFrameEx (f=
    Frame 0x1203a0ba0, for file <string>, line 1, in <module> (), throwflag=0)
    at Python/ceval.c:1769
#4  0x00000001201134bc in PyEval_EvalCodeEx (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x0000000120107294 in PyEval_EvalCode (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x0000000120152e08 in run_mod (mod=0x12038b848, filename=
    0x12021cf00 "<string>", globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f4174d8, arena=0x1203406b0)
    at Python/pythonrun.c:1340
#7  0x0000000120152c2c in PyRun_StringFlags (str=0x1202b2010 "print 42\n", 
    start=257, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f4174d8)
    at Python/pythonrun.c:1303
#8  0x0000000120150f50 in PyRun_SimpleStringFlags (command=
    0x1202b2010 "print 42\n", flags=0x11f4174d8) at Python/pythonrun.c:962
#9  0x00000001200185a0 in Py_Main (argc=4, argv=0x11f4176b8)
    at Modules/main.c:525
#10 0x0000000120016e88 in main (argc=4, argv=0x11f4176b8)
    at ./Modules/python.c:23


----------------------------------------------------------------------
Ran 31 tests in 27.624s

FAILED (failures=2)

----------
assignee: dmalcolm
keywords: buildbot
messages: 102509
nosy: dmalcolm
severity: normal
status: open
title: Failures seen in test_gdb on buildbots
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  7 03:36:32 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 07 Apr 2010 01:36:32 +0000
Subject: [issue8331] a documentation grammar fix in logging module
In-Reply-To: <1270604192.13.0.509346290398.issue8331@psf.upfronthosting.co.za>
Message-ID: <1270604192.13.0.509346290398.issue8331@psf.upfronthosting.co.za>


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

Just fixed some grammatical error in the docs of logging module.

----------
assignee: georg.brandl
components: Documentation
files: logging.patch
keywords: patch
messages: 102510
nosy: georg.brandl, l0nwlf, vinay.sajip
severity: normal
status: open
title: a documentation grammar fix in logging module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16792/logging.patch

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

From report at bugs.python.org  Wed Apr  7 04:28:09 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 07 Apr 2010 02:28:09 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1270607289.08.0.13851016906.issue4487@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I tested it on python 2.5, 2.6, 2.7 trunk and 3.2 varying msg.set_charset(x) with x = 'utf8' and 'utf-8' 
Here are the results. Apparantly python 2.x had issue with Test case and 3.2 passed but I guess it is unrelated with the issue.

07:35:40 l0nwlf-MBP:~ $ 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.
>>> from email.MIMEText import MIMEText
>>> msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/message.py", line 131, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 84, in flatten
    self._write(msg)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 109, in _write
    self._dispatch(msg)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 135, in _dispatch
    meth(msg)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 178, in _handle_text
    self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)
>>> msg.set_charset('utf-8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/message.py", line 131, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 84, in flatten
    self._write(msg)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 109, in _write
    self._dispatch(msg)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 135, in _dispatch
    meth(msg)
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py", line 178, in _handle_text
    self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)

07:36:17 l0nwlf-MBP:~ $ python2.6
Python 2.6.5 (r265:79063, Apr  6 2010, 21:34:21) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.MIMEText import MIMEText
>>> msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/message.py", line 135, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 84, in flatten
    self._write(msg)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 109, in _write
    self._dispatch(msg)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 135, in _dispatch
    meth(msg)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 178, in _handle_text
    self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)
>>> msg.set_charset('utf-8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/message.py", line 135, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 84, in flatten
    self._write(msg)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 109, in _write
    self._dispatch(msg)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 135, in _dispatch
    meth(msg)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py", line 178, in _handle_text
    self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)
 
07:36:37 l0nwlf-MBP:~ $ 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.
>>> from email.MIMEText import MIMEText
 >>> msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/email/message.py", line 135, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/usr/local/lib/python2.7/email/generator.py", line 83, in flatten
    self._write(msg)
  File "/usr/local/lib/python2.7/email/generator.py", line 108, in _write
    self._dispatch(msg)
  File "/usr/local/lib/python2.7/email/generator.py", line 134, in _dispatch
    meth(msg)
  File "/usr/local/lib/python2.7/email/generator.py", line 180, in _handle_text
    self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)
>>> msg.set_charset('utf-8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/email/message.py", line 135, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/usr/local/lib/python2.7/email/generator.py", line 83, in flatten
    self._write(msg)
  File "/usr/local/lib/python2.7/email/generator.py", line 108, in _write
    self._dispatch(msg)
  File "/usr/local/lib/python2.7/email/generator.py", line 134, in _dispatch
    meth(msg)
  File "/usr/local/lib/python2.7/email/generator.py", line 180, in _handle_text
    self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)

07:37:06 l0nwlf-MBP:~ $ python3.2
Python 3.2a0 (py3k:79532, Apr  1 2010, 01:48:52) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.mime.text import MIMEText
>>> msg = MIMEText('\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> print (msg.as_string())
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf8"

????????
>>> msg.set_charset('utf-8')
>>> print (msg.as_string())
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"

????????


The aliasing of 'utf-8' into 'utf8' and may be 'utf_8' seems reasonable IMO however Test Case fails.

----------
nosy: +l0nwlf
type:  -> feature request

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

From report at bugs.python.org  Wed Apr  7 04:31:20 2010
From: report at bugs.python.org (John Marter)
Date: Wed, 07 Apr 2010 02:31:20 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1270607480.93.0.205760456006.issue4570@psf.upfronthosting.co.za>


John Marter <jmarter at gmail.com> added the comment:

You may want to add another space before the comment, otherwise it will be the only one not aligned with the others.

----------

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

From report at bugs.python.org  Wed Apr  7 04:50:44 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 07 Apr 2010 02:50:44 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1270608644.21.0.146307537478.issue4570@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I guess giving fruit, the set of unique fruit a different name makes it more clear. Comments alignment fixed.

>>> basket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'}
>>> print(basket)
{'orange', 'bananna', 'pear', 'apple'}
>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
>>> uniquefruit = set(fruit)               # create a set without duplicates
>>> uniquefruit
{'orange', 'pear', 'apple', 'banana'}

----------
nosy: +l0nwlf
Added file: http://bugs.python.org/file16793/datastructure.patch

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

From report at bugs.python.org  Wed Apr  7 04:54:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Apr 2010 02:54:09 +0000
Subject: [issue8331] a documentation grammar fix in logging module
In-Reply-To: <1270604192.13.0.509346290398.issue8331@psf.upfronthosting.co.za>
Message-ID: <1270608849.11.0.472129138961.issue8331@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> accepted
stage:  -> patch review

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

From report at bugs.python.org  Wed Apr  7 04:54:33 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 07 Apr 2010 02:54:33 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270608873.62.0.792005051874.issue8297@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Great -- thanks a lot for taking a stab at this!

----------

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

From report at bugs.python.org  Wed Apr  7 06:06:26 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 07 Apr 2010 04:06:26 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1270613186.02.0.374693851223.issue7301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

applied in r79878 - r79881, thanks!

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

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

From report at bugs.python.org  Wed Apr  7 06:08:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Apr 2010 04:08:15 +0000
Subject: [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: <1270613295.64.0.798054515776.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch was causing a failure in test_codeccallbacks, issue8271v4 fixes the test.
(The failing test in test_codeccallbacks was testing that registering error handlers works, using a function that replaced "\xc0\x80" with "\x00". Since now "\xc0" is an invalid start byte regardless of what follows, the function is now receiving only "\xc0" instead of "\xc0\x80" so I had to change the test.)

----------
keywords: +needs review
Added file: http://bugs.python.org/file16794/issue8271v4.diff

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

From report at bugs.python.org  Wed Apr  7 06:51:09 2010
From: report at bugs.python.org (Kelda)
Date: Wed, 07 Apr 2010 04:51:09 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1270615869.37.0.327229408451.issue4570@psf.upfronthosting.co.za>


Kelda <keldas at gmail.com> added the comment:

I think this change fits well with the rest of the example without having to rework things.  Spacing fixed.

----------
Added file: http://bugs.python.org/file16795/datastructures.diff

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

From report at bugs.python.org  Wed Apr  7 07:15:30 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 07 Apr 2010 05:15:30 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270617330.45.0.841454113161.issue8297@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  7 07:57:08 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Apr 2010 05:57:08 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1270619828.83.0.746196263131.issue4570@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll get to this soon.

----------

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

From report at bugs.python.org  Wed Apr  7 08:02:28 2010
From: report at bugs.python.org (Kelda)
Date: Wed, 07 Apr 2010 06:02:28 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1270620148.73.0.154705218024.issue4570@psf.upfronthosting.co.za>


Changes by Kelda <keldas at gmail.com>:


Removed file: http://bugs.python.org/file16790/datastructures.diff

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

From report at bugs.python.org  Wed Apr  7 08:08:37 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 07 Apr 2010 06:08:37 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270620517.38.0.669385926946.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Rietveld link: http://codereview.appspot.com/810044/show

This patch changes unittest.TestLoader.loadTestsFromName() so that ImportErrors will bubble up when importing from a module with a bad import statement.  Before the method raised an AttributeError.  The unit test code is taken from a patch by Salman Haq.  The patch also includes code adapted from http://twistedmatrix.com .

(This is my first patch, so any guidance is greatly appreciated.  Thanks.)

----------
Added file: http://bugs.python.org/file16796/_patch-7559-3.diff

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

From report at bugs.python.org  Wed Apr  7 08:31:03 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 07 Apr 2010 06:31:03 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1270621863.85.0.170850257659.issue7301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

I committed a somewhat different version of this patch to py3k to handle the warn options now calling for wchars, but this needs more work. Some of the buildbots are unhappy

Seems like the py3k version either needs to fully decode the env values to a unicode obj via the file system encoding (which I doubt is initialized at this point)/surrogateescape, or use something along the lines of char2wchar in python.c

----------
assignee:  -> pjenvey
resolution: fixed -> accepted
status: closed -> open

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

From report at bugs.python.org  Wed Apr  7 10:05:48 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 07 Apr 2010 08:05:48 +0000
Subject: [issue8327] unintuitive behaviour of logging message propagation
In-Reply-To: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
Message-ID: <1270627548.54.0.330947626887.issue8327@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Thanks for the doc patch, if you don't mind I'd just add the paragraph below too, to clarify the fact that logger levels are only "entry points" levels, ignored he rest of the time. There might be slight redundancies with the rest of the (long) documentation, but it's all benefit imo. B-)

"In addition to any handlers directly associated with a logger, *all handlers associated with all ancestors of the logger* are called to dispatch the message (unless the *propagate* flag for a logger is set to a false value, at which point the passing to ancestor handlers stops).

Note that in this process, the level of ancestor loggers is never considered : only their *propagate* attribute and the levels of their loggers canimpact the treatment on the message being dispatched. The level of a logger is thus only acting as an *entry point barrier*, only able to stop the whole dispatch of a message that enters the system through it."

----------

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

From report at bugs.python.org  Wed Apr  7 10:37:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Apr 2010 08:37:37 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270305802.77.0.0073241346145.issue8271@psf.upfronthosting.co.za>
Message-ID: <4BBC4451.7030704@egenix.com>


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

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> I also found out that, according to RFC 3629, surrogates 
>> are considered invalid and they can't be encoded/decoded, 
>> but the UTF-8 codec actually does it.
> 
> Python2 does, but Python3 raises an error.
> 
> Python 2.7a4+ (trunk:79675, Apr  3 2010, 16:11:36)
>>>> u"\uDC80".encode("utf8")
> '\xed\xb2\x80'
> 
> Python 3.2a0 (py3k:79441, Mar 26 2010, 13:04:55)
>>>> "\uDC80".encode("utf8")
> UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 0: surrogates not allowed
> 
> Deny encoding surrogates (in utf8) causes a lot of crashs in Python3, because most functions calling suppose that _PyUnicode_AsString() does never fail: see #6687 (and #8195 and a lot of other crashs). It's not a good idea to change it in Python 2.7, because it would require a huge work and we are close to the first beta of 2.7.

I wonder how that change got into the 3.x branch - I would certainly
not have approved it for the reasons given further up on this ticket.

I think we should revert that change for Python 3.2.

----------

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

From report at bugs.python.org  Wed Apr  7 11:02:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Apr 2010 09:02:04 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <4BBC4451.7030704@egenix.com>
Message-ID: <201004071101.56629.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> >> I also found out that, according to RFC 3629, surrogates
> >> are considered invalid and they can't be encoded/decoded,
> >> but the UTF-8 codec actually does it.
> >
> > Python2 does, but Python3 raises an error.
> > (...)
> 
> I wonder how that change got into the 3.x branch - I would certainly
> not have approved it for the reasons given further up on this ticket.
> 
> I think we should revert that change for Python 3.2.

See r72208 and issue #3672.

pitrou wrote "We could fix it for 3.1, and perhaps leave 2.7 unchanged if some 
people rely on this (for whatever reason)."

----------
title: str.decode('utf8',	'replace') -- conformance with Unicode 5.2.0 -> str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0

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

From report at bugs.python.org  Wed Apr  7 11:19:18 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 07 Apr 2010 09:19:18 +0000
Subject: [issue8332] regrtest single TestClass/test_method
In-Reply-To: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>
Message-ID: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It would be convenient for debug to execute single test_method or TestClass. Running all tests in file can take a long time.

----------
components: Tests
messages: 102524
nosy: techtonik
severity: normal
status: open
title: regrtest single TestClass/test_method
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  7 11:20:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 07 Apr 2010 09:20:08 +0000
Subject: [issue8332] regrtest single TestClass/test_method
In-Reply-To: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>
Message-ID: <1270632008.69.0.113904137308.issue8332@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

regrtest [options] test_file.TestClass
regrtest [options] test_file.test_method

----------

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

From report at bugs.python.org  Wed Apr  7 11:41:01 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Wed, 07 Apr 2010 09:41:01 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1270633261.76.0.621602363101.issue4026@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

This very same problem happens (with Python-2.6.2) on AIX5.3 now too, after upgrading to:
$ oslevel -s
5300-08-09-1013

Unlike before (comparing with old build logs), this AIX5.3 now provides flock() in <sys/file.h> and libbsd.a[shr.o] like AIX6.1.

Interesting enough, /usr/lib/libbsd.a contains 32bit shared objects only, so -lbsd does not help in 64bit mode (don't know if python actually supports 64bit on AIX). I don't have an AIX6.1 to check this.

Because of this, upgrading "checking for flock" from compile- to link-check (eventually trying -lbsd a second time) might help?

----------
nosy: +haubi

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

From report at bugs.python.org  Wed Apr  7 11:41:35 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 07 Apr 2010 09:41:35 +0000
Subject: [issue8331] a documentation grammar fix in logging module
In-Reply-To: <1270604192.13.0.509346290398.issue8331@psf.upfronthosting.co.za>
Message-ID: <1270633295.55.0.548509162837.issue8331@psf.upfronthosting.co.za>


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

Fix checked into trunk (r79888).

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

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

From report at bugs.python.org  Wed Apr  7 11:43:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Apr 2010 09:43:58 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1270633438.69.0.610352349547.issue8314@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's surprising that test_ulonglong fails, while test_longlong passes:  can the Linux Sparc ABI really be treating these two types differently?

Maybe more information could be gained by supplying a more interesting test value than 42---some 8-byte value with all bytes different, for example.

In any case, this seems likely to be a libffi bug somewhere;  maybe we could bring it up on the libffi mailing list.  If we can translate the failing Python code into failing C code first that would probably increase the chances of getting a good answer.  Without access to Sparc hardware, I don't see much other way of making progress here.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Apr  7 12:03:21 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Wed, 07 Apr 2010 10:03:21 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1270634601.26.0.643704043368.issue4026@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

Ohw, looking on another machine, being AIX5.3 TL6:
$ oslevel -s
5300-06-00-0000

Here flock() is provided in libbsd.a(shr.o) (32bit only) too, but it isn't declared in any header-file. So that recent AIX5.3 patchset just adds the flock() declaration, not the function itself (is already there).

----------

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

From report at bugs.python.org  Wed Apr  7 12:14:40 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 07 Apr 2010 10:14:40 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270635280.22.0.401098932856.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Added unittest for tab with and without set filedate.
Removed #7583 dependency with NORMALIZE_WHITESPACE.

----------
Added file: http://bugs.python.org/file16797/issue7585.difflib-tab-unittest.diff

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

From report at bugs.python.org  Wed Apr  7 13:00:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 11:00:06 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1270638006.23.0.0326084084616.issue8314@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have just studied the issue in detail; v8.S is indeed missing support for unsigned long long. Here is a patch.

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file16798/sparc.diff

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

From report at bugs.python.org  Wed Apr  7 13:03:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 11:03:08 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1270638188.5.0.712721666024.issue8314@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed as r79892.

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

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

From report at bugs.python.org  Wed Apr  7 13:12:25 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Wed, 07 Apr 2010 11:12:25 +0000
Subject: [issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP
	sockets
In-Reply-To: <1265069614.13.0.295096684445.issue7834@psf.upfronthosting.co.za>
Message-ID: <1270638745.39.0.285599375504.issue7834@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

I've zero experience with programming bluetooth (to be honest, I only tackled this bug because I'm learning how to contribute to Python and it seemed ultra-easy), so I'm not an authoritative source on whether such a 'loopback' test is possible.

On #bluez in freenode I was told that generally no, there is no 'localhost' for BT sockets, and that a while ago there was a bluetooth emulation tool called 'hciemu' which is no longer maintained.

I'm attaching the patch (it's just a oneliner), it passes regression though obviously isn't really tested by it... I suggest Mathew will try the patch out and see if it helps; we can decide how to proceed from there.

----------
keywords: +patch
Added file: http://bugs.python.org/file16799/zero_l2cap_addr_struct.diff

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

From report at bugs.python.org  Wed Apr  7 13:14:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 11:14:24 +0000
Subject: [issue6090] zipfile DeprecationWarning Python in 2.6, failure in 2.7
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1270638864.86.0.704189945534.issue6090@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug in the code, but in the application. You are passing a date before 1980; this is not supported in zipfiles. Try passing 1980 instead of 1.

I think the error message could be better, though; it should probably be a ValueError.

Reducing the priority to normal.

----------
nosy: +loewis
priority: critical -> normal

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

From report at bugs.python.org  Wed Apr  7 13:49:44 2010
From: report at bugs.python.org (Cyril)
Date: Wed, 07 Apr 2010 11:49:44 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1270640984.59.0.492457226876.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

Here is a patch that implements SSLSocket.get_mode/set_mode, with the SSL_MODE_ENABLE_PARTIAL_WRITE and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER constants defined in the ssl module.

The patch contains a test case and documentation. It's made against trunk 44327 and also applies nicely with --fuzz=3 on a 2.6.5.

There are no compatibility issues as no specific mode is set by default. It's up to the application to call SSLSocket.set_mode before use. I've tested my own use case with a set_mode(SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER), it works nicely.

----------
Added file: http://bugs.python.org/file16800/ssl_mode.patch

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

From report at bugs.python.org  Wed Apr  7 15:08:53 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Wed, 07 Apr 2010 13:08:53 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1270645733.92.0.808253019629.issue6610@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

It seems to me that subprocess is protected against this flaw. Python 2.x has a pure-Python implementation of the child logic (which is susceptible to an unrelated issue). Python 3.x has a C implementation which falls back to pure-Python if the former is not available.

Both implementations test explicitly that they're not closing standard file descriptors after the dup2() call in the child. It is my understanding that test is sufficient, I couldn't reproduce the bug in Python, and thus I think this issue should be closed.

All that said, there was no coverage in subprocess' test for this particular case (spawning a coprocess when the standard fds closed). I'm attaching a patch which adds a testcase to cover it.

----------
keywords: +patch
nosy: +Yaniv.Aknin
Added file: http://bugs.python.org/file16801/test_subprocess_with_standard_fds_closed.diff

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

From report at bugs.python.org  Wed Apr  7 15:09:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Apr 2010 13:09:51 +0000
Subject: [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: <1270645791.98.0.67959669276.issue8271@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  7 15:12:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 13:12:01 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270645921.22.0.26576557249.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I just found a one line example of the problem:

>>> EnumValue(HKEY_PERFORMANCE_DATA, 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 234] More data is available

Other functions are also affected:

>>> QueryValueEx(HKEY_PERFORMANCE_DATA, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 234] More data is available

In a nutshell, the Python implementation of these functions works like this:
  1) Query the API for the length of the value
  2) Allocate a buffer of that size
  3) Query the API for the value

However, the API functions called in step #1 are not guaranteed to be accurate.  It works *most* of the time, but if step #3 returns ERROR_MORE_DATA then we need to dynamically grow the buffer and try again until the data fits.

I'll have a patch (with test cases) ready later today.

----------
versions: +Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr  7 15:18:36 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 07 Apr 2010 13:18:36 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270646316.12.0.121079877852.issue2810@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Great analysis!

----------

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

From report at bugs.python.org  Wed Apr  7 15:34:37 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Apr 2010 13:34:37 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

On Windows/amd64, I get loads of pickling errors in test_multiprocessing.

Type 1 error:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 347, in main
    self = load(from_parent)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 1378, in load
    return Unpickler(file).load()
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 858, in load
    dispatch[key](self)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 880, in load_eof
    raise EOFError
EOFError


Type 2 error:

======================================================================
ERROR: test_fork (__main__.WithManagerTestQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "..\..\Lib\test\test_multiprocessing.py", line 485, in test_fork
    p.start()
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\process.py", line 104, in start
    self._popen = Popen(self)
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 244, in __init__
    dump(process_obj, to_child, HIGHEST_PROTOCOL)
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 167, in dump
    ForkingPickler(file, protocol).dump(obj)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 40, in dispatcher
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 401, in save_reduce
    save(args)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 548, in save_tuple
    save(element)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 396, in save_reduce
    save(cls)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 748, in save_global
    (obj, module, name))
PicklingError: Can't pickle <type 'cStringIO.StringO'>: it's not found as cStringIO.StringO

----------
components: Library (Lib)
messages: 102539
nosy: skrah
priority: high
severity: normal
stage: needs patch
status: open
title: test_multiprocessing: pickling failures
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  7 15:50:15 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Apr 2010 13:50:15 +0000
Subject: [issue8328] longobject.c: silence warnings (Visual Studio)
In-Reply-To: <1270579109.17.0.48402121763.issue8328@psf.upfronthosting.co.za>
Message-ID: <1270648215.07.0.65748192632.issue8328@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed in trunk (r79885), py3k (r79886) and release31-maint (r79891).

Thanks for the review!

----------
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  7 16:01:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 07 Apr 2010 14:01:21 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270648881.98.0.330657955923.issue2810@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> brian.curtin
priority:  -> normal
stage:  -> needs patch
versions:  -Python 2.4, Python 2.5, Python 3.3

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

From report at bugs.python.org  Wed Apr  7 16:05:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 07 Apr 2010 14:05:23 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270649123.73.0.672967632526.issue2810@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee: brian.curtin -> 

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

From report at bugs.python.org  Wed Apr  7 16:25:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Apr 2010 14:25:41 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1270650341.19.0.714713765841.issue3672@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

From report at bugs.python.org  Wed Apr  7 16:41:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Apr 2010 14:41:18 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1270651278.53.0.0888030394429.issue8240@psf.upfronthosting.co.za>


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

The patch adds a new feature, which makes it unsuitable for 2.6. I guess it could be applied to the 2.7 trunk, although a beta is being released and I'm not sure new features are really welcome afterwards. This one is really small and non-controversial, though, so I'd advocate accepting it.

The patch itself looks good.

----------
nosy: +benjamin.peterson
stage: test needed -> commit review

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

From report at bugs.python.org  Wed Apr  7 16:48:11 2010
From: report at bugs.python.org (Tim Golden)
Date: Wed, 07 Apr 2010 14:48:11 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <4BBC9B22.2090305@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Seeing the same thing on 32-bit WinXP on x86

On 07/04/2010 14:34, Stefan Krah wrote:
>
> New submission from Stefan Krah<stefan-usenet at bytereef.org>:
>
> On Windows/amd64, I get loads of pickling errors in test_multiprocessing.
>
> Type 1 error:
>
> Traceback (most recent call last):
>    File "<string>", line 1, in<module>
>    File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 347, in main
>      self = load(from_parent)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 1378, in load
>      return Unpickler(file).load()
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 858, in load
>      dispatch[key](self)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 880, in load_eof
>      raise EOFError
> EOFError
>
>
> Type 2 error:
>
> ======================================================================
> ERROR: test_fork (__main__.WithManagerTestQueue)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "..\..\Lib\test\test_multiprocessing.py", line 485, in test_fork
>      p.start()
>    File "C:\Users\stefan\svn\trunk\lib\multiprocessing\process.py", line 104, in start
>      self._popen = Popen(self)
>    File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 244, in __init__
>      dump(process_obj, to_child, HIGHEST_PROTOCOL)
>    File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 167, in dump
>      ForkingPickler(file, protocol).dump(obj)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 224, in dump
>      self.save(obj)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
>      self.save_reduce(obj=obj, *rv)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
>      save(state)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
>      f(self, obj) # Call unbound method with explicit self
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
>      self._batch_setitems(obj.iteritems())
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
>      save(v)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
>      f(self, obj) # Call unbound method with explicit self
>    File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 40, in dispatcher
>      self.save_reduce(obj=obj, *rv)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 401, in save_reduce
>      save(args)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
>      f(self, obj) # Call unbound method with explicit self
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 548, in save_tuple
>      save(element)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
>      self.save_reduce(obj=obj, *rv)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
>      save(state)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
>      f(self, obj) # Call unbound method with explicit self
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
>      self._batch_setitems(obj.iteritems())
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
>      save(v)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
>      self.save_reduce(obj=obj, *rv)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
>      save(state)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
>      f(self, obj) # Call unbound method with explicit self
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
>      self._batch_setitems(obj.iteritems())
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
>      save(v)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
>      self.save_reduce(obj=obj, *rv)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 396, in save_reduce
>      save(cls)
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
>      f(self, obj) # Call unbound method with explicit self
>    File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 748, in save_global
>      (obj, module, name))
> PicklingError: Can't pickle<type 'cStringIO.StringO'>: it's not found as cStringIO.StringO
>
> ----------
> components: Library (Lib)
> messages: 102539
> nosy: skrah
> priority: high
> severity: normal
> stage: needs patch
> status: open
> title: test_multiprocessing: pickling failures
> type: behavior
> versions: Python 2.7
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue8333>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/mail%40timgolden.me.uk

----------
nosy: +tim.golden

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

From report at bugs.python.org  Wed Apr  7 17:52:25 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 15:52:25 +0000
Subject: [issue8334] winreg.QueryValue should return bytes, not unicode
In-Reply-To: <1270655545.35.0.413426657032.issue8334@psf.upfronthosting.co.za>
Message-ID: <1270655545.35.0.413426657032.issue8334@psf.upfronthosting.co.za>


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

The Windows RegQueryValue function returns a registry value without returning the corresponding type information (e.g., REG_SZ for string, REG_BINARY for binary data, REG_DWORD for a 32-bit number, etc.).

The corresponding wrapper winreg.QueryValue currently calls PyUnicode_FromUnicode on the return data, which is fine if the type happens to be REG_SZ, but gibberish for anything else.  Since the format of data is unknown, it should return a bytes object rather than a unicode object.

If the user wants a REG_SZ converted to the unicode type automatically, than can use winreg.QueryValueEx instead.  QueryValueEx wraps RegQueryValueEx which *does* return the type information of the underlying value.  QueryValueEx uses the type information to convert to an appropriate Python type if possible (or returns a bytes object for unsupported types).

----------
components: Library (Lib), Windows
messages: 102543
nosy: stutzbach
severity: normal
status: open
title: winreg.QueryValue should return bytes, not unicode
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Apr  7 17:56:51 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 07 Apr 2010 15:56:51 +0000
Subject: [issue8334] winreg.QueryValue should return bytes, not unicode
In-Reply-To: <1270655545.35.0.413426657032.issue8334@psf.upfronthosting.co.za>
Message-ID: <1270655811.05.0.141963797193.issue8334@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Extension Modules -Library (Lib)
nosy: +brian.curtin
priority:  -> normal

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

From report at bugs.python.org  Wed Apr  7 17:59:29 2010
From: report at bugs.python.org (Jasmit)
Date: Wed, 07 Apr 2010 15:59:29 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1270655969.46.0.481386060108.issue8275@psf.upfronthosting.co.za>


Jasmit <jsingh at roguewave.com> added the comment:

I was able to fix the issue by modifying and re-compiling ctypes project in Visual Studio 2008.  The following properties were modified:

Release:
configuration Properties->C/C++->Optimization->Optimization: Disabled(/Od)
configuration Properties->C/C++->Optimization->Enable Intrinsic Functions:  No

----------

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

From report at bugs.python.org  Wed Apr  7 18:27:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 07 Apr 2010 16:27:37 +0000
Subject: [issue8334] winreg.QueryValue should return bytes, not unicode
In-Reply-To: <1270655545.35.0.413426657032.issue8334@psf.upfronthosting.co.za>
Message-ID: <1270657657.56.0.418251587857.issue8334@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Wed Apr  7 18:33:38 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 16:33:38 +0000
Subject: [issue8334] winreg.QueryValue should return bytes, not unicode
In-Reply-To: <1270655545.35.0.413426657032.issue8334@psf.upfronthosting.co.za>
Message-ID: <1270658018.06.0.105751189509.issue8334@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Jumped the gun here.  RegQueryValue returns ERROR_DATA_INVALID if the value isn't a string, so converting to Unicode is OK.

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

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

From report at bugs.python.org  Wed Apr  7 18:42:50 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 16:42:50 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270658570.31.0.232674752681.issue2810@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Added file: http://bugs.python.org/file16802/winreg_test.pach

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

From report at bugs.python.org  Wed Apr  7 18:43:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 16:43:07 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270658587.82.0.524550968836.issue2810@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16803/winreg.patch

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

From report at bugs.python.org  Wed Apr  7 18:43:29 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 16:43:29 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270658609.13.0.635801372875.issue2810@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file16728/more_data_is_available.py

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

From report at bugs.python.org  Wed Apr  7 18:43:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 16:43:33 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270658613.83.0.613102356525.issue2810@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file16729/more_data_is_available2.py

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

From report at bugs.python.org  Wed Apr  7 18:43:54 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 07 Apr 2010 16:43:54 +0000
Subject: [issue8330] Failures seen in test_gdb on buildbots
In-Reply-To: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>
Message-ID: <1270658634.63.0.206332809787.issue8330@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

There's also a deprecation warning in that log:
/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py:229: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  if e.message != 'unichr() arg not in range(0x10000) (narrow Python build)':

I'm attaching a fix for this; tested with -Wd and it works.

This doesn't yet address the other two failures.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file16804/fix-test_gdb-deprection-warning.patch

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

From report at bugs.python.org  Wed Apr  7 18:44:38 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 16:44:38 +0000
Subject: [issue2810] _winreg.EnumValue fails when the registry data includes
	multibyte unicode characters
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1270658678.97.0.891753967013.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I've uploaded two patches (against trunk): one to add test cases that demonstrate this bug and another to fix the bug.

----------

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

From report at bugs.python.org  Wed Apr  7 18:48:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Apr 2010 16:48:21 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1270658901.02.0.0608988979044.issue7472@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

After tracing the code further I now understand what the original patch is doing, and yes the spelling correction is the correct fix.  (The issue is that there are two different encodings involved: the input encoding in which the body is encoded when encode_7or8 bit is called, and the 'output' encoding that will be used to render the message when it is serialized to bytes.  In the case of iso-2022, it is used as the output encoding for at least one input encoding that is an eight bit encoding.  iso-2022 is pretty much the *only* encoding that appears as an output encoding different from the input encoding.)

Applying the patch will have to wait until the branch unfreezes.  I also think that I will not apply it to 2.6, since it is not fixing a bug that anyone has reported as breaking their code, but does represent a behavior change.

Since we have proven in the course of analyzing this that the code is untested, perhaps someone would like to write some unit tests for it?

----------
priority: normal -> low
resolution:  -> accepted
versions:  -Python 2.6

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

From report at bugs.python.org  Wed Apr  7 19:26:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Apr 2010 17:26:14 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270661174.26.0.469754003196.issue8297@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a feature request, so it only applies to unreleased versions.  It'll be up to Benjamin whether it can go into 2.7, if the change is approved, since 2.7 is now technically in feature freeze.

The patch also needs unit tests.

I do like the idea of making the error messages more specific.  I have not reviewed the patch itself.

----------
components: +Interpreter Core -Library (Lib)
nosy: +r.david.murray
stage: needs patch -> test needed
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Wed Apr  7 19:46:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Apr 2010 17:46:50 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270662410.36.0.73322276792.issue7559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The unit test passes on trunk for me without the fix applied.

----------

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

From report at bugs.python.org  Wed Apr  7 19:53:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Apr 2010 17:53:29 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1270662809.55.0.115253746713.issue7585@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Great, thanks.  I'll check this in when the branch is unfrozen.

----------
dependencies:  -doctest should normalize tabs when comparing output

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

From report at bugs.python.org  Wed Apr  7 19:54:02 2010
From: report at bugs.python.org (jan matejek)
Date: Wed, 07 Apr 2010 17:54:02 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>


New submission from jan matejek <jmatejek at suse.cz>:

when running testsuite in a clean environment without pre-installed system python, test_distutils fail in test_build_ext, test_get_outputs:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6
LinkError: command 'gcc' failed with exit status 1

full traceback is below.

this is most likely caused by change in r72637:
http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/tests/test_build_ext.py?r1=72637&r2=72636&pathrev=72637
this changes compiler's working directory, so that it can no longer find libpython2.6.so with "-L."
(related to issue 6022 - the comments there point it out)

not sure about proper fix - personally, i don't care much about leaving one more file in builddir, whereas i do care about tests passing in clean env, so for SUSE i'm reverting r72637


full traceback:

test_distutils
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/tests/test_build_ext.py", line 261, in test_get_outputs
    cmd.run()
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py", line 531, in build_extension
    target_lang=language)
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/ccompiler.py", line 769, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/unixccompiler.py", line 259, in link
    raise LinkError, msg
LinkError: command 'gcc' failed with exit status 1

----------
assignee: tarek
components: Distutils
messages: 102552
nosy: matejcik, tarek
severity: normal
status: open
title: distutils test_build_ext's test_get_outputs fails in bootstrap environment
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  7 19:54:32 2010
From: report at bugs.python.org (jan matejek)
Date: Wed, 07 Apr 2010 17:54:32 +0000
Subject: [issue6022] test_distutils leaves a 'foo' file behind in the cwd
In-Reply-To: <1242320757.03.0.676564730728.issue6022@psf.upfronthosting.co.za>
Message-ID: <1270662872.36.0.888918472462.issue6022@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

see issue 8335

----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6022>
_______________________________________

From report at bugs.python.org  Wed Apr  7 19:55:47 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 07 Apr 2010 17:55:47 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270662947.26.0.569255914567.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks, David.  Sorry about that.  The test probably requires one additional level of nesting so that "parts_copy" is not False:

+                    if not parts_copy or not module_not_found:
                         raise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Wed Apr  7 20:00:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Apr 2010 18:00:43 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270663243.08.0.121694375653.issue8333@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 20:05:31 2010
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 07 Apr 2010 18:05:31 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270663531.83.0.0891884610861.issue8333@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

When did this problem start?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 20:54:54 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Apr 2010 18:54:54 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270666494.44.0.118940355311.issue8333@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It was introduced in r79623, and the attached patch makes the problem
go away. I would be happy to apply it, but I perhaps you and Michael
could analyze if there are unwanted dependencies between multiprocessing
and unittest.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 20:55:08 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Apr 2010 18:55:08 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270666508.3.0.239955341661.issue8333@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16805/issue8333.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 21:09:54 2010
From: report at bugs.python.org (Krauzi)
Date: Wed, 07 Apr 2010 19:09:54 +0000
Subject: [issue8336] PyObject_CallObject - Not "reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>


New submission from Krauzi <krauzi_gmbh at yahoo.de>:

In the docs there is written:
"PyObject_CallObject() is ?reference-count-neutral? with respect to its arguments."
This is not correct. Its only reference-count neutral if the call was SUCCESSFUL otherwise the argument is INCREFED! 
Can anyone confirm this?

Cheers Krauzi.

----------
assignee: georg.brandl
components: Documentation
messages: 102557
nosy: Krauzi, georg.brandl
severity: normal
status: open
title: PyObject_CallObject - Not "reference-count-neutral"
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8336>
_______________________________________

From report at bugs.python.org  Wed Apr  7 21:10:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 19:10:35 +0000
Subject: [issue8337] test_gdb fails on Sparc Ubuntu
In-Reply-To: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>
Message-ID: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

test_gdb fails on Sparc-Ubuntu, e.g.

http://www.python.org/dev/buildbot/trunk/builders/sparc%20Ubuntu%20trunk/builds/45/steps/test/logs/stdio

test test_gdb failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 372, in test_corrupt_tp_name
    'set op->ob_type->tp_name=0xDEADBEEF')
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 341, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '42'
Breakpoint 1 at 0x876a8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x70300d38, flags=1)
    at Objects/object.c:330
330		return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=42, fp=0x70300d38, flags=1) at Objects/object.c:330
#1  0x000492f8 in file_PyObject_Print (op=42, f=0x70336098, flags=1)
    at Objects/fileobject.c:110
#2  0x00050774 in PyFile_WriteObject (v=42, f=<file at remote 0x70336098>, 
    flags=1) at Objects/fileobject.c:2470
#3  0x00120d98 in PyEval_EvalFrameEx (f=
    Frame 0x2ab788, for file <string>, line 1, in <module> (), throwflag=0)
    at Python/ceval.c:1769
#4  0x00129658 in PyEval_EvalCodeEx (co=0x70353c28, globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x0011b99c in PyEval_EvalCode (co=0x70353c28, globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x0016c3c8 in run_mod (mod=0x2b1c38, filename=0x23d850 "<string>", globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0xfff8d664, arena=0x2b69d0)
    at Python/pythonrun.c:1340
#7  0x0016c240 in PyRun_StringFlags (str=0x28c008 "print 42\n", start=257, 
    globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0xfff8d664) at Python/pythonrun.c:1303
#8  0x0016a494 in PyRun_SimpleStringFlags (command=0x28c008 "print 42\n", 
    flags=0xfff8d664) at Python/pythonrun.c:962
#9  0x0002190c in Py_Main (argc=4, argv=0xfff8d7e4) at Modules/main.c:536
#10 0x0001fe88 in main (argc=4, argv=0xfff8d7e4) at ./Modules/python.c:23


Because of these ongoing failures, I'm completely disabling the gdb tests for now.

----------
assignee: dmalcolm
keywords: buildbot
messages: 102558
nosy: dmalcolm, loewis
severity: normal
status: open
title: test_gdb fails on Sparc Ubuntu
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8337>
_______________________________________

From report at bugs.python.org  Wed Apr  7 21:11:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 19:11:59 +0000
Subject: [issue8337] test_gdb fails on Sparc Ubuntu
In-Reply-To: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>
Message-ID: <1270667519.36.0.119763192675.issue8337@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Test disabled in r79896.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8337>
_______________________________________

From report at bugs.python.org  Wed Apr  7 21:14:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Apr 2010 19:14:50 +0000
Subject: [issue8337] test_gdb fails on Sparc Ubuntu
In-Reply-To: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>
Message-ID: <1270667690.44.0.959465728032.issue8337@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #8330, same failure, different buildbot.
Unless they need to be tracked separately I'll close this as duplicate

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8337>
_______________________________________

From report at bugs.python.org  Wed Apr  7 21:17:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 07 Apr 2010 19:17:04 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270667824.18.0.86931606089.issue8333@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I expect the unittest tests will fail with that patch applied however... No problem with switching to just using StringIO in unittest though - preferably with a comment as to why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 21:28:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 19:28:40 +0000
Subject: [issue8337] test_gdb fails on Sparc Ubuntu
In-Reply-To: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>
Message-ID: <1270668520.69.0.523731938078.issue8337@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Failures seen in test_gdb on buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8337>
_______________________________________

From report at bugs.python.org  Wed Apr  7 21:35:55 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 07 Apr 2010 19:35:55 +0000
Subject: [issue8337] test_gdb fails on Sparc Ubuntu
In-Reply-To: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>
Message-ID: <1270668955.1.0.444613153008.issue8337@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

( #8330 has a patch for a DeprecationWarning )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8337>
_______________________________________

From report at bugs.python.org  Wed Apr  7 22:07:43 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 07 Apr 2010 20:07:43 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1270670863.04.0.923589650031.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file16806/python-trunk-20100407-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Apr  7 22:48:45 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Apr 2010 20:48:45 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1270673325.34.0.298821505348.issue8240@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Wouldn't it be nicer if mode was a property?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Wed Apr  7 22:51:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 20:51:03 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270673463.43.0.800264190991.issue8333@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Perhaps we could run the multiprocessing tests unbuffered?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 22:51:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 20:51:36 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270673496.39.0.512091605292.issue8333@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

BTW, this is also causing all Windows buildbots to fail.

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 22:52:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 20:52:52 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270673572.26.0.640203263653.issue8333@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Wed Apr  7 22:56:49 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 07 Apr 2010 20:56:49 +0000
Subject: [issue4484] struct: per item endianess specification
In-Reply-To: <1228199205.8.0.509541493061.issue4484@psf.upfronthosting.co.za>
Message-ID: <1270673809.74.0.176784460779.issue4484@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I don't see any reasonale reason for mixing endianess inside a struct, and don't know of any real-life protocol using per-item endianess.
Unless someone comes up with a good reason for doing so, and since no one else seems to be interested by this issue, I'd suggest to close it.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4484>
_______________________________________

From report at bugs.python.org  Wed Apr  7 23:06:02 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 07 Apr 2010 21:06:02 +0000
Subject: [issue8338] Outdated information
In-Reply-To: <1270674362.74.0.217445647634.issue8338@psf.upfronthosting.co.za>
Message-ID: <1270674362.74.0.217445647634.issue8338@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/library/multiprocessing.html

Doc/library/multiprocessing.rst refers to "SimpleHTTPServer.HttpServer".  The patch changes this to "SimpleHTTPRequestHandler" although you may prefer "http.server.SimpleHTTPRequestHandler" or, of course, something entirely different.

Thanks, Dave.

----------
assignee: georg.brandl
components: Documentation
files: multiprocessing_docs.patch
keywords: patch
messages: 102567
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: Outdated information
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16807/multiprocessing_docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8338>
_______________________________________

From report at bugs.python.org  Wed Apr  7 23:39:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Apr 2010 21:39:47 +0000
Subject: [issue4484] struct: per item endianess specification
In-Reply-To: <1228199205.8.0.509541493061.issue4484@psf.upfronthosting.co.za>
Message-ID: <1270676387.77.0.670070727513.issue4484@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree that this seems like something that would rarely be needed.  If it's really necessary, it's possible to break up the format and do the packing/unpacking in fixed-endian pieces.

----------
nosy: +mark.dickinson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4484>
_______________________________________

From report at bugs.python.org  Wed Apr  7 23:42:07 2010
From: report at bugs.python.org (Michael Glassford)
Date: Wed, 07 Apr 2010 21:42:07 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>


New submission from Michael Glassford <glassfordmjg at gmail.com>:

An unfortunate side-effect of this change: 

http://svn.python.org/view/python/branches/release26-maint/Lib/urlparse.py?r1=66717&r2=78235

which was made to fix this issue: 

http://bugs.python.org/issue7904

is that urlparse.urlunparse(urlparse.urlparse('x://')) now returns 'x:' instead of 'x://', and urlparse.urlunparse(urlparse.urlparse('x:///y')) now returns 'x:/y' instead of 'x:///y'.

This behavior exists in at least Python 2.6 and 3.1, but not in 2.5.

----------
messages: 102569
nosy: Michael Glassford
severity: normal
status: open
title: urlunparse(urlparse('x://')) now returns 'x:' instead of 'x://'
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Thu Apr  8 00:06:37 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Apr 2010 22:06:37 +0000
Subject: [issue4484] struct: per item endianess specification
In-Reply-To: <1228199205.8.0.509541493061.issue4484@psf.upfronthosting.co.za>
Message-ID: <1270677997.91.0.483910357426.issue4484@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I concur with Mark and Charles-Francois.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4484>
_______________________________________

From report at bugs.python.org  Thu Apr  8 00:26:48 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 07 Apr 2010 22:26:48 +0000
Subject: [issue8330] Failures seen in test_gdb on buildbots
In-Reply-To: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>
Message-ID: <1270679208.54.0.699407510938.issue8330@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Both of the failing tests use "set" inside gdb to try to corrupt the memory of the inferior process.

I believe the issue here is that reading through 0xDEADBEEF within gdb on this machine isn't generating a RuntimeError; perhaps that _is_ a valid pointer in the address space of that process (or perhaps we're seeing another gdb-vs-gdb version difference aka issue #8279)

Within PrettyPrintTests.test_corrupt_tp_name, such a situation leads to the use of tp_flags, and the presence of Py_TPFLAGS_INT_SUBCLASS leads to python-gdb.py using PyIntObject, and it correctly print "42", even after op->ob_type->tp_name now has a garbage value, whereas the test was expecting the fallback handler.

Within PrettyPrintTests.test_corrupt_ob_type, it appears that we're using FakeRepr, and that ((PyTypeObject*)0xDEADBEEF->tp_name) within the process pointed at a NUL byte, when my code was expecting gdb to fail to read through ((PyTypeObject*)0xDEADBEEF->tp_name) with a RuntimeError.

I'm attaching a patch which tries to generalize the expected output from these tests, so that they pass if the corruption in the inferior process doesn't manage to confuse gdb, and if 0xDEADBEEF happens to point at something unexpected.

I tested this with PrettyPrintTests active (it continues to all pass on my machine), but commented it out when generating the patch.

This also includes the fix for the DeprecationWarning mentioned in msg102546

----------
Added file: http://bugs.python.org/file16808/fix-overfussy-gdb_text_corruption-tests-and-deprecation-warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8330>
_______________________________________

From report at bugs.python.org  Thu Apr  8 00:28:07 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 07 Apr 2010 22:28:07 +0000
Subject: [issue8337] test_gdb fails on Sparc Ubuntu
In-Reply-To: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>
Message-ID: <1270679287.25.0.584285834498.issue8337@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

( #8330 has a patch which may fix this )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8337>
_______________________________________

From report at bugs.python.org  Thu Apr  8 00:49:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 07 Apr 2010 22:49:52 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270680592.84.0.39622583665.issue8333@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

TestResult creates its StringIO buffers even if they aren't use. I can create them on first use and use StringIO.StringIO rather than cStringIO. Will fix now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Thu Apr  8 00:56:11 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 07 Apr 2010 22:56:11 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270680971.65.0.32270395427.issue8333@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Although merely switching to StringIO may not be enough. TestResult objects keep a reference to sys.stdout when they are instantiated and you can't pickle that either.

It is preferable for the reference to be taken at instantiation time rather than stored as a module level reference to be compatible with test runners (like regrtest) that *themselves* replace sys.stdout...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Thu Apr  8 00:59:27 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 07 Apr 2010 22:59:27 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270681167.18.0.85084256802.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

While trying to reproduce the transient test_tarfile errors, I found two more tests that appear to be failing when symlinks cannot be created, now skipped by patch 27.

----------
Added file: http://bugs.python.org/file16809/windows symlink draft 27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 01:22:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 07 Apr 2010 23:22:59 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

It looks like the bytearray documentation wasn't backported when the bytearray code was. See Doc/library/functions.rst

----------
assignee: georg.brandl
components: Documentation
messages: 102576
nosy: brian.curtin, georg.brandl
severity: normal
stage: needs patch
status: open
title: bytearray undocumented on trunk
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Thu Apr  8 01:31:28 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 07 Apr 2010 23:31:28 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270683088.03.0.400404772208.issue8333@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Changing unittest.TestResult to use StringIO instead of cStringIO isn't sufficient. regrtest.py also needs to use StringIO...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Thu Apr  8 02:02:09 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Thu, 08 Apr 2010 00:02:09 +0000
Subject: [issue2824] zipfile to handle duplicate files in archive
In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
Message-ID: <1270684929.35.0.195672652639.issue2824@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

This affect 3.x as well.

Regardless of the exact version this will come out in, I think the only proper solution is one with which we eventually, maybe in two versions' time, end up with a behaviour that raises an exception upon double insertion. Also, we should leave some switch to allow double insertions (as someone may /want/ to create a peculiar file). If we agree that's a worthy end goal, let's see what deprecation path we take to get there.

I feel PEP4/PEP5 cover more significant changes to the language/stdlib than this, but in their spirit I propose the following concrete solution: For the nearest possible version let's issue a DeprecationWarning when adding dual files and provide a global switch that will change the DeprecationWarning into raising a relevant exception instead. For the version after that, let's remove the DeprecationWarning warning altogether and choose one of these behaviours:
 (a) a global switch that will raise by default
 (b) a switch in ZipFile's __init__() that will raise by default
 (c) a switch in ZipFile's write() that will raise by default

I vote for (c), but I think the delta between the options is small.

If this is agreeable with the audience, I'll be happy to produce a patch against 2.7 and 3.2 that will provide the chosen behaviour, as well as change tests and documentation accordingly. I realize that time is of the essence if we want this included in 2.7, and I'll be happy to do the work in a timely manner, so if you're interested kindly let me know what you feel while the iron's hot. Either way, I'll be happy to see it in any future version.

Regarding the behaviour brtzsnr observed, I think it's a separate bug. I'll try to reproduce this behaviour, and open a separate ticket if I manage to do so.

blah. Small bug, many words!

----------
nosy: +Yaniv.Aknin
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2824>
_______________________________________

From report at bugs.python.org  Thu Apr  8 02:15:10 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 08 Apr 2010 00:15:10 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270685710.22.0.433681653286.issue8333@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I believe this issue to now be fixed on trunk. We can close this when the buildbots are passing again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Thu Apr  8 02:19:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Apr 2010 00:19:47 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1270685987.38.0.426933493807.issue8339@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

To fix this, urlparse would have to differentiate between a null netloc and no netloc characters specified at all.  This could be done by using None for one an '' for the other.  I'm not sure that behavior change could be backported to 2.6, though.

Did this issue actually cause a program failure for you in 2.6?  If so the original patch might wind up getting classed as a regression for the 2.6 line.

----------
keywords: +easy
nosy: +orsenthil, r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Thu Apr  8 02:44:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 08 Apr 2010 00:44:12 +0000
Subject: [issue8333] test_multiprocessing: pickling failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270687452.39.0.993657849082.issue8333@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Green build on Windows XP, trunk.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%20trunk/builds/282

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8333>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:12:12 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Thu, 08 Apr 2010 01:12:12 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1270689132.15.0.75061847533.issue7301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Here's a patch for py3k using the same char2wchar as the argv decoder for posix, and better windows handling. Plus an additional nonascii value test. Patch is against r79980 for clarity

----------
Added file: http://bugs.python.org/file16810/issue7301-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:18:03 2010
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 08 Apr 2010 01:18:03 +0000
Subject: [issue8341] sphinx bug?
In-Reply-To: <1270689483.48.0.0642742972458.issue8341@psf.upfronthosting.co.za>
Message-ID: <1270689483.48.0.0642742972458.issue8341@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/library/multiprocessing.html

Indentation is incorrect as displayed and copied from google chrome browser:


 from multiprocessing import Process

def f(name):
    print('hello', name)

 if __name__ == '__main__':
     p = Process(target=f, args=('bob',))
     p.start()
     p.join()

----------
assignee: georg.brandl
components: Documentation
messages: 102583
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: sphinx bug?
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8341>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:21:36 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 01:21:36 +0000
Subject: [issue8342] Python fails to run if launched from NTFS symlink and DLL
	not in PATH
In-Reply-To: <1270689696.22.0.100417980949.issue8342@psf.upfronthosting.co.za>
Message-ID: <1270689696.22.0.100417980949.issue8342@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

While trying to work out a failing test_platform.PlatformTest.test_architecture_via_symlink, I found a more fundamental problem.

In the build environment, python.exe depends on pythonXX.dll being in the same directory as sys.executable to load the interpreter. If Python is launched from an NTFS symlink, sys.executable may be located in a directory other than the DLL, and the interpreter fails to run (returning exit code 0xC0000135).

This may be expected behavior, but it causes test_architecture_via_symlink to fail once Python becomes aware of symlinks in Windows (sans cygwin).

It took me a while to track this down, so I wanted to be sure to document the behavior.

----------
components: Tests, Windows
messages: 102584
nosy: jaraco
severity: normal
status: open
title: Python fails to run if launched from NTFS symlink and DLL not in PATH
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8342>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:25:43 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 01:25:43 +0000
Subject: [issue8342] Python fails to run if launched from NTFS symlink and DLL
	not in PATH
In-Reply-To: <1270689696.22.0.100417980949.issue8342@psf.upfronthosting.co.za>
Message-ID: <1270689943.31.0.142835475936.issue8342@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This attached patch against the py3k branch adds a test that reproduces the described behavior.

----------
keywords: +patch
Added file: http://bugs.python.org/file16811/reproduction as test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8342>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:29:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 08 Apr 2010 01:29:52 +0000
Subject: [issue8342] Python fails to run if launched from NTFS symlink and DLL
	not in PATH
In-Reply-To: <1270689696.22.0.100417980949.issue8342@psf.upfronthosting.co.za>
Message-ID: <1270690192.31.0.578672676309.issue8342@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I have this fixed locally in a version of your os.symlink patch. The solution is to add the directory sys.executable is from to os.environ["Path"], then that test should pass the custom environment when the subprocess is created. I meant to update you on the patch I was almost ready to check-in -- I'll send it in private.

Overall, I don't believe there is an issue here so I'll close this.

----------
nosy: +brian.curtin
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8342>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:40:47 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 01:40:47 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270690847.18.0.714562756005.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've been fighting a failing test in test_platform (when test.support.can_symlink() is True). Turns out the problem is caused by the fact that the Python DLL cannot be resolved when the executable isn't in the same directory (which is the case when launched from a symlink). I've created issue8342 to track this behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:41:24 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 01:41:24 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270690884.75.0.946174320377.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16196/windows symlink draft 25.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:41:32 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 01:41:32 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270690892.55.0.62900924734.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16761/windows symlink draft 26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 03:51:07 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 01:51:07 +0000
Subject: [issue8342] Python fails to run if launched from NTFS symlink and DLL
	not in PATH
In-Reply-To: <1270690192.31.0.578672676309.issue8342@psf.upfronthosting.co.za>
Message-ID: <D67B8A86984F00488D0776065BA56DBDB0793B384F@Teach.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8342>
_______________________________________

From report at bugs.python.org  Thu Apr  8 04:35:34 2010
From: report at bugs.python.org (Michael Glassford)
Date: Thu, 08 Apr 2010 02:35:34 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1270694134.07.0.615738590437.issue8339@psf.upfronthosting.co.za>


Michael Glassford <glassfordmjg at gmail.com> added the comment:

It caused a minor issue with the Schemes extension for Mercurial: the output changed, which caused a unit test to fail. I'm pretty sure I have a Mercurial patch to fix that issue, however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Thu Apr  8 05:59:12 2010
From: report at bugs.python.org (Matt Bond)
Date: Thu, 08 Apr 2010 03:59:12 +0000
Subject: [issue8029] bug in 2to3 dealing with "print FOO,
	" followed by "sys.stdout.write('')"
In-Reply-To: <1267312123.13.0.138693680363.issue8029@psf.upfronthosting.co.za>
Message-ID: <1270699152.8.0.912606362726.issue8029@psf.upfronthosting.co.za>


Matt Bond <bondg at uoguelph.ca> added the comment:

I've attached a patch that fixes this particular idiom as well as a problem with the handling of bare 'print' statements. It also includes updated tests for these issues.

----------
keywords: +patch
nosy: +zxaos
Added file: http://bugs.python.org/file16812/fix8029.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8029>
_______________________________________

From report at bugs.python.org  Thu Apr  8 08:06:16 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Thu, 08 Apr 2010 06:06:16 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270706776.75.0.748897622839.issue7978@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

First, let me cast my vote in favour of leaving select() itself alone, it's excessive to fix this issue with changing select().

Second, while exarkun's comments are accurate, I understand where pitrou is coming from. EINTR is not a pathological case, but it's not commonplace, either. I believe that on modern Unices (I tried Linux and OpenSolaris), the default handler for SIGCHLD will restart interrupted calls. By default, SIGUSR1 and most sane others, will kill the process anyway. So I can understand the purity of the argument that if a process sets a signal handler, it might just as well set SA_RESTART and be done with it.

That said, Imagine I write a forking server with SocketServer which sets a signal handler for SIGCHLD, and I don't set SA_RESTART because I don't think I need to. I believe this is a valid real-world scenario where (a) I don't expect an EINTER-related exception to be raised from SocketServer, (b) SocketServer can actually do something about it, and (c) I doubt the old EINTR behaviour is relied upon by anyone (now I'm /certain/ someone relying on this will pop-up...). I think its a safer bet on behalf of SocketServer (and subprocess, etc) to use something like untilConcludes.

If we agree so far, I believe that an implementation of untilConcludes *should* be added to stdlib ("signal.restartable_call", anyone?). If people agree, I'd be happy to produce the patch (trunk+py3k, doc+test). Other than SocketServer and subprocess, anything else that should use "untilConcludes"?

Finally, to answer pitrou's second question, I'm pretty sure untilConcludes as presented will not hurt other signal handlers. The interrupt handler will be executed before returning to untilConcludes' loop and manually restarting the call, so KeyboardInterrupt (or anything else signalistic) will behave as expected.

I'm attaching a toy 3.x program to play with select() and EINTR, I used it in writing this comment. Gee, it even has an OptionParser CLI to save you some commenting-out.

----------
nosy: +Yaniv.Aknin
Added file: http://bugs.python.org/file16813/eintr_safety.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Thu Apr  8 08:28:56 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 08 Apr 2010 06:28:56 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270708136.07.0.433572390462.issue7978@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

wrapping select in an eintr handler that loops like SocketServer_eintr.diff is fine.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Thu Apr  8 08:33:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 08 Apr 2010 06:33:47 +0000
Subject: [issue8341] sphinx bug?
In-Reply-To: <1270689483.48.0.0642742972458.issue8341@psf.upfronthosting.co.za>
Message-ID: <1270708427.39.0.800073793139.issue8341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It was a bug in the source file.  Fixed in r79901.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8341>
_______________________________________

From report at bugs.python.org  Thu Apr  8 08:41:20 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 08 Apr 2010 06:41:20 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270708880.41.0.31039182903.issue7978@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

According to "man 7 signal" select must be explicitely restarted, regardless of the SA_RESTART flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Thu Apr  8 08:55:48 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 08 Apr 2010 06:55:48 +0000
Subject: [issue8292] Incorrect condition test in platform.py
In-Reply-To: <1270226918.36.0.398729222231.issue8292@psf.upfronthosting.co.za>
Message-ID: <1270709748.35.0.273690712209.issue8292@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

It seems that the "Lib/lib2to3/fixes/fix_filter.py" should have fixed all the "filter" problem in py3k, by adding a "list()" call to "filter()". It's werid this one still exists in standar library. 

Also I found other two problems with "filter" in standar library. 
They make condition tests on filter object, although the result is correct, but I think it's not proper.

So I make a patch to fix these three problems.

----------
components: +Library (Lib)
keywords: +patch
nosy: +ysj.ray
Added file: http://bugs.python.org/file16814/issue_8292.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8292>
_______________________________________

From report at bugs.python.org  Thu Apr  8 09:19:53 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 08 Apr 2010 07:19:53 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270711193.7.0.844595409132.issue7978@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> If we agree so far, I believe that an implementation of untilConcludes *should* be added to stdlib ("signal.restartable_call", anyone?).

Definitely, it's better to have this handler written once and correct than having various implementations scattered around libraries.

> If people agree, I'd be happy to produce the patch (trunk+py3k, doc+test).

Go ahead :-)

> According to "man 7 signal" select must be explicitely restarted, regardless of the SA_RESTART flag.

man sigaction states this:

    SA_RESTART 

Provide behaviour compatible with BSD signal semantics by making _certain_ system calls restartable across signals. 

Indeed: you can't really rely on SA_RESTART, since certain syscalls are not restartable, and this flag isn't really portable.
select is even specific since the file descriptor sets can be modified, and the timeout too.

That's why it's definitely better to take the EINTR-wrapper approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Thu Apr  8 09:33:19 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 08 Apr 2010 07:33:19 +0000
Subject: [issue8336] PyObject_CallObject - Not "reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270711999.22.0.793886473799.issue8336@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

By looking into the source, I found PyObject_CallObject() is ?reference-count-neutral? even the call is FAILED, because it will always call Py_DECREF(arg) in the end and in case of exception.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8336>
_______________________________________

From report at bugs.python.org  Thu Apr  8 09:46:09 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 08 Apr 2010 07:46:09 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270712769.53.0.194775966453.issue8297@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

The unittest of this patch.

----------
Added file: http://bugs.python.org/file16815/issue_8297_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8297>
_______________________________________

From report at bugs.python.org  Thu Apr  8 09:46:40 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 08 Apr 2010 07:46:40 +0000
Subject: [issue8336] PyObject_CallObject - Not "reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270712800.02.0.451132656807.issue8336@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed, every function of the API is consistent in this aspect, success or failure should not make a difference in reference counts.  Do you have an evidence of the contrary?

Note that it's possible that because of the failure, some argument is stored in an exception (maybe indirectly, through the traceback which contains active frames and their local variables), which increases its reference count. Clearing the exception should release the reference.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8336>
_______________________________________

From report at bugs.python.org  Thu Apr  8 09:51:55 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 08 Apr 2010 07:51:55 +0000
Subject: [issue2824] zipfile to handle duplicate files in archive
In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
Message-ID: <1270713115.42.0.239677469321.issue2824@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

On the second thought having a switch for a low-level zip format hacking is a good addition. It may also be used for in-place removals from .zip file by erasing directory entry. Otherwise remove operation will require repacking archive into temporary file, which is too high level and vulnerable to disk space/permission matters.

So, I vote for:
(b) a switch in ZipFile's __init__() that will raise by default
and also because you'd need to modify write() and writestr().

class zipfile.ZipFile(file[, mode[, compression[, allowZip64, [low_level]]]]) 

"""Added in version 2.7: If `low_level` compatibility switch is set (False by default), then ZipFile allows low level operations, such as adding two files with the same name without raising an exception. This is for compatibility with previous versions.""" 

BTW, allowZip64 would be nice to be aliased/deprecated in favor of allow_zip64 for consistency with other double word params in module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2824>
_______________________________________

From report at bugs.python.org  Thu Apr  8 10:00:56 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Apr 2010 08:00:56 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270713656.29.0.937131297408.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Confirmed on Windows 7 under qemu with a fresh trunk checkout.

----------
nosy: +skrah
priority: low -> high
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Thu Apr  8 10:02:46 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 08 Apr 2010 08:02:46 +0000
Subject: [issue8336] PyObject_CallObject - Not "reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270713766.43.0.935214434859.issue8336@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Yes. I think if the argument object's reference count is increased because of the exception traceback or other cases, it has nothing to do with the PyObject_CallObject itself. Both of the Py_INCREF(arg) and Py_DECREF(arg) will always run once through the PyObject_CallObject() call. 
The ?reference-count-neutral? means the code of PyObject_CallObject() itself can guarantee the "reference-count-neutral", but not include the callable called by PyObject_CallObject().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8336>
_______________________________________

From report at bugs.python.org  Thu Apr  8 10:36:53 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Apr 2010 08:36:53 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270715813.1.0.133672938365.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

FYI, there seems to be a bug in the code cited above:

http://twistedmatrix.com/trac/browser/trunk/twisted/python/reflect.py#L382

For example, _importAndCheckStack('package.subpackage.module') raises
_NoModuleFound in the following scenario:

package/subpackage/__init__.py:
   import no_exist

when it should instead raise an ImportError from the buggy __init__.py.

I now think there should be at least a few unit tests to cover this case and a couple similar permutations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Thu Apr  8 10:52:12 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 08 Apr 2010 08:52:12 +0000
Subject: [issue8343] improve re parse error messages for named groups
In-Reply-To: <1270716731.5.0.82696133579.issue8343@psf.upfronthosting.co.za>
Message-ID: <1270716731.5.0.82696133579.issue8343@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

sre_parse has some messages among repeated code sequences, but can be tweaked for user convenience

----------
components: Library (Lib)
files: lib.re.improve-error-message.diff
keywords: patch
messages: 102604
nosy: techtonik
severity: normal
status: open
title: improve re parse error messages for named groups
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16816/lib.re.improve-error-message.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8343>
_______________________________________

From report at bugs.python.org  Thu Apr  8 11:39:05 2010
From: report at bugs.python.org (Krauzi)
Date: Thu, 08 Apr 2010 09:39:05 +0000
Subject: [issue8336] PyObject_CallObject - Not "reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270719545.91.0.404947775524.issue8336@psf.upfronthosting.co.za>


Krauzi <krauzi_gmbh at yahoo.de> added the comment:

a i think i expressed the problem false. The problem is that the arg (which is a tuple here) is correctly decremented and thus the reference counts are OK. BUT: The objects INSIDE the tuple are NOT correctly decremented. This is the code i've used:
C++ Program: http://www.copypastecode.com/26047/
Python Script imported by it: http://www.copypastecode.com/26051/
Now the results:
With raise in python script:
http://img251.imageshack.us/img251/997/witherror.jpg
and with uncommented "raise":
http://img256.imageshack.us/img256/2818/noerror.jpg

Hope its now clear.

Krauzi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8336>
_______________________________________

From report at bugs.python.org  Thu Apr  8 11:40:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 09:40:56 +0000
Subject: [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: <1270719656.16.0.63484988556.issue8204@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can reproduce the problem. The root cause is that the "event generate .nb <Control-Tab>" simply does not have any effect - neither through Python, nor through directly wish. Nor do any of the other keys that supposedly cycle through the notebook, when send through "event generate". Typing them directly works fine.

Guilherme, any idea?

----------
assignee:  -> gpolo
nosy: +gpolo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8204>
_______________________________________

From report at bugs.python.org  Thu Apr  8 11:45:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 09:45:13 +0000
Subject: [issue8344] test_tag_configure fails on FreeBSD
In-Reply-To: <1270719913.05.0.699032461994.issue8344@psf.upfronthosting.co.za>
Message-ID: <1270719913.05.0.699032461994.issue8344@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The FreeBSD buildbot reports

FAIL: test_tag_configure (test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/trunk.bolen-freebsd7/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 1116, in test_tag_configure
    'blue')
AssertionError: <color object at 0x29715378> != 'blue'

----------
keywords: buildbot
messages: 102607
nosy: loewis
severity: normal
status: open
title: test_tag_configure fails on FreeBSD
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8344>
_______________________________________

From report at bugs.python.org  Thu Apr  8 11:48:07 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Apr 2010 09:48:07 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270720087.48.0.713638244226.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

According to http://standards.ieee.org/regauth/groupmac/tutorial.html ,
the assertions in check_node are weeding out perfectly valid addresses:

>>> node = 0x525400123456
>>> universal_local_bit = (node >> 40L) & 2
>>> universal_local_bit
2L

This just means that the address is locally administered, but valid.
Similarly, shouldn't an individual_group_bit of 1 should just mean multicast mode?


See also: Issue 7650

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file16817/uuid_mac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Thu Apr  8 11:48:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 09:48:11 +0000
Subject: [issue8344] test_tag_configure fails on FreeBSD
In-Reply-To: <1270719913.05.0.699032461994.issue8344@psf.upfronthosting.co.za>
Message-ID: <1270720091.14.0.545640893448.issue8344@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Apparently, Tk returns a color object instead of a string in this version. Fixed in r79903.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8344>
_______________________________________

From report at bugs.python.org  Thu Apr  8 11:57:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 08 Apr 2010 09:57:10 +0000
Subject: [issue8336] PyObject_CallObject - Not "reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270720630.47.0.854765621563.issue8336@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, I think what I wrote above applies here: the string is stored in the "args" variable. When the exception is raised, the traceback contains the *live* frame objects, with position in the bytecode and all local variables. This allows post-mortem debugging, for example.

Try calling PyErr_PrintEx(0) instead of PyErr_Print(), this should clear the exception state without storing it in sys.last_traceback, and the reference will decrease.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8336>
_______________________________________

From report at bugs.python.org  Thu Apr  8 12:04:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 08 Apr 2010 10:04:42 +0000
Subject: [issue8336] PyObject_CallObject - Not "reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270721082.59.0.760151784785.issue8336@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think this needs to be kept open.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8336>
_______________________________________

From report at bugs.python.org  Thu Apr  8 12:06:10 2010
From: report at bugs.python.org (Derk Drukker)
Date: Thu, 08 Apr 2010 10:06:10 +0000
Subject: [issue8345] missing method MatchObject.groups in re module doc
In-Reply-To: <1270721170.37.0.731757178416.issue8345@psf.upfronthosting.co.za>
Message-ID: <1270721170.37.0.731757178416.issue8345@psf.upfronthosting.co.za>


New submission from Derk Drukker <derk.drukker at gmail.com>:

The method MatchObject.groups disappeared from Doc/library/re.rst in py3k branch r79434 after a merge. (trunk, release26-maint, and release31-maint are fine.)

----------
assignee: georg.brandl
components: Documentation
messages: 102612
nosy: drukker, georg.brandl
severity: normal
status: open
title: missing method MatchObject.groups in re module doc
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8345>
_______________________________________

From report at bugs.python.org  Thu Apr  8 12:21:38 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Apr 2010 10:21:38 +0000
Subject: [issue7650] test_uuid is invalid
In-Reply-To: <1262828995.4.0.365764114727.issue7650@psf.upfronthosting.co.za>
Message-ID: <1270722098.31.0.352388019747.issue7650@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The multicast bit is the least significant bit of the first octet.

Could you check if the patch for http://bugs.python.org/issue3581
fixes your problem?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7650>
_______________________________________

From report at bugs.python.org  Thu Apr  8 12:56:00 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Apr 2010 10:56:00 +0000
Subject: [issue1481] test_uuid is warning about unreliable functions
In-Reply-To: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za>
Message-ID: <1270724160.46.0.669188274317.issue1481@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Still fails with trunk on OpenBSD. The error is more ctypes related
though: _uuid_generate_time isn't set.


======================================================================
ERROR: test_unixdll_getnode (__main__.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_uuid.py", line 332, in test_unixdll_getnode
    self.check_node(uuid._unixdll_getnode(), 'unixdll')
  File "/home/stefan/svn/trunk/Lib/uuid.py", line 429, in _unixdll_getnode
    _uuid_generate_time(_buffer)
TypeError: 'NoneType' object is not callable

----------------------------------------------------------------------

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481>
_______________________________________

From report at bugs.python.org  Thu Apr  8 14:09:15 2010
From: report at bugs.python.org (Firat Ozgul)
Date: Thu, 08 Apr 2010 12:09:15 +0000
Subject: [issue8346] Old Version Name in Interactive Mode
In-Reply-To: <1270728555.35.0.913114676338.issue8346@psf.upfronthosting.co.za>
Message-ID: <1270728555.35.0.913114676338.issue8346@psf.upfronthosting.co.za>


New submission from Firat Ozgul <kistihza at yahoo.com>:

In Python 2.7a4 tutorial, under section "2.1 Invoking the Interpreter" set path command is "set path=%path%;C:\python26". Also under section "2.1.2 Interactive Mode" python command is shown to give "Python 2.6 (#1, Feb 28 2007, 00:02:06)"

----------
assignee: georg.brandl
components: Documentation
messages: 102615
nosy: georg.brandl, istihza
severity: normal
status: open
title: Old Version Name in Interactive Mode
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8346>
_______________________________________

From report at bugs.python.org  Thu Apr  8 14:55:39 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 08 Apr 2010 12:55:39 +0000
Subject: [issue8204] test_ttk_guionly assertion error on 3.x linux 64-bit
In-Reply-To: <1270719656.16.0.63484988556.issue8204@psf.upfronthosting.co.za>
Message-ID: <h2uac2200131004080555re4f2041ck99a94b02656fb91d@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Martin v. L??wis added the comment:
>
> I can reproduce the problem. The root cause is that the "event generate .nb <Control-Tab>" simply does not have any effect - neither through Python, nor through directly wish. Nor do any of the other keys that supposedly cycle through the notebook, when send through "event generate". Typing them directly works fine.
>

Could it be caused because the notebook is not focused at the correct
time ? Here in OSX (finally I have one of these) I had to add
self.nb.focus() before that event_generate.

The attached patch is for trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file16818/p1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8204>
_______________________________________
-------------- next part --------------
Index: Lib/lib-tk/test/test_ttk/test_widgets.py
===================================================================
--- Lib/lib-tk/test/test_ttk/test_widgets.py	(revision 79905)
+++ Lib/lib-tk/test/test_ttk/test_widgets.py	(working copy)
@@ -704,6 +704,7 @@
         self.nb.select(0)
 
         support.simulate_mouse_click(self.nb, 5, 5)
+        self.nb.focus()
         self.nb.event_generate('<Control-Tab>')
         self.assertEqual(self.nb.select(), str(self.child2))
         self.nb.event_generate('<Shift-Control-Tab>')

From report at bugs.python.org  Thu Apr  8 15:08:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 13:08:04 +0000
Subject: [issue8204] test_ttk_guionly assertion error on 3.x linux 64-bit
In-Reply-To: <h2uac2200131004080555re4f2041ck99a94b02656fb91d@mail.gmail.com>
Message-ID: <4BBDD530.7090100@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Could it be caused because the notebook is not focused at the correct
> time ? Here in OSX (finally I have one of these) I had to add
> self.nb.focus() before that event_generate.

No, that doesn't help. The event still gets lost. In particular, running

ttk::notebook .nb
.nb add [label .nb.l1 -text hello] -text a
.nb add [label .nb.l2 -text world] -text b
pack .nb
focus .nb
puts [.nb select]
event generate .nb <Key-Right>
puts [.nb select]

in wish prints ".nb.l1" twice; pressing the right key at the end of the
script does cycle properly, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8204>
_______________________________________

From report at bugs.python.org  Thu Apr  8 15:56:22 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 08 Apr 2010 13:56:22 +0000
Subject: [issue8345] missing method MatchObject.groups in re module doc
In-Reply-To: <1270721170.37.0.731757178416.issue8345@psf.upfronthosting.co.za>
Message-ID: <1270734982.53.0.0489775418294.issue8345@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Thanks for reporting this. Fixed in r79906.

----------
assignee: georg.brandl -> brian.curtin
nosy: +brian.curtin -georg.brandl
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8345>
_______________________________________

From report at bugs.python.org  Thu Apr  8 16:38:25 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 08 Apr 2010 14:38:25 +0000
Subject: [issue8204] test_ttk_guionly assertion error on 3.x linux 64-bit
In-Reply-To: <4BBDD530.7090100@v.loewis.de>
Message-ID: <n2pac2200131004080738n5681f732i5c630f82d9905561@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

When I run that alone I get the same effect, maybe there is something
else contributing to the previous result I saw.

focus_force did solve when testing it alone, and I think it is ok to
use focus_force when testing at least.
Here is the sample I tried:

import ttk
import Tkinter as tk

nb = ttk.Notebook()
nb.add(tk.Label(text='hi'), text='a')
nb.add(tk.Label(text='there'), text='b')

nb.pack()
nb.wait_visibility()

nb.focus_force()
print nb.select()
nb.event_generate('<Key-Right>')
print nb.select()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8204>
_______________________________________

From report at bugs.python.org  Thu Apr  8 16:40:45 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 08 Apr 2010 14:40:45 +0000
Subject: [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: <1270737645.33.0.570679957384.issue8204@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file16818/p1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8204>
_______________________________________

From report at bugs.python.org  Thu Apr  8 16:44:08 2010
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Thu, 08 Apr 2010 14:44:08 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1270737848.45.0.201370366749.issue2876@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

What's the consensus on this? I ask since I actually ran into code today that uses DictMixin and as such wasn't converted by the 2to3 tool.

----------
nosy: +asmodai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Thu Apr  8 17:28:53 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Apr 2010 15:28:53 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270740533.54.0.0648045268296.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Four failing unit tests (context code can use clean-up).

----------
Added file: http://bugs.python.org/file16819/_patch-7559-4-unittests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Thu Apr  8 17:35:11 2010
From: report at bugs.python.org (Tim Lesher)
Date: Thu, 08 Apr 2010 15:35:11 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1270740911.07.0.163247798403.issue8070@psf.upfronthosting.co.za>


Tim Lesher <tlesher at gmail.com> added the comment:

I just hit this one myself, and was about to write a bug and patch.

On reviewing the patch:

1. This really has the same issue as the original code: it detects one of a few known return values, and will infinitely loop on an unexpected return value.  It would be better to explicitly check for 0 (continue), E_EOF (exit normally), and any other result (exit abnormally).

2. I don't think you want to unconditionally call PyErr_Print(), because you don't know for sure that an exception is set.

3. Returning 0 from PyRun_InteractiveLoopFlags() when an error occurs is a behavior change, which makes its documentation incorrect (meaning there should also be a doc patch). But to be honest, I don't think it's correct to return 0 in this case. It seems better to return the actual error code (which also requires a doc patch)

If you don't have time to update the patch, let me know and I'll put one together.

----------
nosy: +tlesher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8070>
_______________________________________

From report at bugs.python.org  Thu Apr  8 17:36:42 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Apr 2010 15:36:42 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1270741002.72.0.367545447411.issue2876@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

UserDict.DictMixin needs to convert to collections.MutableMapping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Thu Apr  8 17:51:30 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 08 Apr 2010 15:51:30 +0000
Subject: [issue8330] Failures seen in test_gdb on buildbots
In-Reply-To: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>
Message-ID: <1270741890.42.0.113969905538.issue8330@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8330>
_______________________________________

From report at bugs.python.org  Thu Apr  8 17:53:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Apr 2010 15:53:18 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1270741998.79.0.86397946869.issue2876@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Converting DictMixin to collections.MutableMapping is not necessarily a complete solution.  MutableMapping does not provide all the methods that DictMixin does.  See for example the problems encountered in issue 7975.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Thu Apr  8 18:26:18 2010
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 08 Apr 2010 16:26:18 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270638006.23.0.0326084084616.issue8314@psf.upfronthosting.co.za>
Message-ID: <4BBE03A3.70606@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

Martin, you should probably post your patch to upstream libffi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8314>
_______________________________________

From report at bugs.python.org  Thu Apr  8 18:26:27 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Apr 2010 16:26:27 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270743987.13.0.908631962421.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The new patch test_uuid.patch fixes issue 7650, issue 1481 and this one.

I've applied it to py3k-cdecimal in r79905 and test_uuid is passed
on all buildbots (I did not test on ARM and one FreeBSD bot is still hanging in test_subprocess).

Additionally, the patch works on Windows-qemu (this issue) and OpenBSD-qemu.


Changes:

1. check_node accepts addresses with universal_local_bit set to 1.
   These addresses are valid (like the qemu one).

2. check_node accepts addresses with the multicast bit set to 1.
   These addresses are used for valid random addresses per the RFC
   and uuid.getnode() itself actually may return such a random address.

3. On some platforms, _uuid_generate_time can't be set, so
   _unixdll_getnode fails with a TypeError. This exception
   is now caught.

4. With these changes, there appear to be no more failures, so
   all tests are enabled again.


Could this go into trunk, since the tests actually fail needlessly
on qemu setups?

----------
Added file: http://bugs.python.org/file16820/test_uuid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Thu Apr  8 18:28:57 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Apr 2010 16:28:57 +0000
Subject: [issue1481] test_uuid is warning about unreliable functions
In-Reply-To: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za>
Message-ID: <1270744137.9.0.811387757357.issue1481@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

With test_uuid.patch from issue 3581 (related) no warnings can be seen on the buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481>
_______________________________________

From report at bugs.python.org  Thu Apr  8 18:48:28 2010
From: report at bugs.python.org (Austin English)
Date: Thu, 08 Apr 2010 16:48:28 +0000
Subject: [issue7650] test_uuid is invalid
In-Reply-To: <1262828995.4.0.365764114727.issue7650@psf.upfronthosting.co.za>
Message-ID: <1270745308.27.0.537238153455.issue7650@psf.upfronthosting.co.za>


Austin English <austinenglish+python at gmail.com> added the comment:

>From Juan Lang, who originally pointed out the bug:

My only comment is that the message is now misleading:
-        individual_group_bit = (node >> 40L) & 1
-        universal_local_bit = (node >> 40L) & 2
        message = "%012x doesn't look like a real MAC address" % node
-        self.assertEqual(individual_group_bit, 0, message)
-        self.assertEqual(universal_local_bit, 0, message)
        self.assertNotEqual(node, 0, message)
        self.assertNotEqual(node, 0xffffffffffffL, message)

The test no longer checks for the uuid being a MAC address or not.
Ideally it would be reworded to be less confusing, or perhaps the code
could check the various "flavors" of uuids, and check that a generated
uuid conforms to one of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7650>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:05:33 2010
From: report at bugs.python.org (Martin)
Date: Thu, 08 Apr 2010 17:05:33 +0000
Subject: [issue8347] string capitalize erroneously lower-case any non-first
	letters
In-Reply-To: <1270746333.31.0.107951036323.issue8347@psf.upfronthosting.co.za>
Message-ID: <1270746333.31.0.107951036323.issue8347@psf.upfronthosting.co.za>


New submission from Martin <famart80 at gmail.com>:

When the following is run:
  s='the Los Angeles Symphony';
  s.capitalize();
it displays 'The los angeles symphony'
instead of 'The Los Angeles Symphony'

the str.capitalize() should only deal with the first letter, not lower-case the rest of the letters. The manual correctly describes this, but the actual behavior is not consistent with this description.

----------
components: None
messages: 102629
nosy: famart
severity: normal
status: open
title: string capitalize erroneously lower-case any non-first letters
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8347>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:14:43 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 17:14:43 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270746883.86.0.678716930683.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This patch includes a routine that adds the directory of the python executable to the path before attempting to run a symlinked executable (in test_platform).

----------
Added file: http://bugs.python.org/file16821/windows symlink draft 28.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:20:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 17:20:38 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270747238.83.0.0105538286892.issue1578269@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch has now missed the window for 2.7, so backporting it won't be necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:26:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Apr 2010 17:26:06 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270747566.25.0.450189098046.issue3581@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I trust you on the investigation.

> Could this go into trunk, since the tests actually fail needlessly
> on qemu setups?

Yes, but after the beta:
http://mail.python.org/pipermail/python-dev/2010-April/099132.html

----------
assignee:  -> skrah
resolution:  -> accepted
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:33:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 17:33:42 +0000
Subject: [issue8348] test_urllib2net fails because of bad URL
In-Reply-To: <1270748022.01.0.642764123246.issue8348@psf.upfronthosting.co.za>
Message-ID: <1270748022.01.0.642764123246.issue8348@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Recently, test_urllib2net started failing

======================================================================
ERROR: test_ftp_basic (test.test_urllib2net.TimeoutTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_urllib2net.py", line 227, in test_ftp_basic
    u = _urlopen_with_retry(self.FTP_HOST)
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_urllib2net.py", line 24, in wrapped
    return _retry_thrice(func, exc, *args, **kwargs)
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_urllib2net.py", line 20, in _retry_thrice
    raise last_exc
URLError: <urlopen error ftp error: 550 Failed to change directory.>

Apparently, the directory /pub/mirror/gnu does not exist anymore.

----------
messages: 102633
nosy: doko, loewis
severity: normal
status: open
title: test_urllib2net fails because of bad URL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8348>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:39:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 17:39:28 +0000
Subject: [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: <1270748368.48.0.858375661959.issue8204@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the advice. I managed to fix this (for me) in r79907; I had to force focus before every single event :-(

----------
keywords: +buildbot
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8204>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:41:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 17:41:33 +0000
Subject: [issue8348] test_urllib2net fails because of bad URL
In-Reply-To: <1270748022.01.0.642764123246.issue8348@psf.upfronthosting.co.za>
Message-ID: <1270748493.38.0.135884860977.issue8348@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I changed the URL in r79908.

----------
keywords: +buildbot
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8348>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:44:13 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Apr 2010 17:44:13 +0000
Subject: [issue3081] Py_(X)SETREF macros
In-Reply-To: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>
Message-ID: <1270748653.28.0.684725271699.issue3081@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

The name suggests a different behavior to me - I assumed it would set the reference count to a specific value.  Maybe this is the kind of thing Raymond had in mind when he said "The mnemonic doesn't work for me".

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3081>
_______________________________________

From report at bugs.python.org  Thu Apr  8 19:45:29 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Thu, 08 Apr 2010 17:45:29 +0000
Subject: [issue8347] string capitalize erroneously lower-case any non-first
	letters
In-Reply-To: <1270746333.31.0.107951036323.issue8347@psf.upfronthosting.co.za>
Message-ID: <1270748729.3.0.30025854593.issue8347@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

S.capitalize() -> string

Return a copy of the string S with only its first character
capitalized.

You've misunderstood the docs, only the first character is indeed capitalized. You want string.capwords instead

----------
nosy: +pjenvey
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8347>
_______________________________________

From report at bugs.python.org  Thu Apr  8 20:05:42 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Apr 2010 18:05:42 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270749942.06.0.90676201685.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

The new unit tests pass with this patch (minor clean-up still needed).

----------
Added file: http://bugs.python.org/file16822/_patch-7559-5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Thu Apr  8 20:24:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Apr 2010 18:24:46 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270751086.33.0.540322631102.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I raised the "errno 0" issue on the openssl mailing-list, and I had a nice response by Darryl Miles here:
http://www.mail-archive.com/openssl-users at openssl.org/msg60710.html

The bottom line is that any "socket error" return from unwrap(), that is any "SSL_ERROR_SYSCALL" return from SSL_shutdown(), means that the socket is closed (abruptly or not). In this case, we can't do anything except ignore the error in test_ftplib.

We should also remove the special casing hack in _ssl.c, even though a socket error with "errno 0" isn't particularly informative.

Here is a new patch.

----------
Added file: http://bugs.python.org/file16823/newssl4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Apr  8 21:04:10 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 19:04:10 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270753450.98.0.919897087095.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In the last patch, I addressed test_platform running a test under a symlinked Python. I then found the same error resulting from essentially the same code in test_sysconfig. So I refactored those methods into a generator method in test.support. This is patch 29.

----------
Added file: http://bugs.python.org/file16824/windows symlink draft 28.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 21:06:17 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 19:06:17 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270753577.13.0.0664254621646.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file16825/windows symlink draft 29.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 21:06:24 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 19:06:24 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270753584.49.0.271862096027.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16809/windows symlink draft 27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 21:06:30 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 19:06:30 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270753590.54.0.016971822482.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16821/windows symlink draft 28.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 21:06:37 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 19:06:37 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270753597.73.0.703730460195.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16824/windows symlink draft 28.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Apr  8 22:15:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Apr 2010 20:15:14 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270757714.55.0.481463036937.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

My analysis of SSL_shutdown() was missing something: timeout sockets are really non-blocking sockets in disguise. I guess it's never too late to notice.

OpenSSL doesn't know about the timeout, so we have to do it ourselves. Ironically, the infrastructure is already in place in _ssl.c, and used for read() and write() methods.

So here is a new patch, taking this into account.

----------
Added file: http://bugs.python.org/file16826/newssl5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Apr  8 22:21:03 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 08 Apr 2010 20:21:03 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1270758063.69.0.503818505594.issue2643@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Alright, the current behaviour is quite strange:
we don't call msync() when closing the object, we just unmap() it:
mmap_close_method(mmap_object *self, PyObject *unused)
{
[...]
#ifdef UNIX
        if (0 <= self->fd)
                (void) close(self->fd);
        self->fd = -1;
        if (self->data != NULL) {
                munmap(self->data, self->size);
                self->data = NULL;
        }
#endif
[...]
}

But we set self->data to NULL to avoid calling munmap() a second time when deallocating the object:
static void
mmap_object_dealloc(mmap_object *m_obj)
{
[ ... ]
#ifdef UNIX
        if (m_obj->fd >= 0)
                (void) close(m_obj->fd);
        if (m_obj->data!=NULL) {
                msync(m_obj->data, m_obj->size, MS_SYNC);
                munmap(m_obj->data, m_obj->size);
        }
#endif /* UNIX */
[ ...]
}

So, if the object has been closed properly before being deallocated, msync() is _not_ called.
But, if we don't close the object, then msync() is called.

The attached test script shows the _huge_ performance impact of msync:
when only close() is called (no msync()):
$ ./python /home/cf/test_mmap.py
0.35829615593

when both flush() and close() are called (msync() called):
$ ./python /home/cf/test_mmap.py
4.95999493599

when neither is called, relying on the deallocation (msync() called):
$ ./python /home/cf/test_mmap.py
4.8811671257

And a strace leaves no doubt (called 10 times in a loop) :
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb80b1000 <0.000019>
write(1, "4.12167286873\n"..., 144.12167286873
)      = 14 <0.000012>
close(3)                                = 0 <0.000010>
munmap(0xb80b2000, 4096)                = 0 <0.000023>
rt_sigaction(SIGINT, {SIG_DFL}, {0x811d630, [], 0}, 8) = 0 <0.000011>
close(5)                                = 0 <0.004889>
msync(0xb69f9000, 10000000, MS_SYNC)    = 0 <0.584054>
munmap(0xb69f9000, 10000000)            = 0 <0.000433>

See how expensive msync() is, and this is just for a 10MB file.

So the attached patch (mmap_msync.diff) removes the call to msync from mmap_object_dealloc(). Since UnmapViewOfFile() is only called inside flush() method, nothing to remove for MS Windows.

Here's the result of the same test script with the patch:
when only close() is called (no msync()):
$ ./python /home/cf/test_mmap.py
0.370584011078

when both flush() and close() are called (msync() called):
$ ./python /home/cf/test_mmap.py
4.97467517853

when neither is called, relying on the deallocation (msync() not called):
$ ./python /home/cf/test_mmap.py
0.390102148056

So we only get msync() latency when the user explicitely calls flush().

----------
Added file: http://bugs.python.org/file16827/mmap_msync.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Thu Apr  8 22:21:33 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 08 Apr 2010 20:21:33 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1270758093.94.0.538987328934.issue2643@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file16828/test_mmap.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Thu Apr  8 22:28:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Apr 2010 20:28:21 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270758501.34.0.5188532463.issue7559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thank you very much for those tests.  I think you can simplify them a bit. For example, you can use assertRaises.  You also might be able to use the test_support.temp_cwd context manager in your context manager, even though you don't need the cwd part.

I've attached an alternate, simpler patch to fix this bug, based on a similar fix I did in pydoc.  The disadvantage of my patch is that it contains a hardcoding of the name of the function doing the import.  I think this is acceptable given the much greater simplicity of my patch.  I may be missing some subtlety, though, that the twisted folks know about.  Or perhaps people will just find the hardcoding itself objectionable.

----------
Added file: http://bugs.python.org/file16829/alternate_import_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Thu Apr  8 22:35:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Apr 2010 20:35:29 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1270758929.42.0.507094899865.issue2643@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +akuchling, exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
_______________________________________

From report at bugs.python.org  Thu Apr  8 22:37:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Apr 2010 20:37:10 +0000
Subject: [issue3081] Py_(X)SETREF macros
In-Reply-To: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>
Message-ID: <1270759030.94.0.625000288192.issue3081@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Py_ASSIGN could be a better name, but given the enthusiasm generated by this proposal, I think we might just as well close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3081>
_______________________________________

From report at bugs.python.org  Thu Apr  8 23:03:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Apr 2010 21:03:06 +0000
Subject: [issue3081] Py_(X)SETREF macros
In-Reply-To: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>
Message-ID: <1270760586.94.0.654979580484.issue3081@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree with Raymond about the Py_INCREF.  I could see more uses for this macro without the Py_INCREF, especially for things like in-place arithmetic operations.  The following pattern appears a lot in code like Objects/longobject.c:

Old code:

/* add one to x */
temp = PyNumber_Add(x, one);
Py_DECREF(x);
x = temp;
if (x == NULL)
    return NULL;


With a non-INCREF version of Py_SETREF:

/* add one to x */
Py_SETREF(x, PyNumber_Add(x, one));
if (x == NULL)
    return NULL;

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3081>
_______________________________________

From report at bugs.python.org  Thu Apr  8 23:18:04 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Apr 2010 21:18:04 +0000
Subject: [issue3081] Py_(X)SETREF macros
In-Reply-To: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>
Message-ID: <1270761484.29.0.812750485497.issue3081@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3081>
_______________________________________

From report at bugs.python.org  Thu Apr  8 23:37:23 2010
From: report at bugs.python.org (Dan Brandow)
Date: Thu, 08 Apr 2010 21:37:23 +0000
Subject: [issue8349] os.environ.get returns incorrect data
In-Reply-To: <1270762643.12.0.684015717592.issue8349@psf.upfronthosting.co.za>
Message-ID: <1270762643.12.0.684015717592.issue8349@psf.upfronthosting.co.za>


New submission from Dan Brandow <dan.brandow at gmail.com>:

I have a Windows 7 64 bit machine, which means it has a few different environment variables concerning the program files location:
PROGRAMFILES=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)

Note that both env variables have "(x86)" at the end.

When I do an os.environ.get I get the following results:

Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files
>>> print os.environ.get('ProgramFiles')
C:\Program Files
>>>

Note the missing "(x86)" on the last two test cases.

I tried it on the 64-bit version of 2.5.4 as well:

Python 2.5.4 (r254:67916, Dec 23 2008, 15:19:34) [MSC v.1400 64 bit (AMD64)] on win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files
>>> print os.environ.get('ProgramFiles')
C:\Program Files
>>>

Same result.  So I tried the 32-bit version of 2.5.4:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files (x86)
>>> print os.environ.get('ProgramFiles')
C:\Program Files (x86)
>>>

...which gave the correct strings...

----------
components: Extension Modules
messages: 102646
nosy: dbrandow
severity: normal
status: open
title: os.environ.get returns incorrect data
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8349>
_______________________________________

From report at bugs.python.org  Thu Apr  8 23:43:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 21:43:58 +0000
Subject: [issue8349] os.environ.get returns incorrect data
In-Reply-To: <1270762643.12.0.684015717592.issue8349@psf.upfronthosting.co.za>
Message-ID: <1270763038.33.0.0377095626599.issue8349@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is the correct result. The value of the environment variables depends on whether a 32-bit or a 64-bit process is looking at them, see

http://msdn.microsoft.com/en-us/library/aa384274%28VS.85%29.aspx

----------
nosy: +loewis
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8349>
_______________________________________

From report at bugs.python.org  Fri Apr  9 00:02:39 2010
From: report at bugs.python.org (Todd Whiteman)
Date: Thu, 08 Apr 2010 22:02:39 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>


New submission from Todd Whiteman <twhitema at yahoo.com.au>:

The doc command for os.mkdir is incorrect (at least for posix). It specifies that there is an optional mode keyword, but it's not a keyword argument, see below:

>>> import os
>>> help(os.mkdir)
mkdir(...)
    mkdir(path [, mode=0777])
    
    Create a directory.

>>> os.mkdir("/tmp/1", mode=777) 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: mkdir() takes no keyword arguments


Suggest the following doc comment change:

mkdir(...)
    mkdir(path [, mode])
    
    Create a directory. Mode defaults to 0777 if not specified.

----------
assignee: georg.brandl
components: Documentation
messages: 102648
nosy: georg.brandl, twhitema
severity: normal
status: open
title: os.mkdir doc comment is incorrect
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Fri Apr  9 00:08:04 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 08 Apr 2010 22:08:04 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1270764484.93.0.725864284322.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16710/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Apr  9 00:08:34 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 08 Apr 2010 22:08:34 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1270764514.21.0.334120697063.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Uploaded an update.

----------
Added file: http://bugs.python.org/file16830/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Apr  9 00:57:31 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 08 Apr 2010 22:57:31 +0000
Subject: [issue6650] sre_parse contains a confusing generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1270767451.43.0.383881091359.issue6650@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Thanks for the patch, LGTM assuming we don't need a test for this.

Do you think the vague message could be less cryptic for users that didn't want lookbehind (or don't know what it is)?

----------
nosy: +ajaksu2
priority:  -> low
stage:  -> patch review
versions:  -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________

From report at bugs.python.org  Fri Apr  9 00:59:19 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 08 Apr 2010 22:59:19 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1270767559.12.0.747892936413.issue6700@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed in trunk and py3k. Also affects inspect.getsourcelines.

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Apr  9 01:21:10 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 08 Apr 2010 23:21:10 +0000
Subject: [issue6878] outdated docstring in tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1270768870.03.0.599029833163.issue6878@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I think the obvious code fix of list(map()) is less likely to cause surprises than updating the docstring to the new map in 3.x.

----------
keywords: +easy
nosy: +ajaksu2
priority:  -> low
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Fri Apr  9 01:36:44 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Thu, 08 Apr 2010 23:36:44 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

This patch adds the ability to suppress large diffs in the failure message of TestCase.assertSequenceEqual().  The maximum size of the diff is customisable as an new keyword parameter with hopefully a sensible default.

----------
components: Library (Lib)
files: case_seq.diff
keywords: patch
messages: 102653
nosy: flub
severity: normal
status: open
title: Suppress large diffs in unitttest.TestCase.assertSequenceEqual()
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file16831/case_seq.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8351>
_______________________________________

From report at bugs.python.org  Fri Apr  9 01:55:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 08 Apr 2010 23:55:21 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1270770921.9.0.817774459928.issue3984@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Fri Apr  9 01:57:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 08 Apr 2010 23:57:20 +0000
Subject: [issue4843] make distutils use shutil
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1270771040.97.0.682057691781.issue4843@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Fri Apr  9 01:57:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 08 Apr 2010 23:57:32 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1270771052.74.0.464832973388.issue8351@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8351>
_______________________________________

From report at bugs.python.org  Fri Apr  9 01:59:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 08 Apr 2010 23:59:26 +0000
Subject: [issue5187] distutils upload should prompt for the user/password too
In-Reply-To: <1234128468.86.0.0554273106388.issue5187@psf.upfronthosting.co.za>
Message-ID: <1270771166.08.0.964875273602.issue5187@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5187>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:00:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:00:14 +0000
Subject: [issue1004696] translate Windows cr-lf when installing scripts on
	Linux
Message-ID: <1270771214.71.0.862772880291.issue1004696@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1004696>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:01:56 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 00:01:56 +0000
Subject: [issue7007] Tiny inconsistency in the orthography of "url encoded" in
	the doc of urllib.parse
In-Reply-To: <1254071339.25.0.500752949705.issue7007@psf.upfronthosting.co.za>
Message-ID: <1270771316.66.0.202575525149.issue7007@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Hits from py3k:

Doc/library/urllib.rst:239:   Convert a mapping object or a sequence of two-element tuples  to a "url-encoded"

Doc/library/urllib.rst:263:   Convert the path component *path* from an encoded URL to the local syntax for a

Doc/library/urlparse.rst:112:   values in URL encoded queries should be treated as blank strings.   A true value

Doc/library/urlparse.rst:135:   values in URL encoded queries should be treated as blank strings.   A true value

Doc/library/logging.rst:2347:      Sends the record to the Web server as an URL-encoded dictionary.

Lib/logging/handlers.py:1021:        Send the record to the Web server as an URL-encoded dictionary

Lib/cgi.py:135:            URL encoded forms should be treated as blank strings.

Lib/cgi.py:414:            URL encoded forms should be treated as blank strings.

Lib/urlparse.py:297:        qs: URL-encoded query string to be parsed

Lib/urlparse.py:300:            URL encoded queries should be treated as blank strings.

Lib/urlparse.py:323:    qs: URL-encoded query string to be parsed

Lib/urlparse.py:326:        URL encoded queries should be treated as blank strings.  A

----------
assignee:  -> georg.brandl
components: +Documentation
keywords: +easy
nosy: +ajaksu2, georg.brandl
priority:  -> low
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7007>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:03:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:03:36 +0000
Subject: [issue1109659] distutils argument parsing is bogus
Message-ID: <1270771416.35.0.837050585604.issue1109659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?Global option? could be understood as ?option that can be given to any command?, i.e. ?egg spam -d? == ?egg -d spam?. Is it feasible to support such and equivalence, too difficult or not desirable?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109659>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:04:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:04:34 +0000
Subject: [issue7677] distutils,
	better error message for setup.py upload -sign without identity.
In-Reply-To: <1263223354.89.0.290474495181.issue7677@psf.upfronthosting.co.za>
Message-ID: <1270771474.15.0.395509262034.issue7677@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7677>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:08:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:08:29 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1270771709.09.0.622375348781.issue6142@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

So, is this bug ?add a distclean command? now?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6142>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:16:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:16:40 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1270772200.52.0.677897920966.issue4908@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:18:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:18:16 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1270772296.19.0.575957341062.issue6860@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:21:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:21:53 +0000
Subject: [issue793069] Add --remove-source option
Message-ID: <1270772513.58.0.406405381818.issue793069@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue793069>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:22:16 2010
From: report at bugs.python.org (James)
Date: Fri, 09 Apr 2010 00:22:16 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1270772536.31.0.233138727002.issue6142@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

i'm fine with that and willing to contribute patches, however i would feel better if whoever upstream was, was more supportive of the idea.
someone let me know.

a thought:
- it's true (as mentioned) that distclean isn't necessarily directly related to distributing python scripts, however (in my mind anyways) i see distutils as a replacement for common things we do in makefiles. so as a result if we did this we could get rid of makefiles and provide useful "action" targets such as distclean, test, etc... 100% pure python if needed...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6142>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:23:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:23:48 +0000
Subject: [issue6555] distutils config file should have the same name on both
	platforms and all scopes
In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
Message-ID: <1270772628.96.0.809663140052.issue6555@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6555>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:24:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:24:23 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1270772663.56.0.49734381973.issue6087@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:26:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:26:52 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1270772812.9.0.828896371457.issue3992@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:27:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 00:27:17 +0000
Subject: [issue5747] knowing the parent command
In-Reply-To: <1239635801.31.0.779200404785.issue5747@psf.upfronthosting.co.za>
Message-ID: <1270772837.73.0.240487898384.issue5747@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5747>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:27:49 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 00:27:49 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270772869.4.0.460579766317.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

With patch 29, I believe all patch-related test failures are corrected.

The remaining failures in some modules (namely test_tarfile, test_glob, test_mailbox, test_warnings) can be demonstrated to occur in unpatched builds. Since some failures are transient, I created repeat_test, which I used to demonstrate that test_glob, test_tarfile, and test_mailbox will fail on a clean build.

Additionally, I'm including test output for 32- and 64-bit builds on the unpatched build, the patched build running under administrator, and the patched build running under guest.

The test output was generated in an automated fashion to guarantee a clean build. The build process can be found by easy_installing jaraco.develop==1.1.1 and running test-python-symlink-patch.py (VS9, GNU patch, and svn required).

----------
Added file: http://bugs.python.org/file16832/repeat_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:28:07 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 00:28:07 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270772887.15.0.00781744101993.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file16833/admin results - no patch.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:28:17 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 00:28:17 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270772897.94.0.0116575101158.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file16834/admin results - patch 29.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:28:28 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 00:28:28 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270772908.36.0.475270640164.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file16835/guest results - patch 29.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:28:36 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 00:28:36 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270772916.13.0.984413465642.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16202/guest results.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:28:41 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 00:28:41 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270772921.26.0.250535392536.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16203/admin results.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:44:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 00:44:45 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270773885.21.0.866280491207.issue7978@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I think the wrapper approach is a good one. Now remains to decide whether it should stay private to socketserver or be exposed as a generic method (for example in the "os" module as proposed).

By the way, adding a patch would be nice, too. I'm not sure it what form it should be done; perhaps register a signal handler and trigger the signal from a sub-thread while the main thread is iterating in a select loop?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:44:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 00:44:52 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270773892.66.0.566379145626.issue7978@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I think the wrapper approach is a good one. Now remains to decide whether it should stay private to socketserver or be exposed as a generic method (for example in the "os" module as proposed).

By the way, adding a test would be nice, too. I'm not sure it what form it should be done; perhaps register a signal handler and trigger the signal from a sub-thread while the main thread is iterating in a select loop?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:44:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 00:44:58 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270773898.64.0.820862711192.issue7978@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Fri Apr  9 02:52:53 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 00:52:53 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1270774373.34.0.172334009991.issue7163@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

sys.stdout is a idlelib.rpc.RPCProxy in IDLE. It calls Idlelib.PyShell.PseudoFile.write ->
.PyShell.write -> 
.OutputWindow.OutputWindow.write ->
.Percolator.Percolator.insert ->
...

I suppose we could mimic the return value patching PseudoFile.write (for educational purposes?).

----------
nosy: +ajaksu2
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:11:38 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 09 Apr 2010 01:11:38 +0000
Subject: [issue8352] imp.find_module of a .py ending dir causes glibc double
	free crash
In-Reply-To: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>
Message-ID: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

[forwarded from http://bugs.debian.org/577005]

seen with 2.5.5, 2.6.5 and 2.7alpha4:

The imp.find_module function causes a glibc double free or corruption if
it would be invoked with a directory with a ".py" ending. It can be
reproduced with:

mkdir bla.py; python -c 'import imp; imp.find_module("bla", ["."])'

This causes bpython to crash after the first input char if such a
directory exist.


stacktrace with 2.6.5:
(gdb) bt
#0  0x00355906 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00358e05 in *__GI_abort () at abort.c:88
#2  0x0038c78d in __libc_message (do_abort=2, fmt=0x453088 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:173
#3  0x00396905 in malloc_printerr (action=2, str=0x453230 "double free or corruption (!prev)", ptr=
    0x83004e0) at malloc.c:6239
#4  0x003981a3 in _int_free (av=0x46f3c0, p=0x83004d8) at malloc.c:4772
#5  0x0039b22d in *__GI___libc_free (mem=0x83004e0) at malloc.c:3738
#6  0x00386b55 in _IO_new_fclose (fp=0x83004e0) at iofclose.c:88
#7  0x08116efc in call_find_module (name=0xb7f52a54 "bla", path=['.']) at ../Python/import.c:2844
#8  0x08117011 in imp_find_module (self=<unknown at remote 0x0>, args=('bla', ['.']))
    at ../Python/import.c:2865
#9  0x081b1755 in PyCFunction_Call (func=<builtin_function_or_method at remote 0xb7f3cc3c>, arg=
    ('bla', ['.']), kw=<unknown at remote 0x0>) at ../Objects/methodobject.c:81
#10 0x080fbf03 in call_function (pp_stack=0xbffff3cc, oparg=2) at ../Python/ceval.c:3750
#11 0x080f75ac in PyEval_EvalFrameEx (f=File <string>, line 1, in <module> (), throwflag=0)
    at ../Python/ceval.c:2412
#12 0x080f9c48 in PyEval_EvalCodeEx (co=0xb7fe6da8, globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, closure=<unknown at remote 0x0>) at ../Python/ceval.c:3000
#13 0x080efd6b in PyEval_EvalCode (co=0xb7fe6da8, globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}) at ../Python/ceval.c:541
#14 0x0812376c in run_mod (mod=0x83565c0, filename=0x81ef6b1 "<string>", globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, flags=0xbffff6c0, arena=0x82f5700)
    at ../Python/pythonrun.c:1339
#15 0x08123640 in PyRun_StringFlags (str=0x82e5008 "import imp; imp.find_module(\"bla\", [\".\"])\n", 
    start=257, globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, flags=0xbffff6c0) at ../Python/pythonrun.c:1302
#16 0x081223e9 in PyRun_SimpleStringFlags (command=
    0x82e5008 "import imp; imp.find_module(\"bla\", [\".\"])\n", flags=0xbffff6c0)
    at ../Python/pythonrun.c:961
#17 0x0805e3f6 in Py_Main (argc=3, argv=0xbffff7b4) at ../Modules/main.c:521
#18 0x0805d51f in main (argc=3, argv=0xbffff7b4) at ../Modules/python.c:23

----------
components: Interpreter Core
messages: 102662
nosy: doko
severity: normal
status: open
title: imp.find_module of a .py ending dir causes glibc double free crash
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8352>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:12:42 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 01:12:42 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270775562.98.0.658739060155.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

It seems issue7443 discusses the cause of the transient failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:13:20 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 01:13:20 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1270775600.68.0.287054478256.issue7443@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:22:54 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 01:22:54 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1270776174.48.0.797549506522.issue7370@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Thanks for the patch. Per issue 2849, use of rfc822 should be gone from the stdlib. Please re-open if you disagree.

----------
nosy: +ajaksu2
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:28:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 01:28:05 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1270776485.94.0.866797405936.issue7370@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Following the last link on #2859, I?ve found that ?rfc822.formatdate(time)? can be changed to ?email.utils.formatdate(time, usegmt=True)?.

I?ll make a real diff in a few days if noone beats me to it.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:37:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 01:37:49 +0000
Subject: [issue1649329] gettext.py incompatible with eggs
Message-ID: <1270777069.41.0.804904229918.issue1649329@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:39:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 01:39:23 +0000
Subject: [issue5411] add xz compression support to distutils
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1270777163.23.0.612089195097.issue5411@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:39:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 01:39:43 +0000
Subject: [issue3985] removed string module from distutils [patch]
In-Reply-To: <1222597888.29.0.260615260643.issue3985@psf.upfronthosting.co.za>
Message-ID: <1270777183.06.0.0173670586599.issue3985@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3985>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:40:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 01:40:49 +0000
Subject: [issue4151] Separate build dir broken
In-Reply-To: <1224522256.17.0.820973690454.issue4151@psf.upfronthosting.co.za>
Message-ID: <1270777249.58.0.69877419652.issue4151@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4151>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:44:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 01:44:19 +0000
Subject: [issue976869] Stripping script extensions with distutils
Message-ID: <1270777459.51.0.553524002789.issue976869@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue976869>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:44:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 01:44:30 +0000
Subject: [issue870479] Scripts need platform-dependent handling
Message-ID: <1270777470.74.0.838311344646.issue870479@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue870479>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:49:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Apr 2010 01:49:04 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1270777744.39.0.596821423437.issue7370@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The issue is not invalid. The code duplication should be removed, but using the email module as ?ric suggests.  Reopening.

----------
nosy: +r.david.murray
resolution: invalid -> 
stage: committed/rejected -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:49:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Apr 2010 01:49:23 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1270777763.35.0.0800391819823.issue7370@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:49:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Apr 2010 01:49:58 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1270777798.23.0.77864208894.issue7370@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: patch: BaseHTTPServer reinventing rfc822 -> patch: BaseHTTPServer reinventing rfc822 date formatting

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Fri Apr  9 03:53:46 2010
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Fri, 09 Apr 2010 01:53:46 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1270778026.43.0.929569734308.issue7897@psf.upfronthosting.co.za>


Yaroslav Halchenko <yarikoptic at gmail.com> added the comment:

In PyMVPA we have our little decorator as an alternative to Fernando's generators,  and which is closer, I think, to what Michael was wishing for:
@sweepargs

http://github.com/yarikoptic/PyMVPA/blob/master/mvpa/testing/sweepargs.py

NB it has some minor PyMVPA specificity which could be easily wiped out, and since it was at most 4 eyes looking at it and it bears "evolutionary" changes, it is far from being the cleanest/best piece of code, BUT:

* it is very easy to use, just decorate a test method/function and give an argument which to vary within the function call, e.g smth like

@sweepargs(arg=range(5))
def test_sweepargs_demo(arg):
    ok_(arg < 5)
    ok_(arg < 3)
    ok_(arg < 2)

For nose/unittest it would still look like a single test

* if failures occur, sweepargs groups failures by the type/location of the failures and spits out a backtrace for one of failures + summary (instead of detailed backtraces for each failure) specifying which arguments lead to what error... here is the output for example above:

$> nosetests -s test_sweepargs_demo.py
F
======================================================================
FAIL: mvpa.tests.test_sweepargs_demo.test_sweepargs_demo
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.5/nose/case.py", line 183, in runTest
    self.test(*self.arg)
  File "/usr/lib/pymodules/python2.5/nose/util.py", line 630, in newfunc
    return func(*arg, **kw)
  File "/home/yoh/proj/pymvpa/pymvpa/mvpa/tests/test_sweepargs_demo.py", line 11, in test_sweepargs_demo
    ok_(arg < 2)
  File "/usr/lib/pymodules/python2.5/nose/tools.py", line 25, in ok_
    assert expr, msg
AssertionError: 
 Different scenarios lead to failures of unittest test_sweepargs_demo (specific tracebacks are below):
  File "/home/yoh/proj/pymvpa/pymvpa/mvpa/tests/test_sweepargs_demo.py", line 10, in test_sweepargs_demo
    ok_(arg < 3)
    File "/usr/lib/pymodules/python2.5/nose/tools.py", line 25, in ok_
    assert expr, msg
  on
    arg=3 
    arg=4 

  File "/home/yoh/proj/pymvpa/pymvpa/mvpa/tests/test_sweepargs_demo.py", line 11, in test_sweepargs_demo
    ok_(arg < 2)
    File "/usr/lib/pymodules/python2.5/nose/tools.py", line 25, in ok_
    assert expr, msg
  on
    arg=2 

----------------------------------------------------------------------
Ran 1 test in 0.003s

FAILED (failures=1)

* obviousely multiple decorators could be attached to the same test, to test on all combinations of more than 1 argument but output atm is a bit cryptic ;-)

----------
nosy: +Yaroslav.Halchenko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Apr  9 04:00:06 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 02:00:06 +0000
Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face
	of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1270778406.3.0.0351758332869.issue7425@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Nice improvement. This would also solve the "help(), modules" brokenness, right?

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Fri Apr  9 04:01:11 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 02:01:11 +0000
Subject: [issue7378] unexpected truncation of traceback
In-Reply-To: <1258970662.35.0.76558630095.issue7378@psf.upfronthosting.co.za>
Message-ID: <1270778471.4.0.89309213184.issue7378@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Patch still applies to py3k, not applying cleanly to trunk anymore. Tests pass with patch on py3k.

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7378>
_______________________________________

From report at bugs.python.org  Fri Apr  9 04:25:37 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Apr 2010 02:25:37 +0000
Subject: [issue8156] pybsddb 4.8.4 integration
In-Reply-To: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>
Message-ID: <1270779937.39.0.386791358135.issue8156@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8156>
_______________________________________

From report at bugs.python.org  Fri Apr  9 04:43:21 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 02:43:21 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1270781001.55.0.151956637367.issue7584@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

It looks like feed generators need this feature[1]. See also issue 5207 and a current implementation[2].

[1] http://validator.w3.org/feed/docs/error/InvalidRFC3339Date.html
[2] http://code.google.com/p/formattime/

----------
keywords: +easy
nosy: +ajaksu2
priority:  -> normal
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Fri Apr  9 04:48:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 02:48:15 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1270781295.01.0.27762666651.issue7584@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note that the Atom format requires a subset of RFC 3339 (which is in turn a subset of ISO 8601 if I remember correctly, and is the same as the W3C Datetime Format): https://www.tools.ietf.org/html/rfc4287#section-3.3

Summary: Atom requires using an uppercase T between date and time (the RFC permits lower and upper case), and using an uppercase Z for UTC timezone, not ?-00:00?.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Fri Apr  9 04:50:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 02:50:12 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1270781412.42.0.854151111222.issue7584@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Should have checked before speaking. RFC?3339 is a subset of W3CDTF, as said on Daniel?s first link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Fri Apr  9 04:51:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 02:51:16 +0000
Subject: [issue5207] extend strftime/strptime format for RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1270781476.15.0.980267888125.issue5207@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________

From report at bugs.python.org  Fri Apr  9 05:13:49 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 03:13:49 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1270782829.38.0.276435369008.issue7865@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Wouldn't this break code that currently works?

----------
nosy: +ajaksu2
priority:  -> low
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Fri Apr  9 05:15:54 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 03:15:54 +0000
Subject: [issue7842] py_compile.compile SyntaxError output
In-Reply-To: <1265151004.56.0.531784942224.issue7842@psf.upfronthosting.co.za>
Message-ID: <1270782954.61.0.892889811525.issue7842@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Change went into py3k without tests, do we want them? If so, please update Stage to "test needed".

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7842>
_______________________________________

From report at bugs.python.org  Fri Apr  9 05:36:19 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 03:36:19 +0000
Subject: [issue7943] Memory leak due to circular references in ssl.SSLSocket
In-Reply-To: <1266341912.31.0.218071173939.issue7943@psf.upfronthosting.co.za>
Message-ID: <1270784179.04.0.134332485377.issue7943@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7943>
_______________________________________

From report at bugs.python.org  Fri Apr  9 05:45:13 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 03:45:13 +0000
Subject: [issue7927] SSL socket is not closed properly
In-Reply-To: <1266146726.16.0.222413736354.issue7927@psf.upfronthosting.co.za>
Message-ID: <1270784713.21.0.904288167686.issue7927@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed on trunk.

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7927>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:07:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 04:07:40 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1270786060.94.0.0267836527597.issue7132@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:09:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 04:09:30 +0000
Subject: [issue5207] extend strftime/strptime format for RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1270786170.67.0.272561407873.issue5207@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:10:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 04:10:23 +0000
Subject: [issue7378] unexpected truncation of traceback
In-Reply-To: <1258970662.35.0.76558630095.issue7378@psf.upfronthosting.co.za>
Message-ID: <1270786223.91.0.224242390291.issue7378@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7378>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:12:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 04:12:13 +0000
Subject: [issue8352] imp.find_module of a .py ending dir causes glibc double
	free crash
In-Reply-To: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>
Message-ID: <1270786333.08.0.757607935924.issue8352@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +brett.cannon, ncoghlan
priority:  -> high
stage:  -> test needed
type:  -> crash
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8352>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:16:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 04:16:50 +0000
Subject: [issue3985] removed string module from distutils [patch]
In-Reply-To: <1222597888.29.0.260615260643.issue3985@psf.upfronthosting.co.za>
Message-ID: <1270786610.44.0.242213939667.issue3985@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Patch looks good.
There's only a missing space before the for in:
+                self.metadata.platforms = [kw.strip() 
+                                          for kw in platformlist.split(',')]

----------
nosy: +ezio.melotti
resolution:  -> accepted
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3985>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:18:56 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 04:18:56 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1270786736.97.0.147495961807.issue8351@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8351>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:19:24 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 04:19:24 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1270786764.01.0.393081015154.issue4007@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Skip, was there a patch here? I can't find it in the bug lists, so I think we both missed it?

Pinging Martin in case the tracker ate the patch :)

----------
nosy: +ajaksu2, loewis
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:49:53 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Apr 2010 04:49:53 +0000
Subject: [issue8026] strftime bug when timedelta is negative
In-Reply-To: <1267206102.75.0.187323607292.issue8026@psf.upfronthosting.co.za>
Message-ID: <1270788593.99.0.313702226522.issue8026@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Confirmed on trunk, needs a simpler repro :)

----------
components: +Library (Lib) -None
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8026>
_______________________________________

From report at bugs.python.org  Fri Apr  9 06:55:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 04:55:33 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1270788933.19.0.747951110611.issue8351@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8351>
_______________________________________

From report at bugs.python.org  Fri Apr  9 07:46:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 09 Apr 2010 05:46:12 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1270791972.75.0.250402145498.issue4007@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If it did eat the patch, we would have lost it by now: there is nothing in the history that shows that a file was attached at some point. More likely, Skip forgot to attach it when submitting this report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Fri Apr  9 07:57:16 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Fri, 09 Apr 2010 05:57:16 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270792636.08.0.543052944303.issue7978@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

I vote for making a global wrapper. As neologix pointed - many other modules can be (or are) affected. Futher found bugs could be fixed using that global wrapper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Fri Apr  9 07:57:25 2010
From: report at bugs.python.org (Chris Ward)
Date: Fri, 09 Apr 2010 05:57:25 +0000
Subject: [issue8353] Negative exponentiation behaving oddly in python shell
In-Reply-To: <1270792645.79.0.439452519354.issue8353@psf.upfronthosting.co.za>
Message-ID: <1270792645.79.0.439452519354.issue8353@psf.upfronthosting.co.za>


New submission from Chris Ward <cwardusc at gmail.com>:

When using exponentiation interactively in the python shell, it returns all negative results when a negative number is the input. For example:

-4 ** 2 will return -16
-4 ** 2 should evaluate as -4 * -4, which correctly returns 16

This does not occur when using the 'Run Module' feature of IDLE and the exponentiation is processed from the module, it only seems to occur when directly typed into the interactive prompt. I couldn't find anything to suggest this is expected behavior. Using pow() from the prompt returns the correct result, so it only happens in this one situation. Obviously this is low priority since it only affects the prompt and there's a working alternative, but I figured I'd report it anyways. :)

----------
components: IDLE
messages: 102681
nosy: CWardUSC
severity: normal
status: open
title: Negative exponentiation behaving oddly in python shell
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8353>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:16:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 09 Apr 2010 06:16:04 +0000
Subject: [issue8353] Negative exponentiation behaving oddly in python shell
In-Reply-To: <1270792645.79.0.439452519354.issue8353@psf.upfronthosting.co.za>
Message-ID: <1270793764.36.0.984480056116.issue8353@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is expected behavior. The power operator binds with higher precedence than the unary minus:

http://docs.python.org/reference/expressions.html#unary-arithmetic-and-bitwise-operations

Therefore, your term is interpreted as

-(4 ** 2)

As for "it only affects the prompt": I can't reproduce that. If I put

print(-4**2)

in a script and run that, it still prints -16 for me.

----------
nosy: +loewis
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8353>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:21:20 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 09 Apr 2010 06:21:20 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1270794080.85.0.84353756568.issue8350@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Tested on trunk. 

11:46:02 l0nwlf-MBP:python-svn $ ./python.exe 
Python 2.7a4+ (trunk:79888M, Apr  9 2010, 11:41:22) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> posix.mkdir('1')
>>> posix.mkdir('2', 000)
>>> posix.mkdir('3', mode=000)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: mkdir() takes no keyword arguments
>>> import os
>>> os.mkdir('4', 777)
>>> os.mkdir('5', mode=777)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: mkdir() takes no keyword arguments
>>> 

The two options to fix this are:
1. Patch python-svn/Modules/posixmodule.c to take the keyword arguments.
2. Modify the PyDoc in posixmodule.c as Todd suggested.

I had attached a patch which solves the issue using solution '2'. 

Also I observed that os.makedirs() have no such issue even though it uses os.mkdir() because it uses 'mkdir(name, mode)' to call mkdir.

----------
keywords: +patch
nosy: +l0nwlf
versions: +Python 2.7
Added file: http://bugs.python.org/file16836/posixmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:38:58 2010
From: report at bugs.python.org (Chris Ward)
Date: Fri, 09 Apr 2010 06:38:58 +0000
Subject: [issue8353] Negative exponentiation behaving oddly in python shell
In-Reply-To: <1270792645.79.0.439452519354.issue8353@psf.upfronthosting.co.za>
Message-ID: <1270795138.5.0.491667471389.issue8353@psf.upfronthosting.co.za>


Chris Ward <cwardusc at gmail.com> added the comment:

Thanks for clearing that up and pointing me in the right direction. I should have tested print first. The assumption was based on the evaluation of (-4) ** 2 within an expression, which does return correctly. I hadn't made the distinction that the parentheses made it evaluate differently by containing the unary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8353>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:40:59 2010
From: report at bugs.python.org (Tim Golden)
Date: Fri, 09 Apr 2010 06:40:59 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1270795259.05.0.144570638769.issue7443@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

This is basically a rerun of this discussion a couple of years ago:

  http://mail.python.org/pipermail/python-dev/2008-April/078333.html

The problem certainly still happens against trunk -- I have a semi-aggressive test-harness which can cause it to reproduce pretty much on-demand. I proposed an approach here:

  http://mail.python.org/pipermail/python-dev/2008-April/078339.html

but when I started digging into test_support it all got a bit hairy because -- naturally -- test.support.unlink is used in a *lot* of places. In short, there's still a problem to be fixed. I believe that a rename-unlink dance would solve it, but only at the cost of affecting a lot of tests.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:46:46 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 09 Apr 2010 06:46:46 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1270795606.36.0.775059123845.issue4007@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

skip.montanaro forgot to attached the patch obviously, however the issue is trivial but there i.e. the presence of libpython.a file.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:50:32 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 09 Apr 2010 06:50:32 +0000
Subject: [issue8352] imp.find_module of a .py ending dir causes glibc double
	free crash
In-Reply-To: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>
Message-ID: <1270795832.67.0.0345922829225.issue8352@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

<quote>mkdir bla.py; python -c 'import imp; imp.find_module("bla", ["."])'

This causes bpython to crash after the first input char if such a
directory exist.</quote>

I am sure you do not mean 'bpython intepretor' here.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8352>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:50:37 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Fri, 09 Apr 2010 06:50:37 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>


New submission from Andrew Bennetts <spiv at users.sourceforge.net>:

The effect of signal.siginterrupt(somesig, False) is reset the first time a that signal is received.  This is not the documented behaviour, and I do not think this is a desireable behaviour.  It renders siginterrupt effectively useless at providing the robustness against EINTR it is intended to provide.

Attached is a fairly simple program to show this using SIGWINCH: run it in a resizeable terminal, and resize it twice.  Notice that on the second terminal resize (i.e. the second SIGWINCH signal) the program crashes with an EINTR from the os.read.

A partial workaround for the problem is to call signal.siginterrupt(somesig, False) again inside your signal handler, but it's very fragile.  It depends on Python getting a chance to run the Python function registered by the signal.signal call, but this is not guaranteed.  If there's frequent IO, that workaround might suffice.  For the sig-test.py example attached to this bug, it doesn't (try it).

The cause seems to be that signal_handler in signalmodule.c unconditionally does PyOS_setsig(sig_num, signal_handler) [except for SIGCHLD], which unconditionally invokes siginterrupt(sig, 1).  A possible fix would be to add a 'int siginterrupt_flag;' to the Handlers array, and arrange for that value to be passed instead of the hard-coded 1.  Another might be to not call PyOS_setsig from signal_handler at all -- I'm not sure why it is trying to reinstall itself, but perhaps there's some issue there I'm not aware of.

----------
components: Library (Lib)
files: sig-test.py
messages: 102688
nosy: spiv
severity: normal
status: open
title: siginterrupt with flag=False is reset when signal received
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16837/sig-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Fri Apr  9 08:54:13 2010
From: report at bugs.python.org (Darryl Miles)
Date: Fri, 09 Apr 2010 06:54:13 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270796053.85.0.939298077881.issue8108@psf.upfronthosting.co.za>


Darryl Miles <darryl.miles at darrylmiles.org> added the comment:

In order to build Python with a specific version of OpenSSL followed the CYGWIN instructions and edited Modules/Setup to make it read (note - I added "-L$(SSL)" into the linker options too, since by default on CentOS 5.4 i386 OpenSSL build in static library mode ala ../openssl-1.0.0/libssl.a) :

SSL=../openssl-1.0.0
_ssl _ssl.c \
        -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
        -L$(SSL)/lib -L$(SSL) -lssl -lcrypto


It is not clear to me what Python's goals are:
 * To be backward compatible, in which case I don't know your historical use of SSL_shutdown().
 * To be a thin-layer (1:1) over OpenSSL, so that "power users" can harness the full potential of OpenSSL if they are willing to understand the finer points.
 * To provide a full-featured Python API.
 * To provide a Python API that is easy to use within the Python paradigm.

These goals may not be convergent.

----------
nosy: +dlmiles
Added file: http://bugs.python.org/file16838/python_ssl.c.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:01:07 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Fri, 09 Apr 2010 07:01:07 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270796467.95.0.917907967609.issue7978@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Note that a trivial untilConcludes isn't correct for select if a timeout was passed.  If a select(..., 60) was interrupted after 59 seconds, you probably want to restart it with a timeout of 1 second, not 60.

The SocketServer_eintr.diff patch has this flaw.

----------
nosy: +spiv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:15:58 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 09 Apr 2010 07:15:58 +0000
Subject: [issue8352] imp.find_module of a .py ending dir causes glibc double
	free crash
In-Reply-To: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>
Message-ID: <1270797358.79.0.379743886148.issue8352@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

No, that is not bpython interpreter. The a crash report on "python interpreter" observed with imp module when a directory ends with .py.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8352>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:36:50 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 07:36:50 +0000
Subject: [issue3985] removed string module from distutils [patch]
In-Reply-To: <1222597888.29.0.260615260643.issue3985@psf.upfronthosting.co.za>
Message-ID: <1270798610.04.0.17513048105.issue3985@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Distutils is now frozen. Moving it to Distutils2

----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3985>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:44:48 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 07:44:48 +0000
Subject: [issue5411] add xz compression support to distutils
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1270799088.66.0.178290442318.issue5411@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:45:26 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 07:45:26 +0000
Subject: [issue870479] Scripts need platform-dependent handling
Message-ID: <1270799126.82.0.654121952771.issue870479@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue870479>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:46:06 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 07:46:06 +0000
Subject: [issue976869] Stripping script extensions with distutils
Message-ID: <1270799166.18.0.586958029249.issue976869@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue976869>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:57:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 09 Apr 2010 07:57:27 +0000
Subject: [issue8352] imp.find_module of a .py ending dir causes glibc double
	free crash
In-Reply-To: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>
Message-ID: <1270799847.52.0.776819219234.issue8352@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It looks like a duplicate of #7732.

----------
nosy: +flox
resolution:  -> duplicate
status: open -> closed
superseder:  -> imp.find_module crashes Python if there exists a directory named "__init__.py"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8352>
_______________________________________

From report at bugs.python.org  Fri Apr  9 09:59:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 09 Apr 2010 07:59:58 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1270799998.11.0.0262520900298.issue7732@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

see also http://bugs.python.org/issue8352#msg102662

----------
nosy: +doko, l0nwlf, ncoghlan, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:06:02 2010
From: report at bugs.python.org (Nicolas Dumazet)
Date: Fri, 09 Apr 2010 08:06:02 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1270800362.78.0.762614839919.issue6715@psf.upfronthosting.co.za>


Changes by Nicolas Dumazet <nicdumz at gmail.com>:


----------
nosy: +nicdumz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:09:42 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 09 Apr 2010 08:09:42 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1270800582.6.0.925622560082.issue7732@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I can reproduce this locally. I believe it is relevant that a simple "import crash" (with crash.py as the directory) doesn't cause a problem - there must be something higher in the import machinery which avoids the issue.

----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:11:35 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 08:11:35 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1270800695.72.0.626647694584.issue7443@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is unlikely that it will go further then discussion unless this bug can be reliably reproduced to be debugged. If not testcase when at least Process Monitor log would be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:16:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 08:16:00 +0000
Subject: [issue4908] Implement PEP 376
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1270800960.99.0.410317911433.issue4908@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Work done in pkgutil, in the Distutils2 project, see PEP 376 for API names.

----------
components: +Distutils2 -Distutils
title: adding a get_metadata in distutils -> Implement PEP 376

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:34:49 2010
From: report at bugs.python.org (Tim Golden)
Date: Fri, 09 Apr 2010 08:34:49 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1270800695.72.0.626647694584.issue7443@psf.upfronthosting.co.za>
Message-ID: <4BBEE6A3.9070001@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

In one window run the attached script (assumes you have pywin32 installed) with a parameter of the directory the TESTFN file will end up in. Then run, eg, test_zipfile in another window. For me:

c:\temp> watch_dir.py C:\work_in_progress\make-snapshots\trunk\python\Lib

C:\work_in_progress\make-snapshots\trunk\python\Lib> ..\pcbuild\python.exe -m test.test_zipfile

Obviously, you'd have to change the path to be wherever you're running the test suite from.

The watch_dir script sits there looking for file activity, then takes and releases a delete-share handle on the file. It's enough to disrupt certain tests (such as test_zipfile) pretty much every time. Other tests are affected less, or only the first few times. Not sure why, but it's certainly enough to reproduce the general effect of TortoiseSVN or indexer or virus checker.

----------
Added file: http://bugs.python.org/file16839/watch_dir.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________
-------------- next part --------------
import os, sys

import winerror
import win32file
import win32con

if __name__ == '__main__':
  path_to_watch = sys.argv[1]
  hDir = win32file.CreateFile (
    path_to_watch,
    1, # FILE_LIST_DIRECTORY
    win32con.FILE_SHARE_READ | win32con.FILE_SHARE_WRITE,
    None,
    win32con.OPEN_EXISTING,
    win32con.FILE_FLAG_BACKUP_SEMANTICS,
    None
  )
  print "=> Watching", path_to_watch

  watching = set ()
  handles = []
  try:
    while 1:
      results = win32file.ReadDirectoryChangesW (
        hDir, 1024, True,
        win32con.FILE_NOTIFY_CHANGE_FILE_NAME,
        None, None
      )
      for action, filename in results:
        filename = os.path.join (path_to_watch, filename)
        if action == 1 and filename not in watching:
          try:
            handle = win32file.CreateFile (
              filename,
              0, win32file.FILE_SHARE_DELETE,
              None, win32file.OPEN_EXISTING, 0, 0
            )
            handles.append (handle)
          except win32file.error, (errno, module, message):
            if errno == winerror.ERROR_SHARING_VIOLATION:
              print ".. Can't hold", repr (filename)
            else:
              print ".. Problem with %r: %s" % (filename, message)
          else:
            watching.add (filename)
            print ".. Holding", repr (filename)
            handle.Close ()
            handles.remove (handle)
            watching.discard (filename)
            print ".. Released", repr (filename)

  finally:
    for handle in handles:
      handle.Close ()

  hDir.Close ()

From report at bugs.python.org  Fri Apr  9 10:36:19 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 09 Apr 2010 08:36:19 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1270802179.95.0.442450527752.issue7732@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, OK - the problem is confined solely to the wrapper for the Python imp module function. The normal import machinery doesn't go through the wrapper and hence doesn't have the problem.

The PyFile_FromFile logic is a little convoluted, but Florent's patch looks correct. Currently, if the dircheck call in fill_file_fields fails, the function returns NULL, but leaves the file object populated (included its f_fp field). The Py_DECREF call then implicitly closes the file, resulting in a double close when call_find_module does the same thing manually.

One other thing that is a little dubious in this code is the lack of error checking on the conversion of mode to a string object in fill_file_fields. That's fine for file_init (where mode came from a Python string object in the first place), but not valid for PyFile_FromFile (where mode is passed in as a char * instance).

----------
assignee: ncoghlan -> flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:47:21 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 08:47:21 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1270802841.47.0.724139867237.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Atom spec - http://www.atomenabled.org/developers/syndication/atom-format-spec.php#date.constructs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:54:25 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 08:54:25 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Script/diff.py default context diff format is outdated. It makes sense to produce unified diff by default.

----------
components: Demos and Tools
messages: 102701
nosy: techtonik
severity: normal
status: open
title: diff.py produce unified format by default
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:55:31 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 09 Apr 2010 08:55:31 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1270803331.92.0.985671327492.issue7732@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

An interesting part of this story is *why* it doesn't crash in Py3k (despite explicitly closing the file descriptor in the same way as 2.x closes the C file pointer).

The reason is that PyFile_FromFd (the closest Py3k equivalent to PyFile_FromFile) will sometimes leave the file descriptor open, even if closefd is True. Specifically, this will happen if the raw file IO object fails to be created. Any subsequent failure while opening the file (e.g. while creating the line buffering or text wrapper) will trigger the same double close bug as occurs in 2.x.

io_open needs to be fixed so this behaviour is consistent: if creation of the raw file IO object fails and closefd is True, io_open should close the file descriptor so that the behaviour on error is consistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Fri Apr  9 10:59:15 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 09 Apr 2010 08:59:15 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1270803555.2.0.27385024472.issue6087@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Yes, I agree with you, this may be a bug? 

Seemingly, the sysconfig.get_python_lib() should act just like the get_python_inc() function, return "[prefix]/lib/python[version]" in case of "python_build" flag is False, and "[prefix]/Lib" in case of "python_build" flag is True.

----------
nosy: +ysj.ray
versions: +Python 3.2 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Fri Apr  9 11:00:06 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 09 Apr 2010 09:00:06 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1270803606.47.0.286775203911.issue6087@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
versions: +Python 2.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Fri Apr  9 11:00:28 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 09 Apr 2010 09:00:28 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1270803628.23.0.867144282008.issue6087@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
versions: +Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Fri Apr  9 11:16:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 09 Apr 2010 09:16:23 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1270804583.47.0.0959212385754.issue7732@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Fri Apr  9 11:21:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 09:21:30 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270804890.33.0.443064399172.issue8355@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16840/8355.diff-py-unified-by-default.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 11:24:33 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Fri, 09 Apr 2010 09:24:33 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1270805073.9.0.649869061952.issue7978@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

pitrou, re. test code: I actually started with the test code, so that part is done.

I opted to use a forked SocketServer rather than threads. I'm not an expert on the low-level details of a multi-threaded process receiving threads, but it seems to me like there's a chicken and egg issue here: suppose we have threadA (blocking on select()) and threadB (managing the test and doing something like os.kill(os.getpid(), SIGFOO). I think by definition the thread running when the signal is received is threadB (since it sent the signal), and I'm not sure threadA will be interrupted properly that way (threads are sneaky, now aren't they). So I cleaned up test_socketserver.py a bit, split it to a base test case and concrete test cases, and added a separate test case which uses os.fork() rather than threads and tests that way.

The attached patch is against recent py3k and includes both neologix's patch (adapted to py3k) and the added test code. If this looks good, I'll easily backport it to 2.x/trunk.

spiv, re. handling timeout in select: You're very right, and I'm not sure how we should handle it if we want to take the "untilConcludes" code that is currently shared between subprocess.py and socketserver.py and move it outside. For subprocess' and socketserver's specific cases, the naive implementation which doesn't handle timeouts is OK, because they don't use the timeout parameter anyway.

Moving it outside warrants more discussion. Remember this isn't just about select() - it's a general user-space-restarter for any of the myriad of "slow" system calls that might be interrupted. There is some tension between elegance and even feasibility of correct implementation vs. the wrapper hiding functionality of some of these system calls. You could argue that if the user of the wrapper is unhappy about the lost functionality, they can make their own wrapper. 

Unless we can reach a resolution quickly, my gut feeling is that the current patch should be applied as-is and this issue be closed. A new issue along the lines of "Extract duplicate interruption-restart code to a relevant module and review stdlib for unprotected select() calls" should be opened instead. Your thoughts?

----------
Added file: http://bugs.python.org/file16841/socketserver_eintr_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Fri Apr  9 11:40:05 2010
From: report at bugs.python.org (Torne Wuff)
Date: Fri, 09 Apr 2010 09:40:05 +0000
Subject: [issue6650] sre_parse contains a confusing generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1270806005.3.0.813319868982.issue6650@psf.upfronthosting.co.za>


Torne Wuff <torne-pythonbugs at wolfpuppy.org.uk> added the comment:

I suspect a better message could be invented, but I'm not sure what :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________

From report at bugs.python.org  Fri Apr  9 13:00:44 2010
From: report at bugs.python.org (Martin Zimmermann)
Date: Fri, 09 Apr 2010 11:00:44 +0000
Subject: [issue8356] SyntaxError: integer assignment with leading zeros (only
	8 and 9)
In-Reply-To: <1270810844.03.0.603411749549.issue8356@psf.upfronthosting.co.za>
Message-ID: <1270810844.03.0.603411749549.issue8356@psf.upfronthosting.co.za>


New submission from Martin Zimmermann <info at posativ.org>:

try this:
x = (05, 06, 07)
y = (08, 09, 019)

you will get SyntaxError: invalid token.
(also in python 2.5.2)

----------
components: Interpreter Core
messages: 102706
nosy: posativ
severity: normal
status: open
title: SyntaxError: integer assignment with leading zeros (only 8 and 9)
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8356>
_______________________________________

From report at bugs.python.org  Fri Apr  9 13:03:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Apr 2010 11:03:40 +0000
Subject: [issue8356] SyntaxError: integer assignment with leading zeros (only
	8 and 9)
In-Reply-To: <1270810844.03.0.603411749549.issue8356@psf.upfronthosting.co.za>
Message-ID: <1270811020.53.0.70554546671.issue8356@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The leading 0 is used to indicate octal numbers, and 8 and 9 are not valid octal digits.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8356>
_______________________________________

From report at bugs.python.org  Fri Apr  9 13:15:11 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 09 Apr 2010 11:15:11 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270811711.12.0.671670010696.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for your suggestions on the test code.  I will do that.

It seems like the hard-coded approach would be more brittle.  For example, if someone wants to replace __import__ with their own, e.g.

old__import__ = __builtins__.__import__

def __my_logging_import(*args, **kwargs):
    print "Importing %s..." % args[0]  # module name
    return old__import__(*args, **kwargs)

__builtins__.__import__ = __my_logging_import

Then the stack traces would be different:

  File "/Users/chris_g4/dev/Python/trunk/Lib/unittest/loader.py", line 92, in loadTestsFromName
    module = __import__('.'.join(parts_copy))
  File "unittests.py", line 8, in __my_logging_import
    return old__import__(*args, **kwargs)
ImportError: No module named sdasfasfasdf

This causes the unit tests not to pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Fri Apr  9 13:21:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 11:21:59 +0000
Subject: [issue8356] SyntaxError: integer assignment with leading zeros (only
	8 and 9)
In-Reply-To: <1270810844.03.0.603411749549.issue8356@psf.upfronthosting.co.za>
Message-ID: <1270812119.47.0.202743779044.issue8356@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Duly documented here: http://docs.python.org/reference/lexical_analysis.html#numeric-literals

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8356>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:00:46 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 09 Apr 2010 12:00:46 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1270814446.97.0.73966619146.issue7865@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Well, it would break code which currently ignores that it fails, so it's more a benefit than a loss for programmers imo.

I doubt the impact will be important though, because the io module is still quite recent, and furthermore errors on the last flush are quite unlikely to happen if previous ones succeeded (except "disk full", I don't see any reason for this to happen).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:17:54 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 09 Apr 2010 12:17:54 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1270791972.75.0.250402145498.issue4007@psf.upfronthosting.co.za>
Message-ID: <19391.3816.141797.342184@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Martin> If it did eat the patch, we would have lost it by now: there is
    Martin> nothing in the history that shows that a file was attached at
    Martin> some point. More likely, Skip forgot to attach it when
    Martin> submitting this report.

Yeah, I must have just forgotten to attach it.  At one point I'm pretty sure
I had something in my sandbox, but have nothing now.  Removing .a files is
pretty straightforward.  Removing .so.X.Y files is a little more cumbersome
because globbing isn't perfect.  This (only lightly tested) patch should be
good enough though:

Index: Makefile.pre.in
===================================================================
--- Makefile.pre.in     (revision 79207)
+++ Makefile.pre.in     (working copy)
@@ -1156,8 +1156,9 @@
        find $(srcdir) -name '*.py[co]' -exec rm -f {} ';'

 clean: pycremoval
-       find . -name '*.o' -exec rm -f {} ';'
+       find . -name '*.[oa]' -exec rm -f {} ';'
        find . -name '*.s[ol]' -exec rm -f {} ';'
+       find . -name '*.so.[0-9]*.[0-9]*' -exec rm -f {} ';'
        find build -name 'fficonfig.h' -exec rm -f {} ';' || true
        find build -name 'fficonfig.py' -exec rm -f {} ';' || true
        -rm -f Lib/lib2to3/*Grammar*.pickle

even though the second addition would also match files like

    Margaret.so.9a.1g4

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:21:01 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Apr 2010 12:21:01 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270815661.36.0.371830041379.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

5. uuid.getnode() can fall back to creating a random 48 bit number and
   so can  _windll_getnode() (by using UuidCreateSequential). Therefore,
   in unlucky cases 0xffffffffffff can be generated and the assert in
   check_node() will fail.


check_node() is beginning to look quite pointless...

----------
Added file: http://bugs.python.org/file16842/test_uuid2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:34:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 12:34:18 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1270816458.9.0.923243737085.issue8350@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The docstring looks right to me. "mode=0777" doesn't mean it takes a keyword argument, only that this argument has a default value.

You might want to fix posixmodule to accept keyword arguments, but it should probably be done for all functions then. An mkdir-specific patch would have little point IMO (after all it takes only two args, there's hardly any risk of confusion).

----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:35:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 12:35:45 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1270816545.34.0.133065864697.issue8350@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

This is a recurrent problem with Python functions implemented in C. Since introspection is not possible, developers have to use the first line of the docstring to write the signature, including default arguments. With your patch, people can?t rely on IDE tooltips that display introspected signature + first line of docstring anymore.

The ideal right fix would be for C functions to support introspection, e.g. with PEP 362.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:37:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 12:37:32 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1270816652.22.0.903712581427.issue7865@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You're right that silencing IO errors is bad.  Patch welcome.

----------
nosy: +amaury.forgeotdarc, pitrou
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:38:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 12:38:29 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1270816709.73.0.624714859388.issue8354@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:40:27 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 09 Apr 2010 12:40:27 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1270816827.69.0.60906379783.issue8350@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

The ideal right fix would be for C functions to support introspection - Agreed, but then it will be needed to do so in quite a number of C codes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:47:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 12:47:37 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1270817257.59.0.061984126483.issue8350@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A more attainable fix would be a way to mark up positional-only arguments that have a default value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Fri Apr  9 14:59:59 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Apr 2010 12:59:59 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270817999.37.0.0580516442983.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I do not understand the semantics of uuid.getnode(). Per the docs
it's supposed to return a hardware address. This would reasonably
make it a UUID version 1.

But then the random fallback should be a 47 bit number as per
http://www.ietf.org/rfc/rfc4122.txt section 4.5.

The docs for UuidCreateSequential don't say if the random fallback
is a random version 1 UUID.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Fri Apr  9 15:01:44 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 09 Apr 2010 13:01:44 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270818104.9.0.27972772549.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> I think you can simplify them a bit. For example, you can use assertRaises.

Actually, assertRaises doesn't seem to permit checking error text.  That may be one reason why try-except-else is being used instead throughout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Fri Apr  9 15:05:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Apr 2010 13:05:34 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1270818334.21.0.114788890224.issue7443@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If the problem with the fix is that lots of tests use test_support.unlink, then I don't see why the rename dance can't be implemented in test_support.unlink.  (Possibly conditioned on whether or not the tests are running on a windows platform.)  Dealing with unlink problems is why that method exists in the first place.

There are probably places in the test suite that *don't* use test_support.unlink, though, so fixing test_support.unlink will not necessarily fix all of the problems. We'll have to fix those other tests (probably by using the new test_support.unlink) as we find them.

An actual patch will need a test that doesn't rely on win32file (ctypes would be OK).  It may be necessary to rename to a unique filename, too. (To be clear, I think a unit test that reproduces the problem by doing an open with FILE_SHARE_DELETE is fine, we don't need a test that reproduces the race condition itself.  The windows experts will correct me if I'm wrong :)

I'm changing the stage to patch needed because it seems to me that using a technique like rename that doesn't introduce additional delays into the test suite is to be preferred.

----------
nosy: +r.david.murray
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Fri Apr  9 15:07:44 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 09 Apr 2010 13:07:44 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1270818464.75.0.966289930487.issue6715@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
nosy: +Nikratio

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Apr  9 15:08:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 13:08:47 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270818527.73.0.0766259563102.issue3581@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +nnorwitz, tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Fri Apr  9 16:14:55 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Fri, 09 Apr 2010 14:14:55 +0000
Subject: [issue2824] zipfile to handle duplicate files in archive
In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
Message-ID: <1270822495.7.0.355908378061.issue2824@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

Attached is the addition of the 'low_level' parameter to ZipFile. Included are the parameter, a global switch controlling whether the parameter will raise an Exception or trigger a DeprecationWarning (the latter, for now), updated tests and updated documents. I didn't run test_zipfile64, I can't say for sure it works but I have no reason to believe it doesn't.
Changes are against py3k; let me know what you think, I'll backport to trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file16843/low_level_zipfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2824>
_______________________________________

From report at bugs.python.org  Fri Apr  9 16:31:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 14:31:01 +0000
Subject: [issue1294032] Distutils writes keywords comma-separated
Message-ID: <1270823461.5.0.241257474499.issue1294032@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Comma-separated values are a Good Thing?, because you can have one notion expressed with more than one ?word?, e.g. ?text processing?.

Could we edit a PEP to reflect this or is it too late? Should someone start a discussion on a mailing list?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294032>
_______________________________________

From report at bugs.python.org  Fri Apr  9 16:32:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 14:32:10 +0000
Subject: [issue1294032] Distutils writes keywords comma-separated
Message-ID: <1270823530.63.0.283393317917.issue1294032@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Forgot to add I suggest that someone with admin rights move this bug to Distutils2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294032>
_______________________________________

From report at bugs.python.org  Fri Apr  9 17:15:17 2010
From: report at bugs.python.org (Tim Kersten)
Date: Fri, 09 Apr 2010 15:15:17 +0000
Subject: [issue8357] distutils does not allow installation with --root and
	--prefix, and give's incorrect error message
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>


New submission from Tim Kersten <tim.kersten at lincor.com>:

$ python setup.py install --root=/tmp/ --prefix=/usr
running install
error: must supply either home or prefix/exec-prefix -- not both

I believe that this should work. --root and --prefix are, from what I can tell, two unrelated options.

----------
assignee: tarek
components: Distutils
messages: 102724
nosy: tarek, timkersten
severity: normal
status: open
title: distutils does not allow installation with --root and --prefix, and give's incorrect error message
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 17:16:15 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 09 Apr 2010 15:16:15 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1270826175.92.0.433922349878.issue8354@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> The effect of signal.siginterrupt(somesig, False) is reset the first time a that signal is received.  This is not the documented behaviour, and I do not think this is a desireable behaviour.  It renders siginterrupt effectively useless at providing the robustness against EINTR it is intended to provide.

Actually, siginterrupt shouldn't be used.
The proper way is to use sigaction with SA_RESTART flag (and still, don't rely on SA_RESTART too much, certain syscalls are non restartable and this isn't realy portable).

> Another might be to not call PyOS_setsig from signal_handler at all -- I'm not sure why it is trying to reinstall itself, but perhaps there's some issue there I'm not aware of.

Because signal.signal might be implemented with sigaction() or signal() and the latter resets the default signal handler when the handler is called. This means that if your system doesn't support sigaction and and you don't reinstall it, then the handler will only get called the first time.
However, reinstalling the signal handler contains a race, because if a second signal comes before you reinstall it, it's handled by the default handler. That's why sigaction is much better (and calling PyOS_setsig unecessary when sigaction is available).

The problem you describe can happen with both sigaction and signal :

sigaction:
- you set your handler with signal.signal()
- sigaction() is called, and by default syscalls are not restarted (SA_RESTART is false)
- you call siginterrupt() with False, which juste reinstalls the handler with SA_RESTART to true
- the first signal arrives: signal_handler() schedules the call of your handler, and calls PyOS_setsig() 
- PyOS_setsig() reinstalls your handler (again, it's neither a good idea nor necessary with sigaction) _without_ SA_RESTART
- the second signal comes in
- you get a EINTR, game over

signal:
- you set your handler with signal.signal()
- signal() is called, and syscalls are not restarted by default
- you call siginterrupt() with False, which juste reinstalls the handler with SA_RESTART to true
- the first signal arrives: signal_handler() schedules the call of your handler, and calls PyOS_setsig() 
- PyOS_setsig() reinstalles your handler _without_ SA_RESTART (I think the flag is lost even before calling siginterrupt)
- the second signal comes in
- you get a EINTR, game over

So the simple fix when sigaction is available is simply to not call PyOS_setsig() from signal_handler.
When sigaction is not available, well, you have to recall that you want restartable syscalls, and call siginterrupt again with that value. But I think if the OS doesn't support sigaction, there's little chance it'll support siginterrupt.
(1) I just found out that Windows doesn't have sigaction, but I don't know Window much, so if someone could confirm that it doesn't support siginterrupt, then the fix would simply be to not reinstall handler when sigaction is available.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Fri Apr  9 17:31:30 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 15:31:30 +0000
Subject: [issue8357] distutils does not allow installation with --root and
	--prefix, and give's incorrect error message
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270827090.0.0.88270027726.issue8357@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Those are mutually exclusive:

  --prefix : installation prefix
  --root: install everything relative to this alternate root directory

root will install things into a completely alternate root and will use the existing installation scheme and make all paths relative to root.

Whereas prefix allows you to define an alternate value for the installation sys.prefix. And supposes that this prefix is in your PYTHONPATH. 

IOW, having the two options makes it impossible for distutils to choose where to put some files.

----------
resolution:  -> invalid
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 17:38:05 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Apr 2010 15:38:05 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270827485.94.0.25021658174.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I reread http://www.ietf.org/rfc/rfc4122.txt and I'm pretty sure that
if getnode() is supposed to return a hardware address, one of the
following should be used:

  1) If ifconfig etc. returns successfully, we are fine.

  2) If uuid_generate_time() or UuidCreateSequential() are used
     to extract the node ID, we have to make sure that the returned
     UUID is in fact RFC_4122 and version 1.

  3) The fallback node ID should be 47 bits according to section 4.5.


I've got a new patch (getnode.patch) that takes care of these issues.

----------
keywords:  -patch
resolution: accepted -> 
Added file: http://bugs.python.org/file16844/getnode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Fri Apr  9 17:52:06 2010
From: report at bugs.python.org (Tim Kersten)
Date: Fri, 09 Apr 2010 15:52:06 +0000
Subject: [issue8357] distutils does not allow installation with --root and
	--prefix, and give's incorrect error message
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270828326.41.0.762041898668.issue8357@psf.upfronthosting.co.za>


Tim Kersten <tim.kersten at lincor.com> added the comment:

I fail to see how these are, or at least should be mutually exclusive. Upon reading your reply I would think that if one was to specify both a --prefix and --root that the prefix would be relative to the --root.

i.e. --prefix changes the curront installation scheme as per usual

i.e. --root specifies an alternative "root", but obeys the installation scheme in every other sense. i.e.
(On linux) / => /path/to/alternative/root/


Any chance you could explain this further please? I'm having difficulties understanding why I'm wrong.

----------
versions: +Python 2.5, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 17:53:19 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 09 Apr 2010 15:53:19 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270828399.77.0.951802067258.issue8355@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This would be easier to review if the patch were generated with 'svn diff'.

That said, it looks okay in concept to me, although I couldn't apply it and test without manually mucking with the patch.

2.6 is in bugfix mode, so it can't be changed there. I added 3.2, since it should probably agree with 2.7.

What I can't answer is if this should actually be done. I don't know if anyone's relying on the current behavior. I do agree that unified diffs are more desirable.

----------
nosy: +eric.smith
priority:  -> low
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 18:23:43 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 16:23:43 +0000
Subject: [issue8357] distutils does not allow installation with --root and
	--prefix, and give's incorrect error message
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270830223.6.0.176175633171.issue8357@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

== prefix == 

With prefix, you need to make sure the target site-packages is in your PYTHONPATH:

  PYTHONPATH=/tmp/foo/lib/python2.6/site-packages/ python setup.py install --prefix=/tmp/foo

And here, prefix is used as the base location, and the command uses the schemes defined
for each platform.

So stuff will be installed in /tmp/foo  (bin/ , lib/python2.6, etc)

 
== root ==

With root, you just need to provide a path:

  python setup.py install --root=/tmp/foo

In this case, sys.prefix will be used relatively to root (location = root+sys.prefix), so for example,
under Mac OS X, I have '/Library/Frameworks/Python.framework/Versions/2.6' for sys.prefix.

So stuff will be installed under /tmp/foo/Library/Frameworks/Python.framework/Versions/2.6/

Since both options are used to define the base location, they are mutualy exclusive.
That's how it works today.

What are you trying to achieve exactly ?

Btw: Please don't add Python 2.5 in the versions. Python 2.5 is not a target anymore.

----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 18:46:11 2010
From: report at bugs.python.org (Darryl Miles)
Date: Fri, 09 Apr 2010 16:46:11 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270831571.84.0.63486554196.issue8108@psf.upfronthosting.co.za>


Darryl Miles <darryl.miles at darrylmiles.org> added the comment:

I've updated my attachment to the bug, if you read the old one please re-read the updated version (since some points in there were not accurate).

With regards to the OpenSSL error return -1/ERROR_SYSCALL with errno==0 being observed, I shall respond into the OpenSSL mailing list with a fuller response.  The man page SSL_get_error(3) does explain what getting a zero error means in relation to end-of-file at the BIO/TCP socket level.  In light of the presumption by me that the problem was because one end did a syscall close(fd) this makes perfect sense in the context of your observation and OpenSSL appears to be working as documented.  There is also code to print out the error in Python at Modules/_ssl.c method PySSL_SetError() so I'm not sure of the source of the funny looking error printing in relation to the ftpcli test case, consider it to be an error message formatting glitch.


Now the issue I see here is that there are clearly 3 use cases Python should provide:

 * one-shot raw mode (don't enter the loop at all, as per newssl5.patch/my attachment, this is more or less what you already have in CVS, but I would remove the 2nd call to SSL_shutdown(), raw mode means exactly that; the caller is in charge of calling it again, thin layer for Python power users) [case-1]

 * perform IO sleep/wait as necessary until we observe SSL_shutdown()==0 (or better!  so this will return if 0 or 1 is returned) [case-2]

 * perform IO sleep/wait as necessary until we observe SSL_shutdown()==1 [case-3]

I presume you already have a way of handling the configuration of I/O timeouts as per Python's IO processing model (that is provided by some other API mechanism).



The question is what is the best way to provide them (what is inline with the Python paradigm?) :

 * one method, keep existing named method, add new optional argument that can indicate all 3 modes of operation.  Debate which of the 3 modes of operation is the default when the argument is not specified, case-1 seems to most backwardly compatible.  [I am presuming python supports optional arguments]

 * new method, keep existing as-is (to cover case 1), implement case-2 and case-3 in the method which also take an argument for the user to specify which use case they want.


>From this a patch should be straight-forward.  Then we can look to see if the FTP client or server is doing anything wrong in light of having the building blocks in place to achieve any goal on top of OpenSSL.

----------
Added file: http://bugs.python.org/file16845/python_ssl_v2.c.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Apr  9 18:46:20 2010
From: report at bugs.python.org (Darryl Miles)
Date: Fri, 09 Apr 2010 16:46:20 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1270831580.33.0.0625451321558.issue8108@psf.upfronthosting.co.za>


Changes by Darryl Miles <darryl.miles at darrylmiles.org>:


Removed file: http://bugs.python.org/file16838/python_ssl.c.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Apr  9 19:07:03 2010
From: report at bugs.python.org (Tim Kersten)
Date: Fri, 09 Apr 2010 17:07:03 +0000
Subject: [issue8357] distutils does not allow installation with --root and
	--prefix, and give's incorrect error message
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270832823.07.0.795847639534.issue8357@psf.upfronthosting.co.za>


Tim Kersten <tim.kersten at lincor.com> added the comment:

Ok, this is embarrassing. :-/

$ python setup.py install --root=/tmp/ --prefix=/usr
running install
error: must supply either home or prefix/exec-prefix -- not both

The above is not caused by specifying both --root and --prefix as I had assumed. It was my forgetting that I had specified the --home option in a setup.cfg file. I'm so sorry for wasting your time.

Having removed the setup.cfg file and have tested it again and now it behaves exactly as I had anticipated. i.e. --prefix is relative to --root, so it is actually possible to specify both.

In particular what this allows one to achieve is easiest shown by example:

A) $ python setup.py install --prefix=/tmp/test1
B) $ python setup.py install --prefix=/usr/special --root=/tmp/test2

in A) it installs as such:

/etc/mypythonapp.settings
/tmp/test1/mypythonapp/...

in B) it installs as such:
/tmp/test2/etc/mypythonapp.settings
/tmp/test2/usr/special/mypythonapp/...


This bug can be closed. Again, my apologies and thank you for taking the time to help me sort it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 19:09:50 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 17:09:50 +0000
Subject: [issue8358] absolute_import future directive ignored by 2to3
In-Reply-To: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>
Message-ID: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

I'm using Python 3.1.2 64-bit on Windows.

I've found that even if "absolute_import" is imported from __future__, 2to3 will convert imports to be treated as relative.

To demonstrate this behavior, I created a small package "abs_imp_test" (attached).

abs_imp_test.__init__ is 0 bytes.
abs_imp_test.string is a one-line file.
  foo = 'bar'
abs_imp_test.main contains 4 lines:
  from __future__ import absolute_import
  import string
  assert not hasattr(string, 'foo'), 'fail'
  print("success")

Put abs_imp_test package somewhere in the python path (just having it relative to current directory works).

Note that the code is designed to be future-proof (using the future directive), so will run under Python 2.6 and Python 3.1 without errors.

> python26\python -c "from abs_imp_test import main"
success
> python31\python -c "from abs_imp_test import main"
success

However, if I run 2to3 on main, it converts "import string" to "from . import string" which changes the fundamental meaning of the import and breaks the test.

> 2to3 abs_import_test
...
RefactoringTool: Files that were modified:
RefactoringTool: abs_imp_test\main.py

> python -c "from abs_imp_test import main"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "abs_imp_test\main.py", line 4, in <module>
    assert not hasattr(string, 'foo'), "fail"
AssertionError: fail

Is it possible that if the absolute_import future directive is present that the imports not be modified for relativity?

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: abs_imp_test.zip
messages: 102733
nosy: jaraco
severity: normal
status: open
title: absolute_import future directive ignored by 2to3
versions: Python 3.1
Added file: http://bugs.python.org/file16846/abs_imp_test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8358>
_______________________________________

From report at bugs.python.org  Fri Apr  9 19:18:54 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 17:18:54 +0000
Subject: [issue8358] absolute_import future directive ignored by 2to3
In-Reply-To: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>
Message-ID: <1270833534.74.0.180875158702.issue8358@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

More importantly, is there a workaround for main.py that will work in Python 2, and in Python 3 after 2to3, that doesn't require any module renaming?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8358>
_______________________________________

From report at bugs.python.org  Fri Apr  9 19:42:11 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 17:42:11 +0000
Subject: [issue8358] absolute_import future directive ignored by 2to3
In-Reply-To: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>
Message-ID: <1270834931.54.0.150904331286.issue8358@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I found a workaround by excluding the "import" fixer that seems to work.

For the example,

> 2to3 -x import abs_imp_test

The command still modifies main, but it only removes the __future__ directive and doesn't modify the imports.

For my real-world package, which is using distutils, I added the following to get a build_py that will run 2to3:

try:
	from distutils.command.build_py import build_py_2to3 as build_py
	# exclude some fixers that break already compatible code
	from lib2to3.refactor import get_fixers_from_package
	fixers = get_fixers_from_package('lib2to3.fixes')
	for skip_fixer in ['import']:
		fixers.remove('lib2to3.fixes.fix_' + skip_fixer)
	build_py.fixer_names = fixers
except ImportError:
	from distutils.command.build_py import build_py

This works because the entire package is already using absolute imports wherever they are relevant, so removing the import fixer is appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8358>
_______________________________________

From report at bugs.python.org  Fri Apr  9 19:54:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Apr 2010 17:54:24 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270835664.18.0.472316065853.issue8355@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For what it is worth, the unix 'diff' command does not produce unified format by default.  It doesn't produce the format diff.py does by default either, though.

Our normal policy is not to change an interface unless there's a strong reason.  On the other hand, Tools probably don't need to be held to as high a standard as library code.

I guess I'm +0 on this change.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 20:00:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Apr 2010 18:00:01 +0000
Subject: [issue8357] distutils does not allow installation with --root and
	--prefix, and give's incorrect error message
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270836001.09.0.00271634987765.issue8357@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 20:00:05 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 09 Apr 2010 18:00:05 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1270836005.61.0.0180087676177.issue8339@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Hello Michael, 

Looking a bit deeper into this issue, I don't see that 'x://' and 'x:///y' qualifies as valid URLS as per RFC 3986. (Well, urlparse has been not strictly conforming to it, but that is a different issue)

If you look at the section 3. it states the following for validity.

 hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty
 
In those cases, I would assume that 'x://y', x:/y','x:/','/' as valid URLS, but not the two examples you mentioned.

For the issue7904, we had just gone by the definition of RFC to make that minor change and it has resulted in this issue. I looked at the code to see if this can be addressed, but I see that your examples did not fit in as valid urls.

Do you have any opinions on this?

We can just the test_urlparse.py a little like below, and you might fix the break your code.

     def test_unparse_parse(self):
-        for u in ['Python', './Python','x-newscheme://foo.com/stuff']:
+        for u in ['Python', './Python','x-newscheme://foo.com/stuff','x://y','x:/y','x:/','/',]:
             self.assertEqual(urlparse.urlunsplit(urlparse.urlsplit(u)), u)
             self.assertEqual(urlparse.urlunparse(urlparse.urlparse(u)), u)

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Fri Apr  9 20:25:49 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Apr 2010 18:25:49 +0000
Subject: [issue8357] Add a --show-installation-paths in the install command
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270837549.04.0.906426588231.issue8357@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ooops you are right, I messed up too in my explanation, I mischecked the code. root and home are mutually exclusive, not root and prefix. 

In any case, all those options are making it really hard to understand. 

I'd like to make this story easier in distutils2, So I'll move this issue in there.

Maybe we could have a --show-installation-paths option in install that displays the installation paths the install command will use, and from where the options were read from (and in particular from which .cfg files)

----------
components: +Distutils2 -Distutils
resolution: invalid -> accepted
status: closed -> open
title: distutils does not allow installation with --root and --prefix, and give's incorrect error message -> Add a --show-installation-paths in the install command

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 20:35:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 09 Apr 2010 18:35:32 +0000
Subject: [issue7007] Tiny inconsistency in the orthography of "url encoded" in
	the doc of urllib.parse
In-Reply-To: <1254071339.25.0.500752949705.issue7007@psf.upfronthosting.co.za>
Message-ID: <1270838132.45.0.357267845114.issue7007@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

What is referred to as URL-encoded or URL encoded is technically 'percent-encoding'. Consistency would desirable and I think 'URL encoded' is okay. It involves a minor change in removing '-' in some places. Once trunk opens, I shall make those changes in the docs referenced here.

----------
assignee: georg.brandl -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7007>
_______________________________________

From report at bugs.python.org  Fri Apr  9 21:25:47 2010
From: report at bugs.python.org (Fernando Perez)
Date: Fri, 09 Apr 2010 19:25:47 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1270841147.26.0.0922503881651.issue7897@psf.upfronthosting.co.za>


Fernando Perez <fdo.perez at gmail.com> added the comment:

Hey Yarick,

On Thu, Apr 8, 2010 at 18:53, Yaroslav Halchenko <report at bugs.python.org> w=
rote:
> In PyMVPA we have our little decorator as an alternative to Fernando's ge=
nerators, =A0and which is closer, I think, to what Michael was wishing for:
> @sweepargs
>
> http://github.com/yarikoptic/PyMVPA/blob/master/mvpa/testing/sweepargs.py
>
> NB it has some minor PyMVPA specificity which could be easily wiped out, =
and since it was at most 4 eyes looking at it and it bears "evolutionary" c=
hanges, it is far from being the cleanest/best piece of code, BUT:
>
> * it is very easy to use, just decorate a test method/function and give a=
n argument which to vary within the function call, e.g smth like
>
> @sweepargs(arg=3Drange(5))
> def test_sweepargs_demo(arg):
> =A0 =A0ok_(arg < 5)
> =A0 =A0ok_(arg < 3)
> =A0 =A0ok_(arg < 2)
>
> For nose/unittest it would still look like a single test

Thanks for the post; I obviously defer to Michael on the final
decision, but I *really* would like a solution that reports an
'argument sweep' as multiple tests, not as one.  They are truly
multiple tests (since they can pass/fail independently), so I think
they should be treated as such.

On the other hand, your code does have nifty features that could be
used as well, so perhaps the best of both can be used in the end.

Cheers,

f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Apr  9 21:42:25 2010
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Fri, 09 Apr 2010 19:42:25 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1270842145.86.0.675434701209.issue7897@psf.upfronthosting.co.za>


Yaroslav Halchenko <yarikoptic at gmail.com> added the comment:

Fernando, I agree... somewhat ;-)

At some point (whenever everything works fine and no unittests fail) I wanted to merry sweepargs to nose and make it spit out a dot (or animate a spinning wheel ;)) for every passed unittest, so instead of 300 dots I got a picturesque field of thousands dots and Ss and also saw how many were skipped for some parametrizations.  But I became "Not sure" of such feature since field became quite large and hard to "grasp" visually although it gave me better idea indeed of what was the total number of "testings" were done and skipped.  So may be it would be helpful to separate notions of tests and testings and provide user ability to control the level of verbosity (1 -- tests, 2 -- testings, 3 -- verbose listing of testings (test(parametrization)))

But I blessed sweepargs every time whenever something goes nuts and a test starts failing for (nearly) all parametrization at the same point.  And that is where I really enjoy the concise summary.
Also I observe that often an ERROR bug reveals itself through multiple tests.  So, may be it would be worth developing a generic 'summary' output which would collect all tracebacks and then groups them by the location of the actual failure and tests/testings which hit it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Apr  9 21:56:19 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 09 Apr 2010 19:56:19 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1270842979.91.0.150766717262.issue8354@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Attached are two patches:
- test_signal_siginterrupt.diff is a patch for Lib/test/test_signal.py to check for this problem (more than one signal received after calling signal.siginterrupt())
before:
$ ./python Lib/test/regrtest.py test_signal
test_signal
1 test OK.

after:
$ ./python Lib/test/regrtest.py test_signal
test_signal
test test_signal failed -- Traceback (most recent call last):
  File "/home/cf/python/trunk/Lib/test/test_signal.py", line 299, in test_siginterrupt_off
    self.assertEquals(i, False)
AssertionError: True != False

1 test failed:
    test_signal

- signal_noreinstall.diff is a patch against Modules/signalmodule.c which modifies signal_handler() to call PyOS_setsig() only when sigaction is not available, since in that case the signal handler doesn't need to be reinstalled. This solves this problem, and also saves a call to sigaction every time a signal is received (even if its probably doesn't cost much).

with patch and updated test:
$ ./python Lib/test/regrtest.py test_signal
test_signal
1 test OK.

Of course, this also corrects the problem with sig-test.py, the terminal can be resized indefinitely.
I also passed test_subprocess and test_socketserver just to be sure, but reviews are more than welcome.

----------
keywords: +patch
Added file: http://bugs.python.org/file16847/test_signal_siginterrupt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Fri Apr  9 21:56:23 2010
From: report at bugs.python.org (Tim Kersten)
Date: Fri, 09 Apr 2010 19:56:23 +0000
Subject: [issue8357] Add a --show-installation-paths in the install command
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270842983.29.0.834680840764.issue8357@psf.upfronthosting.co.za>


Tim Kersten <tim.kersten at lincor.com> added the comment:

Such an option would be useful indeed.

An idea, though perhaps it's overkill, would be to show the current values of the options causing problems, specifically if they come from a config file or environment variable.

i.e. when setup.cfg contains home=/somewhere

$ python setup.py install --prefix=/tmp
running install
error: must supply either home or prefix/exec-prefix -- not both
       setup.cfg: home=/somewhere

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 21:56:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 19:56:32 +0000
Subject: [issue7007] Tiny inconsistency in the orthography of "url encoded" in
	the doc of urllib.parse
In-Reply-To: <1254071339.25.0.500752949705.issue7007@psf.upfronthosting.co.za>
Message-ID: <1270842992.27.0.119846028221.issue7007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello.

I?m not a native speaker, but I know that you need hyphens inside adjectives: URI-encoded, percent-encoded, built-in <0.2 wink>,?etc.

I?m willing to produce a patch that changes ?URL-encoded? to ?percent-encoded?.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7007>
_______________________________________

From report at bugs.python.org  Fri Apr  9 21:56:55 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 09 Apr 2010 19:56:55 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1270843015.13.0.694261053774.issue8354@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file16848/signal_noreinstall.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Fri Apr  9 22:01:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 20:01:32 +0000
Subject: [issue8357] Add a --show-installation-paths in the install command
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270843292.9.0.890443728257.issue8357@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8357>
_______________________________________

From report at bugs.python.org  Fri Apr  9 22:07:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 20:07:26 +0000
Subject: [issue7927] SSL socket is not closed properly
In-Reply-To: <1266146726.16.0.222413736354.issue7927@psf.upfronthosting.co.za>
Message-ID: <1270843646.85.0.950463861215.issue7927@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> janssen
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7927>
_______________________________________

From report at bugs.python.org  Fri Apr  9 22:07:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 20:07:37 +0000
Subject: [issue7943] Memory leak due to circular references in ssl.SSLSocket
In-Reply-To: <1266341912.31.0.218071173939.issue7943@psf.upfronthosting.co.za>
Message-ID: <1270843657.18.0.101320075675.issue7943@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> janssen
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7943>
_______________________________________

From report at bugs.python.org  Fri Apr  9 22:08:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 20:08:59 +0000
Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face
	of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1270843739.55.0.684019815354.issue7425@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it a dup of issue1785?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Fri Apr  9 22:12:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Apr 2010 20:12:52 +0000
Subject: [issue8358] absolute_import future directive ignored by 2to3
In-Reply-To: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>
Message-ID: <1270843972.78.0.213436298748.issue8358@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8358>
_______________________________________

From report at bugs.python.org  Fri Apr  9 22:14:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 20:14:34 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1270673325.34.0.298821505348.issue8240@psf.upfronthosting.co.za>
Message-ID: <1270844194.3435.66.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Wouldn't it be nicer if mode was a property?

Good point. I guess it would indeed...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Apr  9 22:53:25 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 20:53:25 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270846405.93.0.967583686861.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Attached is 'svn diff'. Previous one was taken directly from Mercurial Queue, which is a pretty awesome thing to use.

----------
Added file: http://bugs.python.org/file16849/8355.diff-py-unified-by-default.svn.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:03:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 21:03:27 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270847007.5.0.349396949068.issue8355@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Some diff-emitting utilities only support unified format, but if diff.py is supposed to be a diff(1) replacement, changing default options seems bad.

Eric, I think ?patch -p1 < file? would have done the trick, without manual mucking.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:12:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Apr 2010 21:12:14 +0000
Subject: [issue8358] absolute_import future directive ignored by 2to3
In-Reply-To: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>
Message-ID: <1270847534.4.0.947902087038.issue8358@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r79917.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8358>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:19:51 2010
From: report at bugs.python.org (Fernando Perez)
Date: Fri, 09 Apr 2010 21:19:51 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1270847991.24.0.339680255809.issue7897@psf.upfronthosting.co.za>


Fernando Perez <fdo.perez at gmail.com> added the comment:

Yarick: Yes, I do actually see the value of the summary view.  When I have a parametric test that fails, I tend to just run nose with -x so it stops at the first error and with the --pdb options to study it, so I simply ignore all the other failures.  To me, test failures are quite often like compiler error messages: if there's a lot of them, it's best to look only at the first few, fix those and try again, because the rest could be coming from the same cause.

I don't know if Michael has plans/bandwidth to add the summary support as well, but I agree it would be very nice to have, just not at the expense of individual reporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:28:08 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 09 Apr 2010 21:28:08 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270848488.68.0.66093595085.issue8355@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I tried -p1 and it failed, but no matter. The contents were clear enough, and exactly how I would have changed the code.

$ patch -p1 < 8355.diff-py-unified-by-default.diff 
patching file Tools/scripts/diff.py
Hunk #1 FAILED at 13.
Hunk #2 FAILED at 34.
2 out of 2 hunks FAILED -- saving rejects to file Tools/scripts/diff.py.rej

The new patch worked for me.

I'm -0 on this change, for what it's worth. It's probably all irrelevant, anyway. I can't imagine anyone actually generates their diffs with diff.py. As a useful demonstration of how difflib works, it does its job as it currently stands.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:33:57 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 21:33:57 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270848837.74.0.280137388037.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is not a diff replacement. Its output, as David noted, is not a diff output format and can not be reliably parsed due to issue7585 and issue7582 combination.

For being a diff replacement it will have to get rid of .py extension and gain a dozen of options. Such as --normal, -p, -w, -q, -r etc. Without these options diff.py can not be considered diff replacement. This script is more useful on its own, providing reasonable defaults for a cross-platform way of making patches for Python users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:41:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Apr 2010 21:41:56 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270849316.28.0.226220616756.issue8355@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your use case and rationale make sense to me. I?d be +0.5 if I had a voice :)

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:44:51 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 09 Apr 2010 21:44:51 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1270849491.85.0.800449711335.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

If we provide builtin support for parameterized tests it will have to report each test separately otherwise there is no point. You can already add support for running tests with multiple parameters yourself - the *only* advantage of building support into unittest (as I see it) is for better reporting of individual tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Apr  9 23:46:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 09 Apr 2010 21:46:42 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270849602.27.0.651918271406.issue8355@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm with Eric, -0. I don't really think the change is necessary.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Sat Apr 10 00:26:39 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Fri, 09 Apr 2010 22:26:39 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1270851999.5.0.10389593328.issue6457@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

I've updated the sample code to run with Python 3 and tested on Ubuntu 9.10 with and without setting subprocess._has_poll = False.

As expected, when using poll() the sample runs correctly.
When not using poll() the sample breaks (sometimes no data, sometimes some data; oddly, it seems the 'some data' variant appears only when I strace the process, probably because it slows things down).

I suggest this be committed against 3.2 as well, but I don't know how these things are usually done; should I produce a separate patch which ports the latest patch currently posted in this thead against py3k? Or will this be done by whomever applies the patch?

----------
nosy: +Yaniv.Aknin
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6457>
_______________________________________

From report at bugs.python.org  Sat Apr 10 00:37:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Apr 2010 22:37:01 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1270852621.17.0.261570113194.issue8322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After some investigation, the error does occur because of the aforementioned changelog entry (SSLv2 weak ciphers are now disabled by default). To check it I just added the following line to newPySSLObject():

     SSL_CTX_set_cipher_list(self->ctx, "ALL");

Of course this isn't desirable: we shouldn't blindly enable weak ciphers. Instead we could simply add an argument to configure allowed ciphers, and use "ALL" in our tests. Or we could add a separate method to configure ciphers.

(this begs the question of whether this is suitable post-beta1)

What do you think?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Sat Apr 10 01:34:16 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 09 Apr 2010 23:34:16 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270856056.43.0.744627360756.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

David, yes messing about with processor affinities is certainly not nice.
Especially since the issue is cross-platform.
The pthreads api doesn't offer much.  There is pthreadd_setschedparam(), and pthreads_setconcurrency().  Unfortunately I don't have a pthreads machine to test that with.
On windows, one possibility would be to switch to fibers, in the case of a yielding thread.  I don't know if that would change anything, or if the thread-to-fiber and vice versa conversion is lightweight enough to be used dynamically.

Antoine: I'm not familiar with ccbench.  I?ll look into it.   As for my FIFO fix, py3k is trying to do more, namely get rid of the checkinterval. It is most certainly a more complex solution and with it its own set of problems.  The only thing that needs fixing is to add "fairness" to the GIL.

I know that this is coming a bit late for 2.7 and I'm not pushing it as such for 2.7.  But after 2.7 comes 2.8 (and so on ad infinitum)  But I'm also pointing out the obvious problem and an obvious simple fix which doesn't involve inventing a whole new system.  I would have thought that this should at least spark some enthusiasm.

It's unfortunate, maybe, that I only realized so late that the pythread GIL was implemented using a homebrew condition variable mechanism.  I always thougth (being a windows guy) that it were simply using the pthread_mutex() and thus the greedy behaviour of the GIL could be ascribed to that.

Anyway, I?ll continue giving this patch some love.  I wouldn't be surprised if it, and especially the "priority" variant, would be appealing to people doing e.g. webservers with 2.x technology.

Another thing that the "priority" patch has done is convince me that I really need to implement this scheduling mode in stackless, since it does appear to help network latency when using FIFO scheduling of threads / tasklets.

Cheers!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sat Apr 10 01:48:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 23:48:01 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270856881.1.0.072930005911.issue8299@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

If it really improves multicore performance and none of our test fail (even in memory/resource/time survival tests) then I'd give it a try even after a beta. 2.x is still the best practical version out there.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sat Apr 10 03:02:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Apr 2010 01:02:08 +0000
Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face
	of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1270861328.33.0.468047430735.issue7425@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It doesn't look like it is the same bug to me.  This one is more general.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Sat Apr 10 04:25:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Apr 2010 02:25:01 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1270866301.47.0.0999660636024.issue7301@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The tests don't look good to me. You should use p.communicate() rather than p.stdout.read(). Also, check the error return code and raise an error if it's non-zero.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Sat Apr 10 04:48:47 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Sat, 10 Apr 2010 02:48:47 +0000
Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on
	Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1270867727.52.0.0740264723846.issue7334@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Patch with tests (which can only really test it on Windows) here

http://bitbucket.org/pjenvey/et-2009-provolone/changeset/8292a06090a3/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7334>
_______________________________________

From report at bugs.python.org  Sat Apr 10 04:49:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 10 Apr 2010 02:49:55 +0000
Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on
	Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1270867795.2.0.521188353295.issue7334@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7334>
_______________________________________

From brian.curtin at gmail.com  Fri Apr  9 23:42:32 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Fri, 9 Apr 2010 16:42:32 -0500
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270848488.68.0.66093595085.issue8355@psf.upfronthosting.co.za>
References: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
	<1270848488.68.0.66093595085.issue8355@psf.upfronthosting.co.za>
Message-ID: <y2ncf9f31f21004091442r53274bedw639ba4c3fa9fdc90@mail.gmail.com>

On 2010-04-09, Eric Smith <report at bugs.python.org> wrote:
>
> Eric Smith <eric at trueblade.com> added the comment:
>
> I tried -p1 and it failed, but no matter. The contents were clear enough,
> and exactly how I would have changed the code.
>
> $ patch -p1 < 8355.diff-py-unified-by-default.diff
> patching file Tools/scripts/diff.py
> Hunk #1 FAILED at 13.
> Hunk #2 FAILED at 34.
> 2 out of 2 hunks FAILED -- saving rejects to file Tools/scripts/diff.py.rej
>
> The new patch worked for me.
>
> I'm -0 on this change, for what it's worth. It's probably all irrelevant,
> anyway. I can't imagine anyone actually generates their diffs with diff.py.
> As a useful demonstration of how difflib works, it does its job as it
> currently stands.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8355>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/brian.curtin%40gmail.com
>
>

From report at bugs.python.org  Sat Apr 10 11:32:49 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 10 Apr 2010 09:32:49 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270891969.34.0.639545927544.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Sorry, the random node id generation in uuid.py is correct. The least
significant bit of the first octet (which is set to 1) is the first
one transmitted on the network, then the "low 47 random bits" follow.

I assumed that the least significant bit of the first octet was part
of the low 47 bits.



Patch test_uuid3 addresses points 1-5 and is almost the same as
test_uuid.patch, so I reset the resolution to 'accepted'.

As I said, there isn't much left that check_node() can check. One
could possibly check that a MAC address retrieved by ifconfig does
not have the multicast bit set, but what if a user has set the
hardware MAC to a strange value? Correctly retrieving that value
can't be regarded as a failure of uuid.py.


Should the patch go into the maintenance branches as well (after the
beta is out)?

----------
keywords: +patch -needs review
Added file: http://bugs.python.org/file16850/test_uuid3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Sat Apr 10 11:32:59 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 10 Apr 2010 09:32:59 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270891979.54.0.5692076376.issue3581@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Sat Apr 10 11:38:00 2010
From: report at bugs.python.org (=?utf-8?b?2LnYqNiv2KfZhNmE2Ycg2LTZhNmKIChBYmRlbGxhaCBDaGVsbGkp?=)
Date: Sat, 10 Apr 2010 09:38:00 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>


New submission from ??????? ??? (Abdellah Chelli) <sneetsher at gmail.com>:

c/printf accepts this:

n=1;
printf("One hour.", n);

in other hand python/print rises an error:

n=1
print "One hour." % n

Exactly the % formatting operation.
(TypeError: not all arguments converted during string formatting)

This feature is very important when we come to I18n (translation using gettext).

As most translator don't know this work around "%i hour." or "(%i) One hour.". This is not correct for many languages as I know like Arabic where they should write some thing like "One hour." or "An hour.".

https://bugs.launchpad.net/python/+bug/341015

Could this fixed to have same behaviour as in c? More robust.

----------
components: Interpreter Core
messages: 102764
nosy: sneetsher
severity: normal
status: open
title: % formating - TypeError: not all arguments converted during string formatting
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Sat Apr 10 12:41:46 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 10 Apr 2010 10:41:46 +0000
Subject: [issue8360] doc: unittest.skipTest method added in 2.7
Message-ID: <1270896106.71.0.804820199929.issue8360@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
assignee: georg.brandl
components: Documentation
files: doc.python-version-for-skiptest.diff
keywords: patch
nosy: georg.brandl, techtonik
severity: normal
status: open
title: doc: unittest.skipTest method added in 2.7
versions: Python 2.7
Added file: http://bugs.python.org/file16851/doc.python-version-for-skiptest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8360>
_______________________________________

From report at bugs.python.org  Sat Apr 10 12:45:45 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 10 Apr 2010 10:45:45 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270896345.19.0.338183738597.issue8359@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Can you use str.format instead? It doesn't have this restriction. It's available in 2.6 and 3.0.

----------
nosy: +eric.smith
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Sat Apr 10 12:47:32 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 10 Apr 2010 10:47:32 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270896452.3.0.912864600726.issue8359@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Also, if you use the 'mapping' version of %-formatting you also don't have this restriction:

>>> 'One hour' % {'n': 3}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Sat Apr 10 13:15:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 10 Apr 2010 11:15:43 +0000
Subject: [issue8360] doc: unittest.skipTest method added in 2.7
In-Reply-To: <1270898143.06.0.946134736197.issue8360@psf.upfronthosting.co.za>
Message-ID: <1270898143.06.0.946134736197.issue8360@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Thanks, fixed in r79923.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8360>
_______________________________________

From report at bugs.python.org  Sat Apr 10 13:17:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 10 Apr 2010 11:17:08 +0000
Subject: [issue8346] Old Version Name in Interactive Mode
In-Reply-To: <1270728555.35.0.913114676338.issue8346@psf.upfronthosting.co.za>
Message-ID: <1270898228.66.0.702902801237.issue8346@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r79924.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8346>
_______________________________________

From report at bugs.python.org  Sat Apr 10 13:25:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 10 Apr 2010 11:25:32 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270898732.48.0.298549299234.issue8359@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think we won't add new features to %-formatting, when it is considered old-style anyway.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Sat Apr 10 13:41:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 11:41:25 +0000
Subject: [issue8361] Remove assert in functools.total_ordering
In-Reply-To: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>
Message-ID: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Hello

The correct behavior of functools.total_ordering depends on a check performed with an assert. Attached patch changes it to a test that always runs.

Since it?s a kind of protocol error, I went for TypeError but you may disagree.

Regards

----------
components: Library (Lib)
files: remove-assert-in-total_ordering.diff
keywords: patch
messages: 102770
nosy: merwok, rhettinger
severity: normal
status: open
title: Remove assert in functools.total_ordering
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16852/remove-assert-in-total_ordering.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8361>
_______________________________________

From report at bugs.python.org  Sat Apr 10 13:55:58 2010
From: report at bugs.python.org (=?utf-8?b?2LnYqNiv2KfZhNmE2Ycg2LTZhNmKIChBYmRlbGxhaCBDaGVsbGkp?=)
Date: Sat, 10 Apr 2010 11:55:58 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270900558.6.0.623886275404.issue8359@psf.upfronthosting.co.za>


??????? ??? (Abdellah Chelli) <sneetsher at gmail.com> added the comment:

'One hour' % {'n': 3} / mapping will not work gettext replaces the string for each language.

str.format works well.

The problem we couldn't submit a bug to change the code for all packages using it.

I think it's better to be fixed here. At lease this problem must be mentioned within the "% formatting" on Documentation. So developers will avoid using it on internationalized tools.

I have already written this.
So is str.format the new way for formatting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Sat Apr 10 14:14:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 12:14:39 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Hello

The maintainers listing is helpful for us outside bug reporters, but only present in the py3k branch. I copied it and reverted module name changes. Attached is the resulting file and the diff against py3k.

Regards

----------
assignee: georg.brandl
components: Documentation
files: maintainers.rst
messages: 102772
nosy: georg.brandl, merwok, r.david.murray
severity: normal
status: open
title: Add Misc/maintainers.rst to 2.x branch
versions: Python 2.7
Added file: http://bugs.python.org/file16853/maintainers.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Sat Apr 10 14:15:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 12:15:05 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1270901705.75.0.683883045834.issue8362@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16854/maintainers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Sat Apr 10 14:19:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 12:19:02 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1270901942.61.0.559101867813.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello spelling and doc people

(I hope it?s okay to use this bug as umbrella instead of opening a myriad bugs for typos.)

Attached patch fixes small things in functools module and docs:
- Typos: ?simplies? does not exist, ?fills-in? needs no hyphen since it?s a verb;
- Unnecessary repetition of filename in docstring (doc tools are good enough to introspect it, see e.g. ?pydoc functools?);
- Whitespace in keyword arguments;
- Use triple-quoted docstrings for consistency?s sake.

Regards

----------
Added file: http://bugs.python.org/file16855/functools-typos-pep8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sat Apr 10 14:31:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 10 Apr 2010 12:31:24 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270902684.54.0.0845837811433.issue8359@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't understand how this:
n=1
print "One hour." % n

is different from this:
map={'n': 3}
print "One hour." % map

In any event, if str.format works for you, use that. It's the new style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Sat Apr 10 14:48:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Apr 2010 12:48:34 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1270903714.14.0.213796372951.issue3581@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Should the patch go into the maintenance branches as well (after the
> beta is out)?

Yes, I think it would be nice (though not mandatory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Sat Apr 10 15:04:36 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 10 Apr 2010 13:04:36 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1270904676.32.0.259096373053.issue7355@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Sat Apr 10 15:13:14 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 10 Apr 2010 13:13:14 +0000
Subject: [issue8363] Lots of duplicate code between test_classify_oldstyle and
	test_classify_newstyle in test_inspect.py
In-Reply-To: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>
Message-ID: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

There are two tests for the way inspect.classify_class_attrs handles various sorts of attributes.  The tests are identical, except one uses a classic class and one a new-style class.  The tests sources have actually begun to diverge, but so far only in whitespace.  This code will be easier to maintain (not to mention shorter) if there is just one copy of the actual test parts.

----------
assignee: exarkun
components: Library (Lib), Tests
keywords: needs review, patch
messages: 102776
nosy: exarkun
severity: normal
status: open
title: Lots of duplicate code between test_classify_oldstyle and test_classify_newstyle in test_inspect.py
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8363>
_______________________________________

From report at bugs.python.org  Sat Apr 10 15:14:19 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 10 Apr 2010 13:14:19 +0000
Subject: [issue8363] Lots of duplicate code between test_classify_oldstyle and
	test_classify_newstyle in test_inspect.py
In-Reply-To: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>
Message-ID: <1270905259.36.0.488667020569.issue8363@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


Added file: http://bugs.python.org/file16856/test_inspect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8363>
_______________________________________

From report at bugs.python.org  Sat Apr 10 15:15:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 13:15:42 +0000
Subject: [issue8364] Update site.setquit docstring
In-Reply-To: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>
Message-ID: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Hello

The docstring for site.setquit was not updated when  r42948 changed quit and exit from strings to callables. Attached patch fixes it.

By the way, is ?Library? the right component for docstring-related bugs or is it ?Documentation??

Regards

----------
components: Library (Lib)
messages: 102777
nosy: merwok
severity: normal
status: open
title: Update site.setquit docstring
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8364>
_______________________________________

From report at bugs.python.org  Sat Apr 10 15:26:37 2010
From: report at bugs.python.org (=?utf-8?b?2LnYqNiv2KfZhNmE2Ycg2LTZhNmKIChBYmRlbGxhaCBDaGVsbGkp?=)
Date: Sat, 10 Apr 2010 13:26:37 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270905997.55.0.741406429122.issue8359@psf.upfronthosting.co.za>


??????? ??? (Abdellah Chelli) <sneetsher at gmail.com> added the comment:

The full example:
===
import gettext

gettext.bindtextdomain("pygettext_test","./locale")
gettext.textdomain("pygettext_test")
_=gettext.gettext
n_=gettext.ngettext

n1=1
n2=3

print n_("there is %i command","there are %i commands",n1) % n1
print n_("there is %i command","there are %i commands",n2) % n2
===

the result of n_("there is %i command","there are %i commands",n2) will be:

"there is %i command"
or
"there are %i commands"
or
different string from translation file in case of other language then English as in Arabic we have 6 forms, 3 of them don't include %i.

"?? ???? ?? ???"
"???? ??? ????"
"???? ?????"
"???? %i ?????"
"???? %i ????"
"???? %i ???"

(You may not see the Arabic well aligned because it's a RTL language).

So format string is open to fit all languages.
That's why mapping good only for predefined strings.

Then these will be our solution:
===
print n_("there is {0} command","there are {0} commands",n1).format(n1)
print n_("there is {0} command","there are {0} commands",n2).format(n2)
===

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Sat Apr 10 16:03:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Apr 2010 14:03:49 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1270908229.08.0.464803704149.issue8362@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I didn't put maintainers.rst into 2.6 because I didn't want to commit to maintaining the two divergent copies.  If you want to commit to maintaining it in the 2.x branch (copying changes backwards from the 3.x branch), then I'd be +0 (or maybe even +0.5) on adding it there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Sat Apr 10 16:13:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 14:13:06 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270908229.08.0.464803704149.issue8362@psf.upfronthosting.co.za>
Message-ID: <4BC0876E.4010204@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Module names have to be converted only once, so now maintenance is just 
keeping names updated. I?m willing to commit to maintaining the 
maintainers file <0.2 meta wink> with one caveat: Core developers can 
commit and merge immediately, keeping branches in sync, whereas I don?t 
update my copies of trunk and py3k every day. If some lag up to one week 
is acceptable, then I?d be happy to maintain the file.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Sat Apr 10 16:32:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Apr 2010 14:32:18 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1270909938.65.0.598791044418.issue8362@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Sat Apr 10 16:46:08 2010
From: report at bugs.python.org (Oliver Martin)
Date: Sat, 10 Apr 2010 14:46:08 +0000
Subject: [issue1079] decode_header does not follow RFC 2047
In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za>
Message-ID: <1270910768.58.0.922209662022.issue1079@psf.upfronthosting.co.za>


Oliver Martin <oliver at volatilevoid.net> added the comment:

I got bitten by this too. In addition to not decoding encoded words without whitespace after them, it throws an exception if there is a valid encoded word later in the string and the first encoded word is followed by something that isn't a hex number:

>>> decode_header('aaa=?iso-8859-1?q?bbb?=xxx asdf =?iso-8859-1?q?jkl?=')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/email/header.py", line 93, in decode_header
    dec = email.quoprimime.header_decode(encoded)
  File "/usr/lib/python2.5/email/quoprimime.py", line 336, in header_decode
    return re.sub(r'=\w{2}', _unquote_match, s)
  File "/usr/lib/python2.5/re.py", line 150, in sub
    return _compile(pattern, 0).sub(repl, string, count)
  File "/usr/lib/python2.5/email/quoprimime.py", line 324, in _unquote_match
    return unquote(s)
  File "/usr/lib/python2.5/email/quoprimime.py", line 106, in unquote
    return chr(int(s[1:3], 16))
ValueError: invalid literal for int() with base 16: 'xx'

I think it should join the encoded words with the surrounding text if there's no whitespace in between. That seems to be consistent with what the non-RFC-compliant MUAs out there mean when they send such things.

Reverting the change from Issue 1582282 doesn't seem to be a good idea, since it was introduced in response to problems with mailman (see https://bugs.launchpad.net/mailman/+bug/266370). Instead of leaving "Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord" as it is, my patch converts it to [('Sm\xf6rg\xe5sbord', 'iso-8859-1')]. This shouldn't reintroduce the problem mailman was having while fixing ours.

----------
nosy: +leromarinvit
Added file: http://bugs.python.org/file16857/rfc2047_embed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1079>
_______________________________________

From report at bugs.python.org  Sat Apr 10 16:51:57 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 10 Apr 2010 14:51:57 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270852621.17.0.261570113194.issue8322@psf.upfronthosting.co.za>
Message-ID: <4BC09088.1070704@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Antoine Pitrou wrote:
>
> Antoine Pitrou<pitrou at free.fr>  added the comment:
>
> After some investigation, the error does occur because of the aforementioned changelog entry (SSLv2 weak ciphers are now disabled by default). To check it I just added the following line to newPySSLObject():
>
>       SSL_CTX_set_cipher_list(self->ctx, "ALL");
>
> Of course this isn't desirable: we shouldn't blindly enable weak ciphers. Instead we could simply add an argument to configure allowed ciphers, and use "ALL" in our tests. Or we could add a separate method to configure ciphers.
>
> (this begs the question of whether this is suitable post-beta1)
>
> What do you think?

List of ciphers is application dependent and configure script can't 
limit users(applications) .

Roumen

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Sat Apr 10 16:53:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Apr 2010 14:53:56 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <4BC09088.1070704@roumenpetrov.info>
Message-ID: <1270911356.3433.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> List of ciphers is application dependent and configure script can't 
> limit users(applications) .

I was obviously talking about a runtime argument to ssl.wrap_socket().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Sat Apr 10 18:07:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Apr 2010 16:07:42 +0000
Subject: [issue8363] Lots of duplicate code between test_classify_oldstyle and
	test_classify_newstyle in test_inspect.py
In-Reply-To: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>
Message-ID: <1270915662.35.0.712994368162.issue8363@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think the patch is ok except for that docstrings should start on the same line as the triple quote.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8363>
_______________________________________

From report at bugs.python.org  Sat Apr 10 18:12:55 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 10 Apr 2010 16:12:55 +0000
Subject: [issue8363] Lots of duplicate code between test_classify_oldstyle and
	test_classify_newstyle in test_inspect.py
In-Reply-To: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>
Message-ID: <1270915975.79.0.152890979952.issue8363@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Okay.

I shouldn't commit until after trunk is unfrozen though, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8363>
_______________________________________

From report at bugs.python.org  Sat Apr 10 18:18:31 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Apr 2010 16:18:31 +0000
Subject: [issue8363] Lots of duplicate code between test_classify_oldstyle and
	test_classify_newstyle in test_inspect.py
In-Reply-To: <1270915975.79.0.152890979952.issue8363@psf.upfronthosting.co.za>
Message-ID: <j2y1afaf6161004100918hb0db1a35tea078c13922611d8@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/4/10 Jean-Paul Calderone <report at bugs.python.org>:
>
> Jean-Paul Calderone <exarkun at divmod.com> added the comment:
>
> Okay.
>
> I shouldn't commit until after trunk is unfrozen though, right?

Correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8363>
_______________________________________

From report at bugs.python.org  Sat Apr 10 18:29:06 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Apr 2010 16:29:06 +0000
Subject: [issue8361] Remove assert in functools.total_ordering
In-Reply-To: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>
Message-ID: <1270916946.13.0.685261185568.issue8361@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8361>
_______________________________________

From report at bugs.python.org  Sat Apr 10 18:44:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Apr 2010 16:44:40 +0000
Subject: [issue8361] Remove assert in functools.total_ordering
In-Reply-To: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>
Message-ID: <1270917880.56.0.192154563816.issue8361@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The max(roots) line that follows will raise its own ValueError when given an empty input.   Will mull over your patch.  I may just delete the assert line, leave it as-is, or apply something like your patch (but with a ValueError).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8361>
_______________________________________

From report at bugs.python.org  Sat Apr 10 18:57:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 16:57:08 +0000
Subject: [issue8361] Remove assert in functools.total_ordering
In-Reply-To: <1270917880.56.0.192154563816.issue8361@psf.upfronthosting.co.za>
Message-ID: <4BC0ADE0.8020501@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Ok. It won?t have a user-friendly error message, though.

You may be interested in a minor doc patch in #5341.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8361>
_______________________________________

From report at bugs.python.org  Sat Apr 10 19:01:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Apr 2010 17:01:05 +0000
Subject: [issue8361] Remove assert in functools.total_ordering
In-Reply-To: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>
Message-ID: <1270918865.75.0.961681479388.issue8361@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r79930 and r79931

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8361>
_______________________________________

From report at bugs.python.org  Sat Apr 10 20:54:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Apr 2010 18:54:40 +0000
Subject: [issue8361] Remove assert in functools.total_ordering
In-Reply-To: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>
Message-ID: <1270925680.55.0.891611798952.issue8361@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8361>
_______________________________________

From report at bugs.python.org  Sat Apr 10 21:05:28 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 10 Apr 2010 19:05:28 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1270926328.07.0.630994176901.issue7355@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> I'm half-convinced that struct.pack *should* ideally add trailing 
> padding in the same situation that C does, for consistency with C.  
> Then calcsize would match C's sizeof.

Maybe...  AFAIK, the C language does not mandate structure padding.
Section 6.7.2.1 of the C99 standard says that "unnamed padding" may be inserted anywhere inside of a structure object *except* at the beginning.  In other words, padding between members and trailing  padding is very implementation specific.  

When and why things are padded usually depends on the compiler, OS, and computer architecture.  For example, padding between members is usually
just an optimization for architectures like x86, but on architectures like ARM and MIPS you may end up with alignment faults.  Moreover, I 
think trailing padding is typically added to maintain alignment for 
arrays of structures, which again may be an optimization or correctness issue depending on the architecture.

So, I don't think we can match what C does since C leaves it open.
Perhaps we could match the C implementation that compiles the 'struct'
module, though?  Maybe there is a way we can compute the trailing padding in a fashion similar to how alignment is computed for various
types in the '*_ALIGN' macros in '_struct.c'?

Another thing that came to mind when thinking about structure layout issues was whether it might be useful to provide "packed" structures, e.g. no padding.  If the goal is to provide a way to read\write C-compatible structs, then currently there is no easy way to handle structures that have been serialized after being compiled with something like GCC's '-fpack-struct' option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Sat Apr 10 21:28:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Apr 2010 19:28:20 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1270927700.31.0.475865209421.issue3928@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Apr 10 21:29:55 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Apr 2010 19:29:55 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1270927795.09.0.843283211784.issue7723@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sat Apr 10 22:03:52 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 10 Apr 2010 20:03:52 +0000
Subject: [issue8363] Lots of duplicate code between test_classify_oldstyle and
	test_classify_newstyle in test_inspect.py
In-Reply-To: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>
Message-ID: <1270929832.48.0.683690347617.issue8363@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Committed in r79935

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8363>
_______________________________________

From report at bugs.python.org  Sat Apr 10 22:26:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Apr 2010 20:26:43 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1270931203.74.0.614232146661.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> When and why things are padded usually depends on the compiler, OS,
> and computer architecture. [...]

Sure.  The struct module has a rather simplistic set of rules for adding padding, but I believe that it manages to match the platform's C rules (assuming no relevant extra compile flags) in most cases.

If we wanted something that's *guaranteed* to match C then I agree that's probably not easy within the struct module itself;  it probably belongs in ctypes somewhere instead.

For trailing padding, one fairly obvious and simple rule to use (to match the simplicity of the current rules for padding) would be to add enough padding so that the alignment of the struct matches the largest alignment of any member of the struct.  So e.g. on a platform where doubles are aligned to 8 bytes and ints to 4 bytes, 'db' would have 7 bytes of trailing padding, while 'iib' would have 3 bytes.  'b' would have no trailing padding at all.  I *think* (but would have to check) that this again matches what happens on common platforms.

> Another thing that came to mind when thinking about structure layout
> issues was whether it might be useful to provide "packed" structures

These already exist, provided that you're willing to accept 'standard' rather than 'native' sizes.  The struct modes for '<', '>', '=' and '!' never introduce padding (unless it's explicitly asked for with 'x').

---

On the subject of documentation, I think there are two points that need to be made more clearly in the current docs:

(1) *By default* (i.e. without a '<', '>', ...), padding *is* used;  but is automatically turned off with '<', '>', '=', '!'.  Ideally this should be mentioned very early on, since it seems to trip up a lot of people.

(2) Padding is only added between successive struct members; there's no trailing padding.  But padding can be forced using Eric's trick (though you end up having to choose exactly what alignment you want, e.g. by specifying '0i' rather than '0q' or '0d').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Sat Apr 10 23:21:10 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 10 Apr 2010 21:21:10 +0000
Subject: [issue8364] Update site.setquit docstring
In-Reply-To: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>
Message-ID: <1270934470.61.0.869466417502.issue8364@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

merwok I think you forgot to attach patch

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8364>
_______________________________________

From report at bugs.python.org  Sat Apr 10 23:23:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 21:23:39 +0000
Subject: [issue8364] Update site.setquit docstring
In-Reply-To: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>
Message-ID: <1270934619.6.0.76606643129.issue8364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hey, I do that all the time with email attachments! (They made a Thunderbird? extension for that.)

Thanks ;)

----------
keywords: +patch
Added file: http://bugs.python.org/file16858/quit-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8364>
_______________________________________

From report at bugs.python.org  Sat Apr 10 23:35:29 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 10 Apr 2010 21:35:29 +0000
Subject: [issue8364] Update site.setquit docstring
In-Reply-To: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>
Message-ID: <1270935329.94.0.706349349927.issue8364@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

looks fine to me. However I heard trunk will be/is frozen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8364>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:01:40 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 10 Apr 2010 22:01:40 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1270936900.12.0.73559169816.issue8340@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

On a related note, the documentation of 'bytes' is not backported too.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:03:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Apr 2010 22:03:52 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1270937032.47.0.858467085674.issue5380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It turns out isatty() returns True for fds created by openpty(), which helps quite a bit: we can silence EIO for ttys while keeping it for non-ttys, where a low-level I/O (hardware) error should be raised properly.
Here is a patch for trunk.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16859/io-openpty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:08:24 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 10 Apr 2010 22:08:24 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1270937304.12.0.717672732214.issue8340@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Attached a patch to backport the 'bytearray' and 'bytes' documentation in trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file16860/functions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:10:25 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 10 Apr 2010 22:10:25 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1270937425.03.0.0718068022846.issue2876@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
components: +2to3 (2.x to 3.0 conversion tool) -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:10:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 22:10:34 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1270937434.36.0.140102808152.issue8340@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> * If it is a *string*, you must also give the *encoding* (and optionally,
> *errors*) parameters; :func:`bytearray` then converts the string to
>     bytes using :meth:`str.encode`.

I think this needs some lines to tell how it behaves with str and unicode.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:12:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 10 Apr 2010 22:12:14 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1270937534.39.0.254848314067.issue4662@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
components: +2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4662>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:16:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 10 Apr 2010 22:16:06 +0000
Subject: [issue6409] 2to3 -j 4 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1270937766.79.0.409198013623.issue6409@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
components: +2to3 (2.x to 3.0 conversion tool) -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:17:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Apr 2010 22:17:39 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1270937859.73.0.322898031592.issue5380@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16859/io-openpty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:17:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Apr 2010 22:17:47 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1270937867.47.0.633187745743.issue5380@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file16861/io-openpty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:46:41 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sat, 10 Apr 2010 22:46:41 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1270939601.06.0.773750179903.issue7723@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

I see that the status of this issue keeps changing.

Now does anything in the sqlite3 module or the docs need to be changed?

Or what's left to close this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sun Apr 11 00:48:19 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 10 Apr 2010 22:48:19 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1270939699.19.0.615943659375.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Patch update: added unit test to cover replacing __import__, incorporated R. David Murray's suggestion to use test_support.test_cwd(), and overall code clean-up.

Also uploaded as Patch 3 to--

http://codereview.appspot.com/810044/show

----------
Added file: http://bugs.python.org/file16862/_patch-7559-6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Sun Apr 11 02:03:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 00:03:10 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1270944190.98.0.0289788373674.issue7946@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Apr 11 02:44:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 00:44:04 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1270937032.47.0.858467085674.issue5380@psf.upfronthosting.co.za>
Message-ID: <1270946764.3433.27.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

After triggering the buildbots, it seems that reading from the master fd
after the slave fd has been closed is rather OS-dependent. The FreeBSDs
return an empty string. I wonder whether this use case (reading from the
master after the slave is closed) should really be supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sun Apr 11 02:55:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 00:55:23 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1270947323.29.0.699191945211.issue5380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Regardless of the decision, a new patch.

----------
Added file: http://bugs.python.org/file16863/io-openpty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sun Apr 11 02:55:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 00:55:42 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1270947342.9.0.275593919639.issue5380@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16861/io-openpty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sun Apr 11 03:15:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 01:15:01 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1270948501.43.0.728019274538.issue5380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Worse, the test timed out (probably froze) on the Solaris buildbot:
http://www.python.org/dev/buildbot/trunk/builders/sparc%20solaris10%20gcc%20trunk/builds/649/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sun Apr 11 03:41:20 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Apr 2010 01:41:20 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1270950080.47.0.774885884166.issue7355@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> would be to add enough padding so that the alignment of the struct 
> matches the largest alignment of any member of the struct. 

That might work.  I will have to think about it a bit.

> On the subject of documentation

Attached a doc patch which addresses Mark's two points plus the following:

(1) Organized things more clearly into sub-sections.
(2) Fixed up the "notes" column from the '__index__' change that
    was submitted last week.
(3) Added some examples.

----------
keywords: +patch
Added file: http://bugs.python.org/file16864/issue-7355.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Sun Apr 11 03:54:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Apr 2010 01:54:42 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1270950882.15.0.947084337047.issue7621@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Some more testing:
<http://psf.upfronthosting.co.za/roundup/meta/issue254>
[http://psf.upfronthosting.co.za/roundup/meta/issue254]
(http://psf.upfronthosting.co.za/roundup/meta/issue254)
{http://psf.upfronthosting.co.za/roundup/meta/issue254}
http://psf.upfronthosting.co.za/roundup/meta/issue254.
http://psf.upfronthosting.co.za/roundup/meta/issue254,
http://psf.upfronthosting.co.za/roundup/meta/issue254;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7621>
_______________________________________

From report at bugs.python.org  Sun Apr 11 04:21:19 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 02:21:19 +0000
Subject: [issue8365] 'readline' module fails to build on OS X - some recent
	change broke it
In-Reply-To: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>
Message-ID: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

'readline' module fails to build on OS X  in case of trunk and python 3.x. It have no issues with python 2.5 and 2.6 and python 2.7 alpha.

Here is the trace after running ./configure; make in trunk

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 gdbm            
imageop            linuxaudiodev      ossaudiodev     
readline           spwd               sunaudiodev  

With that the uparrow-downarrow and other features fails which I suppose depends on 'readline'

07:31:51 l0nwlf-MBP:python-svn $ ./python.exe 
Python 2.7b1+ (trunk:79945M, Apr 11 2010, 07:14:54) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> t = 'test'      
>>> ^[[A^[[A^[[B^[[B

07:32:53 l0nwlf-MBP:CoreHD $ python3.2
Python 3.2a0 (py3k:79532, Apr  1 2010, 01:48:52) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named readline
>>> t = 'test'
>>> ^[[A^[[A

(pressing up-arrow for repeating the previous command fails)

However, an interesting observation is, 

07:34:00 l0nwlf-MBP:CoreHD $ 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 readline
>>> t = 'test'
>>> t = 'test'
 
No such issue here, 'uparrow' is working, thereby completing the previous command on interpretor. The version is python2.7 alpha as you can see. So I assume some recent changes broke something, it was fine earlier.

----------
components: Build
messages: 102807
nosy: l0nwlf, ronaldoussoren
severity: normal
status: open
title: 'readline' module fails to build on OS X - some recent change broke it
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8365>
_______________________________________

From report at bugs.python.org  Sun Apr 11 04:57:38 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 02:57:38 +0000
Subject: [issue8365] 'readline' module fails to build on OS X - some recent
	change broke it
In-Reply-To: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>
Message-ID: <1270954658.56.0.775176896195.issue8365@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

After I recompiled my older revision the 'readline' module failed to build. So I guess this is not python-related issue, rather something to do with my system.

08:17:47 l0nwlf-MBP:python-svn(rev79372) $ ./python.exe -V
Python 2.7a4+
08:17:53 l0nwlf-MBP:python-svn(rev79372) $ ./python.exe 
Python 2.7a4+ (trunk:79372, Apr 11 2010, 08:15:12) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named readline

I will try looking for the cause behind it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8365>
_______________________________________

From report at bugs.python.org  Sun Apr 11 06:29:20 2010
From: report at bugs.python.org (Gombiuda Jiang)
Date: Sun, 11 Apr 2010 04:29:20 +0000
Subject: [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: <1270960160.43.0.221320718323.issue8241@psf.upfronthosting.co.za>


Gombiuda Jiang <gombiuda at gmail.com> added the comment:

I have upload a patch for this problem by just removing the lines as Gabriel said.

Please check it out. Thanks.

----------
keywords: +patch
nosy: +gombiuda
Added file: http://bugs.python.org/file16865/py2_test_grammar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8241>
_______________________________________

From report at bugs.python.org  Sun Apr 11 08:46:40 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 06:46:40 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Prior to r79392 (trunk) and r79401 (py3k), the changes introduced for Issue8211, the gcc lines produced for an OS X universal build, say

./configure --enable-universalsdk --with-universal-archs=32-bit ; make

might look like this:

gcc-4.0 -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic -DNDEBUG -g -O3 -I/tmp/_py/libraries/usr/local/include  -I. -IInclude -I/private/tmp/_t/Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPy_BUILD_CORE -o Modules/python.o /private/tmp/_t/Modules/python.c

With the changes introduced by r79392 and r79401 to save and restore the original value of CFLAGS across the AC_PROG_CC macro call (see trunk configure.in at about line 496), the same gcc call now looks like this:

gcc-4.0 -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DNDEBUG -g -O3 -I/tmp/_py/libraries/usr/local/include  -I. -IInclude -I/private/tmp/_t/Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPy_BUILD_CORE -o Modules/python.o /private/tmp/_t/Modules/python.c

Note that there are now two sets of -arch and -sysroot flags because the CFLAGS ones were being lost before but are now preserved.  While the duplicate flags do not seem to bother gcc and friends, the code in sysconfig.py to determine the machine name for OS X is not prepared to handle them and the build fails when the interpreter starts up:

Traceback (most recent call last):
  File "/private/tmp/_t/Lib/site.py", line 542, in <module>
    main()
  File "/private/tmp/_t/Lib/site.py", line 521, in main
    addbuilddir()
  File "/private/tmp/_t/Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/private/tmp/_t/Lib/sysconfig.py", line 646, in get_platform
    "Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1

----------
assignee: ronaldoussoren
components: Macintosh
messages: 102810
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X universal builds fail on 2.7b1 and py3k with "Don't know machine value for archs"
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 08:48:28 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 06:48:28 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1270968508.28.0.603917249959.issue8211@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note these changes to restore CFLAGS have the side effect of breaking OS X universal builds; see Issue8366.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Sun Apr 11 09:09:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 07:09:37 +0000
Subject: [issue8365] 'readline' module fails to build on OS X - some recent
	change broke it
In-Reply-To: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>
Message-ID: <1270969777.97.0.820822320185.issue8365@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Issue6877 (and subsequent fixes in Issue8066) allows the Python readline module to be built and linked with the OS X editline (libedit) library rather than with the GNU readline library (which is not included with OS X).  However, the libedit included in versions of OS X prior to 10.5 is considered too broken to use here.

By default, if you do not specify an --with-universal-archs other than "32-bit" to configure or if you do not explicitly set MACOSX_DEPLOYMENT_TARGET to another value, configure defaults to using "10.4" (or earlier) so the building of the readline module is skipped.  You can check this:

>>> from distutils.sysconfig import get_config_var 
>>> get_config_var('MACOSX_DEPLOYMENT_TARGET')
'10.4'

(Whether this is the best default is another question.)

As it stands, to be able to build the readline module, either:

(1) supply the GNU readline library as a local library, or

(2) ensure you are building with a deployment target of at least 10.5.  For example:

    ./configure MACOSX_DEPLOYMENT_TARGET=10.6 ; make

Also note that option (2) is not available for 3.1.x since the changes to support editline/libedit were not ported to it; they are, however, in 2.6.5, 2.7 (trunk), and 3.2 (py3k).

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8365>
_______________________________________

From report at bugs.python.org  Sun Apr 11 09:50:23 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 07:50:23 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270972223.58.0.43555296726.issue8366@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I tried to reproduce it on trunk by trying,
./configure --enable-universalsdk --with-universal-archs=32-bit ; make
However It did managed to build successfully.

The relevant bits during installation:

gcc -c -arch ppc -arch i386 -isysroot /   -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c

<snip>

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           gdbm               linuxaudiodev   
ossaudiodev        readline           spwd            
sunaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Failed to build these modules:
_bsddb             _locale                            

running build_scripts
<trim>
/usr/bin/install -c -m 644 ./Tools/gdb/libpython.py python.exe-gdb.py

12:52:55 l0nwlf-MBP:python-svn $ ./python.exe 
Python 2.7b1+ (trunk:79945M, Apr 11 2010, 12:46:28) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 10:21:03 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 08:21:03 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270974063.35.0.799878286749.issue8366@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fails for me with py3k, trunk, and with the 2.7.b1 tarball on 10.6.3 (Intel) and 10.5.8 (ppc).

Your test output looks suspect; with the given configure values, the use of gcc-4.0 should be forced.  Perhaps you used an existing build directory but did not do a make clobber and/or not rm the previous cached configure values?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 10:25:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 08:25:04 +0000
Subject: [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: <1270974304.83.0.705286050307.issue8241@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Benjamin, ISTM that the tests in lib2to3/tests/data/py2_test_grammar aren't run at all, as part of regrtest. If so, the entire file could be removed.

----------
components: +Installation -2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8241>
_______________________________________

From report at bugs.python.org  Sun Apr 11 10:32:55 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 08:32:55 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270974775.9.0.402251557812.issue8366@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I reinstalled with :
make distclean; ./configure --enable-universalsdk --with-universal-archs=32-bit; make
on 10.6.2 (Intel) Which I guess is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 11:06:26 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 09:06:26 +0000
Subject: [issue8365] 'readline' module fails to build on OS X - some recent
	change broke it
In-Reply-To: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>
Message-ID: <1270976786.08.0.521505791344.issue8365@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

./configure MACOSX_DEPLOYMENT_TARGET=10.6 ; make does the trick.
However it should be done by default rather than being defined explicitly.
Closing the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8365>
_______________________________________

From report at bugs.python.org  Sun Apr 11 11:06:47 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 09:06:47 +0000
Subject: [issue8365] 'readline' module fails to build on OS X - some recent
	change broke it
In-Reply-To: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>
Message-ID: <1270976807.45.0.807910270855.issue8365@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8365>
_______________________________________

From report at bugs.python.org  Sun Apr 11 11:16:39 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Apr 2010 09:16:39 +0000
Subject: [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1270977399.55.0.848823943112.issue8093@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

For the record:

In 2.7-alpha you do not even get to press [Restart Shell], since IDLE is
not responding during the calculation.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8093>
_______________________________________

From report at bugs.python.org  Sun Apr 11 11:18:21 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 09:18:21 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270977501.88.0.0761458252675.issue8366@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Chances are you do not have the 10.4u SDK installed; it is not installed by default by the Snow Leopard Xcode mpkg installer.  If it is not installed, configure falls back to using / as the sysroot (see configure.in at around line 95).  If you are going to build and test Python on OS X 10.5 or 10.6, you really need to have it installed.

$ ls /Developer/SDKs/
MacOSX10.4u.sdk/ MacOSX10.5.sdk/  MacOSX10.6.sdk/

Even without 10.4u installed, this should fail:

make distclean; ./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk --with-universal-archs=32-bit MACOSX_DEPLOYMENT_TARGET=10.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 11:49:10 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 09:49:10 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270979350.04.0.398876823394.issue8366@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

The error was finally reproduced with :
$make distclean; ./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk --with-universal-archs=32-bit MACOSX_DEPLOYMENT_TARGET=10.6; make 

gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk  -u _PyMac_Error -o python.exe \
			Modules/python.o \
			libpython2.7.a -ldl  -framework CoreFoundation     
Traceback (most recent call last):
  File "/Volumes/CoreHD/python-svn/Lib/site.py", line 544, in <module>
    main()
  File "/Volumes/CoreHD/python-svn/Lib/site.py", line 523, in main
    addbuilddir()
  File "/Volumes/CoreHD/python-svn/Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/Volumes/CoreHD/python-svn/Lib/sysconfig.py", line 646, in get_platform
    "Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1

Also,
$ ls /Developer/SDKs/
MacOSX10.5.sdk MacOSX10.6.sdk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 12:07:50 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Apr 2010 10:07:50 +0000
Subject: [issue8367] test_winsound: failure on systems without soundcard
In-Reply-To: <1270980470.8.0.919577975963.issue8367@psf.upfronthosting.co.za>
Message-ID: <1270980470.8.0.919577975963.issue8367@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Got this test failure on Windows/qemu:

======================================================================
FAIL: test_stopasync (__main__.PlaySoundTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_winsound.py", line 199, in test_stopasync
    None, winsound.SND_PURGE
AssertionError: RuntimeError not raised


The problem is that PlaySound(None, winsound.SND_PURGE) does not
raise on systems without a soundcard. The wrapped C function returns
success in this case, so I think it's ok to go along with it and
disable this assertion.

----------
messages: 102821
nosy: skrah
severity: normal
status: open
title: test_winsound: failure on systems without soundcard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8367>
_______________________________________

From report at bugs.python.org  Sun Apr 11 12:35:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Apr 2010 10:35:16 +0000
Subject: [issue8367] test_winsound: failure on systems without soundcard
In-Reply-To: <1270980470.8.0.919577975963.issue8367@psf.upfronthosting.co.za>
Message-ID: <1270982116.77.0.0139772240221.issue8367@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Searching for the failure reveals that sporadically this has appeared on the buildbots, so I plan to apply the patch soon if there aren't any
protests.

----------
assignee:  -> skrah
components: +Tests
keywords: +patch
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16866/test_winsound.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8367>
_______________________________________

From report at bugs.python.org  Sun Apr 11 13:09:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Apr 2010 11:09:06 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270984146.83.0.532372545466.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I looked at ccbench.  It's a great tool.  I've added two features to it (see the attached patch)
-y option to turn off the "do_yield" option in throughput, and so measure thread scheduling without assistance, and the throughput option now also computes "balance", which is the standard deviation of the throughput of each thread normalized by the average.

I give you three results for throughput, to demonstrate the ROUNDROBIN_GIL implementation:
1) LEGACY_GIL, no forced switching
C:\pydev\python\trunk\PCbuild>python.exe ..\Tools\ccbench\ccbench.py -y -t
== CPython 2.7a4+.0 (trunk) ==
== AMD64 Windows on 'Intel64 Family 6 Model 23 Stepping 6, GenuineIntel' ==

--- Throughput ---

Pi calculation (Python)

threads= 1:   672 iterations/s. balance
threads= 2:   597 ( 88%)        0.4243
threads= 3:   603 ( 89%)        0.2475
threads= 4:   596 ( 88%)        0.4776

regular expression (C)

threads= 1:   571 iterations/s. balance
threads= 2:   565 ( 98%)        0.6203
threads= 3:   567 ( 99%)        1.6867
threads= 4:   570 ( 99%)        1.1670

SHA1 hashing (C)

threads= 1:  1269 iterations/s. balance
threads= 2:  1268 ( 99%)        1.1470
threads= 3:  1270 (100%)        0.6024
threads= 4:  1263 ( 99%)        0.7419

LEGACY_GIL, with forced switching
C:\pydev\python\trunk\PCbuild>python.exe ..\Tools\ccbench\ccbench.py -t
== CPython 2.7a4+.0 (trunk) ==
== AMD64 Windows on 'Intel64 Family 6 Model 23 Stepping 6, GenuineIntel' ==

--- Throughput ---

Pi calculation (Python)

threads= 1:   663 iterations/s. balance
threads= 2:   605 ( 91%)        0.0232
threads= 3:   599 ( 90%)        0.1988
threads= 4:   601 ( 90%)        0.4648

regular expression (C)

threads= 1:   568 iterations/s. balance
threads= 2:   562 ( 99%)        0.1737
threads= 3:   571 (100%)        0.3950
threads= 4:   566 ( 99%)        0.3158

SHA1 hashing (C)

threads= 1:  1275 iterations/s. balance
threads= 2:  1267 ( 99%)        0.7238
threads= 3:  1271 ( 99%)        0.2405
threads= 4:  1270 ( 99%)        0.1508

Using the forced "do_yield" helps balance things, but not much.  We still have a .7 balance in SHA1 hashing for two threads.

Now, for ROUNDROBIN_GIL, and no forced switching:
C:\pydev\python\trunk\PCbuild>python.exe ..\Tools\ccbench\ccbench.py -t -y
== CPython 2.7a4+.0 (trunk) ==
== AMD64 Windows on 'Intel64 Family 6 Model 23 Stepping 6, GenuineIntel' ==

--- Throughput ---

Pi calculation (Python)

threads= 1:   672 iterations/s. balance
threads= 2:   485 ( 72%)        0.0289
threads= 3:   448 ( 66%)        0.0737
threads= 4:   476 ( 70%)        0.0408

regular expression (C)

threads= 1:   569 iterations/s. balance
threads= 2:   551 ( 96%)        0.0505
threads= 3:   551 ( 96%)        0.1637
threads= 4:   551 ( 96%)        0.2020

SHA1 hashing (C)

threads= 1:  1271 iterations/s. balance
threads= 2:  1262 ( 99%)        0.0111
threads= 3:  1207 ( 94%)        0.0143
threads= 4:  1202 ( 94%)        0.0317

Notice the much better balance value, and this is without the forced sleep.
Also note a lower througput when computing pi with threads.  This is because yielding every 100 opcodes now actually works, and the aforementioned instruction cache problem kicks in.  Increasing the checkinterval to 1000 solves this:
C:\pydev\python\trunk\PCbuild>python.exe ..\Tools\ccbench\ccbench.py -t -y -i100
0
== CPython 2.7a4+.0 (trunk) ==
== AMD64 Windows on 'Intel64 Family 6 Model 23 Stepping 6, GenuineIntel' ==

--- Throughput ---

Pi calculation (Python)

threads= 1:   673 iterations/s. balance
threads= 2:   628 ( 93%)        0.0000
threads= 3:   603 ( 89%)        0.0284
threads= 4:   606 ( 90%)        0.0328

regular expression (C)

threads= 1:   570 iterations/s. balance
threads= 2:   569 ( 99%)        0.2729
threads= 3:   562 ( 98%)        0.6595
threads= 4:   560 ( 98%)        1.2440

SHA1 hashing (C)

threads= 1:  1265 iterations/s. balance
threads= 2:  1256 ( 99%)        0.0000
threads= 3:  1264 ( 99%)        0.0759
threads= 4:  1255 ( 99%)        0.1309

If no one objects, I'd like to submit this changed ccbench.py to the trunk.

----------
Added file: http://bugs.python.org/file16867/ccbench.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:10:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 12:10:35 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
	output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1270987835.25.0.644309393491.issue6860@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Distutils being frozen, I?m reassigning to Distutils2. Not sure if I should make versions blank, 3.3 or third-party, so leaving it alone.

Regards

----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:15:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 12:15:12 +0000
Subject: [issue6650] sre_parse contains a confusing generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1270988112.1.0.930181161459.issue6650@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In the absence of better propositions, the message in the patch seems more helpful to me than the previous, especially because ?lookbehind? is a search term that matches <0.1 wink> on docs.python.org. So I?d apply this patch.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:19:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 12:19:40 +0000
Subject: [issue6555] distutils config file should have the same name on both
	platforms and all scopes
In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
Message-ID: <1270988380.56.0.247124662697.issue6555@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me add that os.path.expanduser is the Right Way? to get a user?s home directory on POSIX too, since not every setup has a $HOME envvar or a /etc/passwd file. The only interface one should use is the pwd module (or  getent in shell scripts), and so does os.path.expanduser.

Reassigning to Distutils2.

Regards

----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6555>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:21:18 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Apr 2010 12:21:18 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270988478.36.0.584274975502.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Fyi, here is the output using the unmodified Windows GIL, i.e. without my patch being active:
C:\pydev\python\trunk\PCbuild>python.exe ..\Tools\ccbench\ccbench.py -t -y
== CPython 2.7a4+.0 (trunk) ==
== AMD64 Windows on 'Intel64 Family 6 Model 23 Stepping 6, GenuineIntel' ==

--- Throughput ---

Pi calculation (Python)

threads= 1:   623 iterations/s. balance
threads= 2:   489 ( 78%)        0.0289
threads= 3:   461 ( 74%)        0.0369
threads= 4:   460 ( 73%)        0.0426

regular expression (C)

threads= 1:   515 iterations/s. balance
threads= 2:   548 (106%)        0.0771
threads= 3:   532 (103%)        0.0556
threads= 4:   523 (101%)        0.1132

SHA1 hashing (C)

threads= 1:  1188 iterations/s. balance
threads= 2:  1212 (102%)        0.0232
threads= 3:  1198 (100%)        0.0250
threads= 4:  1215 (102%)        0.0163

You see results virtually identical to the ROUNDROBIN_GIL implementation.  This is just do demonstrate that Windows has had the ROUNDROBIN_GIL behaviour all along.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:22:05 2010
From: report at bugs.python.org (David Beazley)
Date: Sun, 11 Apr 2010 12:22:05 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270988525.5.0.297197736712.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I must be missing something, but why, exactly would you want multiple CPU-bound threads to yield every 100 ticks?   Frankly, that sounds like a horrible idea that is going to hammer your system with excessive context switching overhead and cache performance problems---an effect that you, yourself have actually observed.   The results of ccbench also show worse performance for the round-robin GIL because of this.

Although the legacy GIL signals every 100  ticks, threads do not context switch that rapidly.  In fact, on single CPU systems, they context switch at about the same rate as the system time-slice (5-10 milliseconds on most systems).     The new GIL implemented by Antoine also does not rapidly switch CPU-bound threads.

Again, I must be missing something, but I don't see how this round-robin GIL and all of this forced thread switching is anything that you would ever want--especially for CPU-bound threads. It seems to go against just about every design goal that people usually have for schedulers (especially the goal of minimizing context switching overhead).

Again, maybe I'm just being dense and missing something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:32:13 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 11 Apr 2010 12:32:13 +0000
Subject: [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1270989133.66.0.0385762948572.issue5315@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I think two things can trigger this problem, both have to do with how signals are handled by the interpreter.
Contrarily to what you may think, when a signal is received, its handler is _not_ called. Instead, it's Modules/signalmodule.c signal_handler() that's called. This handler stores the reception of the signal inside a table, and schedules the execution of the associated handler for later:

signal_handler(int sig_num)
{
[...]
                Handlers[sig_num].tripped = 1;
                /* Set is_tripped after setting .tripped, as it gets
                   cleared in PyErr_CheckSignals() before .tripped. */
                is_tripped = 1;
                Py_AddPendingCall(checksignals_witharg, NULL);
[...]
}

checksignal_withargs() calls PyErr_CheckSignals(), which in turn calls the handler.
The pending calls are checked periodically from the interpreter main loop, in Python/ceval.c: when _Py_Ticker reaches 0, then we check for pending calls, and if there are any, we run the pending calls, hence checksignals_witharg, and the handler.
This is actually a documented behaviour, quoting signal documentation:
"Although Python signal handlers are called asynchronously as far as the Python user is concerned, they can only occur between the ?atomic? instructions of the Python interpreter. This means that signals arriving during long calculations implemented purely in C (such as regular expression matches on large bodies of text) may be delayed for an arbitrary amount of time."

But there's a race, imagine this happens:
- a thread (or a process for that matter) receives a signal
- signal_handler schedules the associated handler
- before _Py_Ticker reaches 0 and is checked from the interpreter main loop, a blocking call is made
- since the process is blocked in the call, the main eval loop doesn't run, and the handler doesn't get called until the process leaves the call and enters the main eval loop again. If the call doesn't return (e.g. select without timeout), then the process remains stuck forever.

This problem can also happen even if the signal is sent after select is called:
- the main thread calls select
- the second thread runs, and sends a signal to the process
- the signal is not received by the main thread, but by the second thread
- the second thread schedules execution of the handler
- since the main thread is blocked in select, the handler never gets called

But this case is quite flaky, because the documentation warns you:
"Some care must be taken if both signals and threads are used in the same program. The fundamental thing to remember in using signals and threads simultaneously is: always perform signal() operations in the main thread of execution. Any thread can perform an alarm(), getsignal(), pause(), setitimer() or getitimer(); only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). This means that signals can?t be used as a means of inter-thread communication. Use locks instead."

Sending signals to a process with multiple threads is risky, you should use locks.

Finally, I think that the documentation should be rephrased:
"and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads)."
It's false. What's guaranteed is that the signal handler will only be executed on behalf of the main thread, but any thread can _receive_ a signal.
And comments in Modules/signalmodule.c are misleading:
   We still have the problem that in some implementations signals
   generated by the keyboard (e.g. SIGINT) are delivered to all
   threads (e.g. SGI), while in others (e.g. Solaris) such signals are
   delivered to one random thread (an intermediate possibility would
   be to deliver it to the main thread -- POSIX?).  For now, we have
   a working implementation that works in all three cases -- the
   handler ignores signals if getpid() isn't the same as in the main
   thread.  XXX This is a hack.

Sounds strange. If only a thread other than the main thread receives the signal and you ignore it, then it's lost, isn't it ?
Furthermore, under Linux 2.6 and NPTL, getpid() returns the main thread PID even from another thread.

Peers ?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5315>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:33:50 2010
From: report at bugs.python.org (David Beazley)
Date: Sun, 11 Apr 2010 12:33:50 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270989230.29.0.642714608629.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Sorry, but I don't see how you can say that the round-robin GIL and the legacy GIL have the same behavior based solely on the result of a performance benchmark.   Do you have any kind of thread scheduling trace that proves they are scheduling threads in exactly the same manner?   Maybe they both have lousy performance, but for different reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 14:38:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 12:38:54 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270984146.83.0.532372545466.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270989655.3494.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> SHA1 hashing (C)
> 
> threads= 1:  1275 iterations/s. balance
> threads= 2:  1267 ( 99%)        0.7238
> threads= 3:  1271 ( 99%)        0.2405
> threads= 4:  1270 ( 99%)        0.1508
> 
> Using the forced "do_yield" helps balance things, but not much.  We
> still have a .7 balance in SHA1 hashing for two threads.

Which is not unreasonable, since SHA1 releases the GIL. The unbalance
would be produced by the Windows scheduler, not by Python.

Note: "do_yield" is not meant to "balance" things as much as to make
measurements meaningful at all. Without switching at all during say 2
seconds, the numbers become totally worthless.

> If no one objects, I'd like to submit this changed ccbench.py to the trunk.

Please let me take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 15:32:16 2010
From: report at bugs.python.org (Krauzi)
Date: Sun, 11 Apr 2010 13:32:16 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>


New submission from Krauzi <krauzi_gmbh at yahoo.de>:

Hi guys, i think this is a bug and Matt from help at python.org suggested me to report it here:
I attached a sample project where the memory leak occurs.I created a sample project where the memory leak occurs.
It's a visual studio 2008 project and uses windows threads so you have to recompile when using linux (makefile not included). 500 thread calls result in a memory leak of about 1 MB.

----------
files: Python Bug.zip
messages: 102832
nosy: Krauzi
severity: normal
status: open
title: Memory leak on multi-threaded PyObject_CallObject
versions: Python 2.6
Added file: http://bugs.python.org/file16868/Python Bug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:12:02 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 11 Apr 2010 14:12:02 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1270818334.21.0.114788890224.issue7443@psf.upfronthosting.co.za>
Message-ID: <4BC1D898.3030509@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I put together a trivial patch against the 2.7 trunk (basically: I added
a os.rename before the os.remove in test_support.unlink) and reran my
test harness with test_zipfile... and it still failed because, of course,
test_zipfile calls shutil.rmtree which bypasses the test_support.unlink
altogether etc. etc.

At this point several things occur to me:

1) There's little point in targetting the 2.x tree since 2.7 is due
out any time now and is effectively end-of-line for 2.x and this
isn't a release-blocker. Therefore whatever effort is brought to bear
should be against the 3.x latest

2) This is a repeatable but relatively minority case: it only applies
to Windows boxes and only to those where some behind-the-scenes process
is holding this kind of lock on files for long enough to affect the
tests. I'd certainly like to nail it but...

3) The amount of work -- and intrusion in the tests -- is quite substantial.
Just looking [*] for straight os.unlink instances, without even considering
shutil use gives 71 instances; os.remove gives another 90. That's even
without the issues of the tests for shutil and os in any case.

I'm willing to do the legwork of moving all the tests use, eg, support.unlink,
support.rmtree and so on, but quis custodiet? who'll test the tests?

grep "os\.unlink" *.py | wc -l
grep "os\.remove" *.py | wc -l

4) All that said, the result should be a cleaner, more controllable test environment,
at least for temp files. Another solution would be to rework the use of
TESTFN on Windows to use a new temporary file every time. But that would be as much
work and more than the unlink / rmtree work above.

I'd like to hear opinions before I move forward with a non-trivial patch
for this.

For the sake of completeness, I attach a tiny test case which shows that the
rename/remove approach should in fact work for the symptom we're seeing.

----------
Added file: http://bugs.python.org/file16869/test-case.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________
-------------- next part --------------
import os, sys
import traceback
import win32file

FILENAME = "test"

def rename_and_remove (filename):
   os.rename (filename, filename + ".deleted")
   os.remove (filename + ".deleted")

def remove_only (filename):
   os.remove (filename)

def test (remove):
   open (FILENAME, "w").close ()
   hFile = win32file.CreateFile (
     FILENAME,
     win32file.GENERIC_READ, win32file.FILE_SHARE_DELETE,
     None, win32file.OPEN_EXISTING, 0, 0
   )
   try:
     remove (FILENAME)
     try:
       open (FILENAME, "w").close ()
     except IOError:
       print "FAIL"
     else:
       print "PASS"
   finally:
     hFile.Close ()

   try:
     open (FILENAME, "w").close ()
   except IOError:
     print "FAIL"
   else:
     print "PASS"

if __name__ =='__main__':
   print
   print "Should see FAIL-PASS"
   test (remove_only)

   print
   print "Should see PASS-PASS"
   test (rename_and_remove)

From report at bugs.python.org  Sun Apr 11 16:17:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 14:17:06 +0000
Subject: [issue8369] Add a lint command to distutils
In-Reply-To: <1270995426.89.0.712440512698.issue8369@psf.upfronthosting.co.za>
Message-ID: <1270995426.89.0.712440512698.issue8369@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Add a command to run lint tools such as Python -3, pep8, pyflakes, pychecker, pylint.

I think this should not be a subcommand of test.

The idea comes from buildutils (http://pypi.python.org/pypi/buildutils/).

----------
assignee: tarek
components: Distutils2
messages: 102834
nosy: merwok, tarek
severity: normal
status: open
title: Add a lint command to distutils
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8369>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:18:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 14:18:22 +0000
Subject: [issue8369] Add a lint command to distutils
In-Reply-To: <1270995426.89.0.712440512698.issue8369@psf.upfronthosting.co.za>
Message-ID: <1270995502.59.0.812789104588.issue8369@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Also, think about running reindent.py and lib2to3 fixers such as idioms or ws_comma.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8369>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:20:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Apr 2010 14:20:03 +0000
Subject: [issue8241] py2_test_grammar.py contains invalid syntax for 2.6
In-Reply-To: <1270974304.83.0.705286050307.issue8241@psf.upfronthosting.co.za>
Message-ID: <i2g1afaf6161004110719v74b3d20aq30da389e8b5729d5@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/4/11 Martin v. L?wis <report at bugs.python.org>:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Benjamin, ISTM that the tests in lib2to3/tests/data/py2_test_grammar aren't run at all, as part of regrtest. If so, the entire file could be removed.

True, but then it would become out of sync with the other branches.
The tests aren't run in the trunk either, but we keep the file there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8241>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:24:52 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 11 Apr 2010 14:24:52 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1270995892.41.0.408226566261.issue7443@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

When I was working on a routine to checkout/patch/build/test/cleanup Python (see https://svn.jaraco.com/jaraco/python/jaraco.develop, and particularly scripts/test-windows-symlink-patch.py), I ran into a similar problem during the cleanup step. I tried using shutil.rmtree to clean up the folder that was checked out, but I repeatedly got 'access denied' exceptions.

I ended up working around the problem by using subprocess and cmd.exe's "rmdir /s /q".

I think this demonstrates three facets to this problem:

1) It doesn't just affect the test suite. It happens to other Python programs that are using shutil.rmtree (and possibly remove/unlink) to remove files that are in use.

2) It doesn't have to be that way. At the very least, there could (should?) be a function in Python that replicates 'rmdir /s /q', which is not subject to the 'access denied' error.

3) We could use subprocess and cmd.exe to perform the unlink and rmtree operations in the test suite to bypass the transient failures until Python supports the behavior natively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:46:27 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Apr 2010 14:46:27 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270997187.54.0.0415144685384.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

David, I don't necessarily think it is reasonable to yield every 100 opcodes, but that is the _intent_ of the current code base. Checkinterval is set to 100.  If you don't want that, then set it higher.  Your statement is like saying: "Why would you want to have your windows fit tightly, it sounds like a horrible thing for the air quality indoors" (I actually got this when living in Germany).  The answer is, of course, that a snugly fitting window can still be opened if you want, but more importantly, you _can_ close it properly.

And because the condition variable isn't strictly FIFO, it actually doesn't switch every time (an observation.  The scheduler may decide o do its own things inside the condition variable / semaphore).  What the ROUNDROBIN_GIL ensures, however, is that the condition variable is _entered_ every checkinterval.  

What I'm trying to demonsrate to you is the brokenness of the legacy GIL (as observed by Antoine long ago) and how it is not broken on windows.  It is broken because the currently running thread is biased to reaquire the GIL immediately in an unpredictable fashion that is not being managed by the (OS) thread scheduler.  Because it doesn't enter the condition variable wait when others are competing for it, the scheduler has no means of providing "fairness" to the application.

So, to summarise this:  I'm not proposing that we context switch every 100 opcodes, but I am proposing that we context switch consistently according to whatever checkinterval is put in place.

Antoine, in case you misunderstood:  I?m saying that the ROUNDROBIN_GIL and the Windows GIL are the same.  If you don't believe me, take a look at the NonRecursiveLock implementation for windows.  I'm also starting to think that you didn't actually bother to look at the patch.  Please compare PyLock_gil_acquire() for LEGACY_GIL and ROUNDROBIN_GIL and see if you can spot the difference.  Really, it's just two lines of code.

Maybe it needs restating. The bug is this (python pseudocode)
with gil.cond:
  while not gil.locked: #this line is the bug
    gil.cond.wait()
  gil.locked = True

vs.

with gil.cond:
  if gil.n_waiting or gil.locked:
    gil.n_waiting += 1
    while True:
      gil.cond.wait() #always wait at least once
      if not gil.locked:
        break
    gil.n_waiting -= 1
  gil.locked = True

 The cond.wait() is where fairness ensues, where the OS can decide to serve threads roughly on a first come, first serve basis. If you are biased towards not entering it at all (when yielding the GIL), then you have taken away the OS' chance of scheduling. 

Antoine (2):  The need to have do_yield is a symptom of the brokenness of the GIL.  You have a checkinterval of 100, which elapses some 1000 times per second, and yet you have to put in place special fudge code to ensure that we do get switches every few seconds?  The whole point of the checkinterval is for you _not_ to have to dot the code with sleep() calls.  Surely you don't expect the average application developer to do that if he wants his two cpu bound threads to compete fairly for the GIL?  This is why I added the -y switch:  To emulate normal application code.

Also, the 0.7 imbalance observed in the SHA1 disappears on windows, (and using ROUNDROBIN_GIL).  It is not due to the windows scheduler, it is due to the broken legacy_gil.


This last slew of comments has been about the ROUNDROBIN_GIL only.  I haven't dazzled you yet with PRIORITY_GIL, but that solves both problems because it is _fair_, and it allows us to increase the checkinterval to 10000, thus elimintating the rapid switching overhead, and yet gives fast response to IO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:52:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 14:52:46 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1270997566.53.0.691856480546.issue8368@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why do you think PyObject_CallObject() is the culprit?
There could be any number of reasons for a memory leak:
- cyclic references needing to be cleared (have you tried calling PyGC_Collect()?)
- reference leak(s) in your own internal logic
- inefficiencies in the Windows memory allocator which mean "freed" memory is not necessarily reclaimed

PyObject_CallObject() itself is called with the GIL held, so the multithreaded nature of the program shouldn't be a factor.
I would also suggest running more iterations, to see whether memory consumption reaches a stable state or grows endlessly.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:59:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Apr 2010 14:59:05 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270997945.26.0.636819078166.issue8366@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 16:59:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 14:59:06 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270997187.54.0.0415144685384.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270998068.3494.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine (2):  The need to have do_yield is a symptom of the brokenness
> of the GIL.

Of course it is. But the point of the benchmark is to give valid results
even with the old broken GIL.

I could remove do_yield and still have it give valid results, but that
would mean running each step for 30 seconds instead of 2. I don't like
having to wait several minutes for benchmark numbers :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:00:42 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 11 Apr 2010 15:00:42 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The "builtins" module referenced in the Python 2.6 __import__ documentation does not seem to exist in Python 2.6:

http://docs.python.org/library/functions.html#__import__

These should probably be changed to __builtin__:

http://docs.python.org/library/__builtin__.html

----------
messages: 102841
nosy: cjerdonek
severity: normal
status: open
title: change module "builtins" to "__builtin__" in __import__ documentation
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:00:56 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 11 Apr 2010 15:00:56 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1270998056.54.0.157321536366.issue8370@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:04:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 15:04:51 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1270998291.02.0.448477774871.issue8370@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You?re right. This module name has been fixed in the 3.x branch (it used a magic name without reason); when importlib was backported from 3.1 to 2.6, this change must have been overlooked.

Are you willing to produce a patch?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:06:55 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 11 Apr 2010 15:06:55 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1270998415.46.0.484523707222.issue8370@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Replaced "builtins" with "__builtin__".  Also inserted a missing "the".

----------
keywords: +patch
Added file: http://bugs.python.org/file16870/_issue-8370-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:14:07 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 11 Apr 2010 15:14:07 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1270998847.28.0.605877388964.issue8370@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for the info and quick response.  Then this should probably also be applied to trunk (Python 2.7).

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:20:22 2010
From: report at bugs.python.org (David Beazley)
Date: Sun, 11 Apr 2010 15:20:22 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270999222.38.0.109338431927.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I'm sorry, I still don't get the supposed benefits of this round-robin patch over the legacy GIL.   Given that using interpreter ticks as a basis for thread scheduling is problematic to begin with (mostly due to the fact that ticks have totally unpredictable execution times), I'd much rather see further GIL work continue to build upon the time-based scheduler that's been implemented in Python 3.2.  For instance, I think being able to specify a thread-switching interval in seconds (sys.setswitchinternal) makes much more sense than continuing to fool around with check intervals and all of this tick business.

The new GIL implementation is by no means perfect, but people are working on it.   I'd much rather know if anything that you've worked out with this patch can be applied to that version of the GIL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:23:56 2010
From: report at bugs.python.org (Krauzi)
Date: Sun, 11 Apr 2010 15:23:56 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1270999436.16.0.173391149271.issue8368@psf.upfronthosting.co.za>


Krauzi <krauzi_gmbh at yahoo.de> added the comment:

i think the PyObject_Call* is the problem because when i comment it out, i do not longer get leaks. The arguments are also correctly decremented because i also can use NULL as argument and i get the same mem leaks like before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:32:31 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 11 Apr 2010 15:32:31 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1270999951.1.0.317461645081.issue8370@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Would it make sense to put a "New in version 3.1" at the top of this page:

http://docs.python.org/py3k/library/builtins.html

(perhaps also with a note explaining that the module replaces __builtin__).  I actually wasn't able to confirm when "builtins" was introduced by searching Google and What's New, etc.  That's why I appreciated Eric's note.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:38:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 15:38:59 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1271000339.68.0.290222132239.issue8370@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> (perhaps also with a note explaining that the module replaces __builtin__)
People used to 2.x will know about the name change; people new to Python with 3.x (the happy ones!) will not this this information, except perhaps to understand outdated docs or snippets. Hm. A short note would be helpful, I agree.


> I actually wasn't able to confirm when "builtins" was introduced by
> searching Google and What's New,
http://docs.python.org/py3k/whatsnew/3.0.html#library-changes

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 17:40:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 15:40:56 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1271000456.4.0.198081982539.issue8370@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your first patch seems good to me; wait for a core developer?s answer before taking time to add notes about renamed modules everywhere.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Sun Apr 11 18:14:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 16:14:03 +0000
Subject: [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1271002443.27.0.655400479927.issue5315@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the detailed analysis, Charles-Fran?ois.

> Finally, I think that the documentation should be rephrased:

Yes, I think so.

> Furthermore, under Linux 2.6 and NPTL, getpid() returns the main thread
> PID even from another thread.

Yes, those threads belong to the same process.

But as mentioned, signals are a rather fragile inter-process communication device; just use a specific file descriptor.
And if you still wanna use signals, there's set_wakeup_fd():
http://docs.python.org/library/signal.html#signal.set_wakeup_fd

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl, pitrou, tim_one
priority:  -> normal
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5315>
_______________________________________

From report at bugs.python.org  Sun Apr 11 18:36:04 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 11 Apr 2010 16:36:04 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1271003764.74.0.712592083771.issue6507@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I've made a patch, which adds a disassemble_str function to the dis module. The dis.dis function calls this function if x is a string. Added the following sentence to the documentation: "Strings are first compiled to code objects with the :func:`compile` built-in function." Added two simle unittests.

----------
keywords: +patch
nosy: +durban
Added file: http://bugs.python.org/file16871/issue6507.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sun Apr 11 18:47:43 2010
From: report at bugs.python.org (Darryl Miles)
Date: Sun, 11 Apr 2010 16:47:43 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271004463.7.0.723229007704.issue8108@psf.upfronthosting.co.za>


Darryl Miles <darryl.miles at darrylmiles.org> added the comment:

I am unable to get "make test" to run from an unpatched version in SVN (details below of make output).

Please find attached an updated patch for your consideration (and testing, as I can't test it due to 'make test' SIGSEGV on CentOS 5.4 i386).


Patch Notes:

1) Some thing that concern me, the "unwrap()" philosophy looks to be used to remove SSL from the Python high-level socket handle, so you can go back to plaintext mode.  You can ONLY perform an unwrap() AFTER an SSL_shutdown()==1 has been observed (you need to wait for the other end to do something voluntarily).

So you must retry the SSL_shutdown() over and over while you sleep-wait for IO, so this is akin to calling the ssl.shutdown(ssl.SSL_SHUTDOWN_MODE_BOTH) and getting back success.

Also if it is your intention to properly implement an unwrap() like this you should disable IO read-ahead mode before calling shutdown for the second time, SSL_set_read_ahead(ssl, 0).  This stops OpenSSL from eating too many bytes accidentally (probably from the kernel into its own buffers), from the inbound IO stream, which may not be SSL protocol data, it maybe plain text data (behind the last byte of SSL protocol data).


2) Due to the IO waiting it looks also necessary to copy the setup of SSL_set_nbio() from the read/write paths so the check_socket_and_wait_for_timeout() works in sympathy to the callers IO timeout reconfiguration.


3) My patch presumes the allocation of the type "struct PySSLObject" uses calloc() or some other memory zeroing strategy.  There is a new member in that struct to track if SSL_shutdown() has previously returned a zero value.


4) The SSL_peek() error path needs checking to see if the error return is consistent with the Python paradigm.


5) Please check I have understand the VARARGS method correctly.  I have made the default to SSL_SHUTDOWN_MODE_SENT (despite backward compatibly being SSL_SHUTDOWN_MODE_ONCE), this is because I would guess that most high-level applications did not intend to use it in raw mode; nor be  bothered with the issues surrounding correct usage.  I would guess high-level applications wanted Python to take the strain here.


6) I suspect you need to address your unwrap() policy a little better, the shutdown operation and the unwrap() are two different matters.  The shutdown() should indicate success or not (in respect of the mode being requested, raw mode is a tricky one as the caller would want to the exact error return so it can do the correct thing), unwrap() should itself call ssl.shutdown(ssl.SSL_SHUTDOWN_MODE_BOTH) until it sees success and then remove the socket (and deallocate SSL objects).

As things stand SSL_SHUTDOWN_MODE_ONCE does not work in a useful way since the error returns are not propagated to the caller, because "unwrap" is mixed into this.  So that would still need fixing.



building works ok, testing fails with SIGSEGV.  Is this something to do with no having _bsddb built ?  I have db-4.3 working.  Maybe someone can reply by email on the matter.

# make
running build
running build_ext
building dbm using gdbm

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts




# make test
running build
running build_ext
building dbm using gdbm

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -Wd -3 -E -tt ./Lib/test/regrtest.py -l 
== CPython 2.7a4+ (trunk:79902M, Apr 11 2010, 16:38:55) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]
==   Linux-2.6.18-164.15.1.el5-i686-with-redhat-5.4-Final
==   /root/python-svn/build/test_python_29248
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
test_unittest
test_doctest
test_doctest2
test_MimeWriter
test_SimpleHTTPServer
test_StringIO
test___all__
/root/python-svn/Lib/test/test___all__.py:10: DeprecationWarning: in 3.x, the bsddb module has been removed; please use the pybsddb project instead
  import bsddb
/root/python-svn/Lib/bsddb/__init__.py:67: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  import _bsddb
make: *** [test] Segmentation fault

----------
Added file: http://bugs.python.org/file16872/Modules__ssl.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sun Apr 11 18:50:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 16:50:31 +0000
Subject: [issue8371] Add a command to download distributions
In-Reply-To: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za>
Message-ID: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Distutils2 should have a command responsible for downloading distributions. This would factor it out of other code in one clear location and allow users to download for later installation.

If setup.cfg files grow options for extras, test-requires, build-requires and such specific kinds of dependencies, matching options would appear on the download (or get) command.

Side note: Is it okay to post this as a bug or should I rather mail distutils-sig first? Or mail them now?

Regards

----------
assignee: tarek
components: Distutils2
messages: 102853
nosy: merwok, tarek
severity: normal
status: open
title: Add a command to download distributions
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8371>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:08:23 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 11 Apr 2010 17:08:23 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1271005703.65.0.390496463731.issue8366@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

It seems to that improvement for CFLAGS show bug  in python build system - quote for configure:
....
		BASECFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${BASECFLAGS}"
		tgt=`sw_vers -productVersion | sed 's/\(10\.[[0-9]]*\).*/\1/'`
		if test "${UNIVERSALSDK}" != "/" -a "${tgt}" '>' '10.4' ; then
			CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}"
			CPPFLAGS="-isysroot ${UNIVERSALSDK}"
		fi
....
No idea why the script set CFLAGS and CPPFLAGS under a specific condition - may be some test cases from configure will fail without those flags set.
Assignment to CPPFLAGS will ignore user settings - this is not acceptable.

Lets see report from Ned Deily: "might look like this" : the -isysroot is added twice .

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:17:59 2010
From: report at bugs.python.org (Krauzi)
Date: Sun, 11 Apr 2010 17:17:59 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271006279.9.0.176237451492.issue8368@psf.upfronthosting.co.za>


Krauzi <krauzi_gmbh at yahoo.de> added the comment:

kay updated the code. Please use this:
http://paste.pocoo.org/show/200484/
smaller code but problem still the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:18:13 2010
From: report at bugs.python.org (Krauzi)
Date: Sun, 11 Apr 2010 17:18:13 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271006293.33.0.769876406579.issue8368@psf.upfronthosting.co.za>


Changes by Krauzi <krauzi_gmbh at yahoo.de>:


Removed file: http://bugs.python.org/file16868/Python Bug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:31:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 17:31:58 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271007118.33.0.357852151124.issue8368@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I've ported the program to Linux (see attached tar file). I cannot observe any memory leak here - even if I let the program run for a long time (linking with Python 2.6). Memory usage in top goes up and down, but never over some upper limit.

The only changes to the source that I made are these:
- remove the pause calls
- run the thread creation in an infinite loop
- join the threads

I notice that the Win32 version also doesn't join the threads. Notice that this is a memory leak in itself.

----------
nosy: +loewis
Added file: http://bugs.python.org/file16873/issue8368.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:45:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 17:45:37 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1271004463.7.0.723229007704.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271008056.3494.43.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

To just run the test_ftplib tests, you can use:

$ ./python -m test.regrtest -v -uall test_ftplib

(Other tests involving SSL sockets are test_ssl, test_smtpnet,
test_imaplib and test_poplib)

> 1) Some thing that concern me, the "unwrap()" philosophy looks to be
> used to remove SSL from the Python high-level socket handle, so you
> can go back to plaintext mode.  You can ONLY perform an unwrap() AFTER
> an SSL_shutdown()==1 has been observed (you need to wait for the other
> end to do something voluntarily).

When the SSL shutdown fails, an exception is raised, which means the
rest of the unwrapping (at the Python "high-level" socket level) doesn't
occur.
Therefore, it is safe to call unwrap() again from user code because the
SSL object is still there.

> Also if it is your intention to properly implement an unwrap() like
> this you should disable IO read-ahead mode before calling shutdown for
> the second time, SSL_set_read_ahead(ssl, 0).  This stops OpenSSL from
> eating too many bytes accidentally (probably from the kernel into its
> own buffers), from the inbound IO stream, which may not be SSL
> protocol data, it maybe plain text data (behind the last byte of SSL
> protocol data).

Do you know how to cook a simple test to exercise this?

> 2) Due to the IO waiting it looks also necessary to copy the setup of
> SSL_set_nbio() from the read/write paths so the
> check_socket_and_wait_for_timeout() works in sympathy to the callers
> IO timeout reconfiguration.

Thanks for spotting this.

> 5) Please check I have understand the VARARGS method correctly.  I
> have made the default to SSL_SHUTDOWN_MODE_SENT (despite backward
> compatibly being SSL_SHUTDOWN_MODE_ONCE), this is because I would
> guess that most high-level applications did not intend to use it in
> raw mode; nor be  bothered with the issues surrounding correct usage.
> I would guess high-level applications wanted Python to take the strain
> here.

Yes, sounds right indeed. I'm not sure we need a choice of shutdown
modes at all.

> building works ok, testing fails with SIGSEGV.  Is this something to
> do with no having _bsddb built ?  I have db-4.3 working.  Maybe
> someone can reply by email on the matter.

_bsddb seems to be built, it's the old bsddb185 which isn't.
The module apparently breaks when importing it, can you open a separate
issue for it?

I'd like Bill Janssen's opinion on these proposed changes. Bill, can you
take a look?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:46:34 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 17:46:34 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1271007994.71.0.537688797452.issue8366@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Setting CPPFLAGS to include the SDK is needed to make sure some of the autoconf tests work correctly by using the SDK's header files rather than  those from /.  But, you're right, it shouldn't throw away other CPPFLAGS settings. Plus that whole test there is suspect: it probably shouldn't be testing the build system version there.  There are various ways to handle this and opportunities to simplify the OS X SDK processing; plus all of the trees (trunk, py3k, 26, 31) should work the same way.  Let's see what Ronald prefers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:56:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Apr 2010 17:56:56 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1271008616.55.0.257622873643.issue6507@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sun Apr 11 19:57:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 17:57:57 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1271008677.44.0.578850641014.issue7443@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

1. I agree that we should fix the unlinking problem on Windows. I also think that such a fix should be independent of the test suite - many people run into failed unlink problems.

2. Tim already said it, but I repeat: the common theory is that the culprit for this kind of problem is software like virus checkers, desktop search spiders, Tortoise, ...

3. I'm not convinced that "rmdir/s/q" *really* solves the problem reliably. Because it's a timing issue, it may be that the additional startup cost to invoke rmdir was enough to let the virus scanner win the race, so that rmdir actually had no problems with removing the file.

4. I believe the official party line for removing files on Windows is this: "If DeleteFile fails, move the file to the trash bin (of the disk), and use NtSetInformationFile to set the delete disposition for the file". See cygwin's unlink_nt for an elaborate implementation of unlinking:

http://tinyurl.com/y7w6rrj

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:33:05 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:33:05 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

The makesockaddr() function in the socket module assumes that
AF_UNIX addresses have a null-terminated sun_path, but Linux
actually allows unterminated addresses using all 108 bytes of
sun_path (for normal filesystem sockets, that is, not just
abstract addresses).

When receiving such an address (e.g. in accept() from a
connecting peer), makesockaddr() will run past the end and return
extraneous bytes from the stack, or fail because they can't be
decoded, or perhaps segfault in extreme cases.

This can't currently be tested from within Python as Python also
refuses to accept address arguments which would fill the whole of
sun_path, but the attached linux-pass-unterminated.diff (for 2.x
and 3.x) enables them for Linux.  With the patch applied:

Python 2.7a4+ (trunk, Apr  8 2010, 18:20:28) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX)
>>> s.bind("a" * 108)
>>> s.getsockname()
'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\xfa\xbf\xa8)\xfa\xbf\xec\x15\n\x08l\xaaY\xb7\xb8CZ\xb7'
>>> len(_)
126

Also attached are some unit tests for use with the above patch, a
couple of C programs for checking OS behaviour (you can also see
the bug by doing accept() in Python and using the bindconn
program), and patches aimed at fixing the problem.

Firstly, the return-unterminated-* patches make makesockaddr()
scan sun_path for the first null byte as before (if it's not a
Linux abstract address), but now stop at the end of the structure
as indicated by the addrlen argument.

However, there's one more catch before this will work on Linux,
which is that Linux system calls return the length of the address
they *would* have stored in the structure had there been room for
it, which in this case is one byte longer than the official size
of a sockaddr_un structure, due to the missing null terminator.

The addrlen-* patches handle this by always calling
makesockaddr() with the actual buffer size if it is less than the
returned length.  This silently ignores any truncation, but I'm
not sure how to do anything sensible about that, and some
operating systems (e.g. FreeBSD) just silently truncate the
address anyway and don't return the original length (POSIX
doesn't make clear which, if either, behaviour is required).
Once these patches are applied, the tests pass.

There is one other issue: the patches for 3.x retain the
assumption that socket paths are in UTF-8, but they should
actually be handled according to PEP 383.  I've got a patch for
that, but I'll open a separate issue for it since the handling of
the Linux abstract namespace isn't documented and there's some
slightly unobvious behaviour that people might be depending on.

----------
components: Extension Modules
files: linux-pass-unterminated.diff
keywords: patch
messages: 102861
nosy: baikie
severity: normal
status: open
title: socket: Buffer overrun while reading unterminated AF_UNIX addresses
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16874/linux-pass-unterminated.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:35:10 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 11 Apr 2010 18:35:10 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1271010910.8.0.763581834126.issue8211@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Victor, could you please fix the patch or revert it ?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:37:40 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:37:40 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271011060.25.0.617084591202.issue8372@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16875/return-unterminated-2.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:37:56 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:37:56 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271011076.26.0.929419411198.issue8372@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16876/return-unterminated-3.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:38:08 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 11 Apr 2010 18:38:08 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1271008677.44.0.578850641014.issue7443@psf.upfronthosting.co.za>
Message-ID: <4BC216E5.7020205@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I'm afraid that the problem doesn't lie in the unlink: DeleteFile
succeeds. The problem is that the file is only marked for delete
until such time as the last SHARE_DELETE handle on it is closed.
Until that time, an attempt to (re)create the file for anything
other than SHARE_DELETE will fail. As you say, it's a timing
issue.

Making os.unlink on Windows more robust may be a good
idea, but it's not going to help this issue. See my test-case.py
on an earlier message for reproduction:

http://bugs.python.org/file16869

TJG

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:38:40 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Apr 2010 18:38:40 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1271011120.32.0.608262211266.issue7433@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7433>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:38:42 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:38:42 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271011122.79.0.887075047277.issue8372@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16877/addrlen-2.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:38:59 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:38:59 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271011139.97.0.417094284211.issue8372@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16878/addrlen-3.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:39:08 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 11 Apr 2010 18:39:08 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1271011148.96.0.954758908857.issue8211@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Reopening the ticket: it shouldn't have been closed.

I'm also making this a release blocker, since this needs to be fixed before the next release - the CC variable has to be initialized by the build system and breaking this in general for all default builds just to get a debug build without optimizations is not warranted.

----------
priority:  -> release blocker
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:39:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 11 Apr 2010 18:39:37 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1271011177.63.0.0201734442124.issue8211@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:40:12 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:40:12 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271011212.67.0.180528192324.issue8372@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16879/test-2.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:40:29 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:40:29 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271011229.41.0.297347564029.issue8372@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16880/test-3.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:45:29 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:45:29 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

In 3.x, the socket module assumes that AF_UNIX addresses use
UTF-8 encoding - this means, for example, that accept() will
raise UnicodeDecodeError if the peer socket path is not valid
UTF-8, which could crash an unwary server.

Python 3.1.2 (r312:79147, Mar 23 2010, 19:02:21) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from socket import *
>>> s = socket(AF_UNIX, SOCK_STREAM)
>>> s.bind(b"\xff")
>>> s.getsockname()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: unexpected code byte

I'm attaching a patch to handle socket paths according to PEP
383.  Normally this would use PyUnicode_FSConverter, but there
are a couple of ways in which the address handling currently
differs from normal filename handling.

One is that embedded null bytes are passed through to the system
instead of being rejected, which is needed for the Linux abstract
namespace.  These abstract addresses are returned as bytes
objects, but they can currently be specified as strings with
embedded null characters as well.  The patch preserves this
behaviour.

The current code also accepts read-only buffer objects (it uses
the "s#" format), so in order to accept these as well as
bytearray filenames (which the posix module accepts), the patch
simply accepts any single-segment buffer, read-only or not.

This patch applies on top of the patches I submitted for issue
#8372 (rather than knowingly running past the end of sun_path).

----------
components: Extension Modules
files: af_unix-pep383.diff
keywords: patch
messages: 102865
nosy: baikie
severity: normal
status: open
title: socket: AF_UNIX socket paths not handled according to PEP 383
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16881/af_unix-pep383.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:47:34 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:47:34 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1271011654.84.0.383083134879.issue8373@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

This patch does the same thing without fixing issue #8372 (not
that I'd recommend that, but it may be easier to review).

----------
Added file: http://bugs.python.org/file16882/af_unix-pep383-no-8372-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:48:57 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:48:57 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1271011737.84.0.802326259758.issue8373@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16883/test-existing.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:49:38 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:49:38 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1271011778.21.0.873061277218.issue8373@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16884/test-new.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:50:11 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:50:11 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1271011811.14.0.618957149589.issue8373@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16885/af_unix-pep383-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sun Apr 11 20:54:12 2010
From: report at bugs.python.org (Darryl Miles)
Date: Sun, 11 Apr 2010 18:54:12 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271012052.01.0.484848939485.issue8108@psf.upfronthosting.co.za>


Darryl Miles <darryl.miles at darrylmiles.org> added the comment:

To explain why you need 2 modes, a client/server would expect to do the following pseudo actions for maximum efficiency:

set_socket_timeout(600_SECONDS)  # or useful default
send_data_over_ssl("QUIT\r\n")
shutdown(SSL_SHUTDOWN_MODE_SENT)
flush_data_down_to_socket()   # maybe automatic/implied (OpenSSL users with custom BIO layers should be aware of this step)
shutdown(socket, SHUT_WR)   # this is optional, TCP socket level shutdown
recv_data_over_ssl() = "250 Bye bye!\r\n"  # this will take time to arrive
set_socket_io_timeout(5_SECONDS)
shutdown(SSL_SHUTDOWN_MODE_BOTH)  # this is optional!  some clients may choose to skip it entirely
close()/unwrap()


A server would:

recv_data_over_ssl() = "QUIT\r\n"  # would be sitting idle waiting for this command
send_data_over_ssl("250 Bye bye!\r\n")
shutdown(SSL_SHUTDOWN_MODE_SENT)
flush_data_down_to_socket()   # maybe automatic/implied (OpenSSL users with custom BIO layers should be aware of this step)
shutdown(socket, SHUT_WR)   # this is optional, TCP socket level shutdown
set_socket_io_timeout(30_SECONDS)
shutdown(SSL_SHUTDOWN_MODE_BOTH)  # a good server would implement this step
close()/unwrap()


Now if your outbound data is CORKed and flushed, the flush points would cause all the SSL data from both the 'last sent data' and the 'send shutdown notify' to go out in the same TCP segment and arrive at the other end more or less together.

Doing any of the above in a different order introduces some kind of inefficiency.  shutdown(fd, SHUT_WR) are often used at the socket level to help the manage TIME_WAIT.

The client has to wait for the QUIT response message anyway.  With the above sequence there is no additional time delay or cost with both parties performing a SSL protocol shutdown at the same time.  Despite the IO timeouts existing (to provide a safety net).

If the client is talking to a buggy server the worst case scenario is that it receives the quit response but the server never does an SSL shutdown and the server doesn't close the socket connection.  In this situation the client will have to wait for IO timeout, some clients in other software use blocking sockets and don't have a timeout so they end up hooked (forever).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:00:10 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 19:00:10 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <y5H9s5ygbZ3F.XN3FkBlq@smtp.gmail.com>


Ned Deily <nad at acm.org> added the comment:

To be totally fair, it is likely that part of the OS X breakage was caused by the original code inadvertently working around the original CFLAGS misbehavior. From an OS X perspective, it may be best to just fix the new issue and move on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:03:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 19:03:21 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271012601.01.0.00934298540892.issue8372@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, loewis
priority:  -> high
stage:  -> patch review
versions:  -Python 2.5, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:04:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 19:04:55 +0000
Subject: [issue8373] socket: AF_UNIX socket paths not handled according to PEP
	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1271012695.77.0.0743735589183.issue8373@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, loewis
priority:  -> normal
stage:  -> patch review
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:12:25 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 19:12:25 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <4BC216E5.7020205@timgolden.me.uk>
Message-ID: <4BC21F16.8050902@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm afraid that the problem doesn't lie in the unlink: DeleteFile
> succeeds. The problem is that the file is only marked for delete
> until such time as the last SHARE_DELETE handle on it is closed.

Then we shouldn't use DeleteFile in the first place to delete the file,
but instead CreateFile, with DELETE access (and FILE_SHARE_DELETE
sharing). If that fails, we need to move the file to the bin
(see unlink_nt for details).

> Making os.unlink on Windows more robust may be a good
> idea, but it's not going to help this issue. See my test-case.py
> on an earlier message for reproduction:

It certainly will help this case also. It would detect that the file is
still open, and move it into the trash bin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:16:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 19:16:40 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271013400.91.0.934750550324.issue8368@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks Martin. I see no leak here either (Linux with Python 2.6 and 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:23:04 2010
From: report at bugs.python.org (Krauzi)
Date: Sun, 11 Apr 2010 19:23:04 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271013784.54.0.140643056402.issue8368@psf.upfronthosting.co.za>


Krauzi <krauzi_gmbh at yahoo.de> added the comment:

oh no then it's a windows bug. Now i understand why many devs use linux instead of windows......

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:24:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 19:24:24 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1271013864.72.0.676586524777.issue8253@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve read some distutils-sig threads about this. Do you still want to write a PEP for it before implementation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:31:57 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 11 Apr 2010 19:31:57 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <4BC21F16.8050902@v.loewis.de>
Message-ID: <4BC2238A.3080609@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

> Then we shouldn't use DeleteFile in the first place to delete the file,
> but instead CreateFile, with DELETE access (and FILE_SHARE_DELETE
> sharing). If that fails, we need to move the file to the bin
> (see unlink_nt for details).

I see what you're getting at. I'm getting to the end of my day
here, but I'll try to put a patch together for posixmodule.c
when I can, if no-one else gets there first.

Would you agree that py3k is the only target branch worth aiming for?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:32:50 2010
From: report at bugs.python.org (Tony Locke)
Date: Sun, 11 Apr 2010 19:32:50 +0000
Subject: [issue2987] RFC2732 support for urlparse (e.g. http://[::1]:80/)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271014370.81.0.828784821245.issue2987@psf.upfronthosting.co.za>


Tony Locke <tlocke at tlocke.org.uk> added the comment:

I've created a patch for parse.py against the py3k branch, and I've also included ndim's test cases in that patch file.

When returning the host name of an IPv6 literal, I don't include the surrounding '[' and ']'. For example, parsing http://[::1]:5432/foo/ gives the host name '::1'.

----------
nosy: +tlocke
versions: +Python 3.2
Added file: http://bugs.python.org/file16886/parse.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:37:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 11 Apr 2010 19:37:24 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1271014644.92.0.67100417015.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Thinking back about this, I wonder whether "FTPS" could be a better name to use instead of "FTP_TLS".
It's shorter, easier to remember, and also makes more sense since also SSL can be used, not only TLS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:38:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 19:38:40 +0000
Subject: [issue2987] RFC2732 support for urlparse (e.g. http://[::1]:80/)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271014720.29.0.0130880503934.issue2987@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Seems sensible: Delimiters are not part of components.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:43:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 19:43:56 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1271015036.58.0.946906137681.issue2054@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It doesn?t look like a constant, too.

httplib.Client, ftplib.Client, ftplib.SecureClient would be much more descriptive than httplib.HTTP and ftplib.FTP. Any interest about adding aliases?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Sun Apr 11 21:45:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 19:45:38 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1271014644.92.0.67100417015.issue2054@psf.upfronthosting.co.za>
Message-ID: <1271015260.23110.6.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thinking back about this, I wonder whether "FTPS" could be a better name to use instead of "FTP_TLS".
> It's shorter, easier to remember, and also makes more sense since also SSL can be used, not only TLS.

What do you mean by "also SSL can be used"?
Wikipedia has an interesting article about the subject:
http://en.wikipedia.org/wiki/FTPS

Secured FTP with explicit negotiation (what we are doing) is sometimes
called "FTPES" (that's how it's named in FileZilla indeed).
"FTPS" is more often used to describe secured FTP with implicit
negotiation, i.e. the SSL session is established before the FTP protocol
even kicks in.

I think FTP_TLS is a fine name. Perhaps we can simply make the above
distinction clearer in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:02:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 20:02:51 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271016171.38.0.808568788309.issue8368@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can't reproduce the problem on Windows, either. The attached project runs the thread creation in a loop (leaving the 3s sleep in the code). I see (in process viewer) that the Commit Size varies between 13MB and 14MB; there is no indication of a leak.

----------
resolution:  -> invalid
status: open -> closed
Added file: http://bugs.python.org/file16887/Python Bug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:06:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 20:06:57 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <4BC2238A.3080609@timgolden.me.uk>
Message-ID: <4BC22BD9.8090009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Would you agree that py3k is the only target branch worth aiming for?

Most certainly, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:32:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 20:32:47 +0000
Subject: [issue2987] RFC2732 support for urlparse (e.g. http://[::1]:80/)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271017967.45.0.880688697781.issue2987@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think parsing should be a bit more careful. For example, what happens when you give 'http://dead:beef::]/foo/' as input (note the missing opening bracket)?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:34:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 20:34:21 +0000
Subject: [issue2987] RFC2732 support for urlparse (e.g. http://[::1]:80/)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271018061.45.0.839250919837.issue2987@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, updating the RFC list as done in python-urlparse-rfc2732-rfc-list.patch is also a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:38:44 2010
From: report at bugs.python.org (Krauzi)
Date: Sun, 11 Apr 2010 20:38:44 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271018324.65.0.840165850394.issue8368@psf.upfronthosting.co.za>


Krauzi <krauzi_gmbh at yahoo.de> added the comment:

ah no you misunderstood me. Please add a system("pause") and a system("pause") at the beginning of the while(1)-loop and one at the end. Then compare the memory usage of the program at the beginning (lets say it's 2,6 MB) with the usage at the second pause. In may case its 3,9 MB at this point. THIS is what i mean with the leak. On my computer on about 30000-35000 calls i pass the 4 MB "border".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:44:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 20:44:49 +0000
Subject: [issue2987] RFC2732 support for urlparse (e.g. http://
In-Reply-To: <1271017967.45.0.880688697781.issue2987@psf.upfronthosting.co.za>
Message-ID: <4BC234BE.70906@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Isn?t ?http://dead:beef::]/foo/? and invalid URI?

Regarding doc, see also #5650.

----------
title: RFC2732 support for urlparse (e.g. http://[::1]:80/) -> RFC2732 support for urlparse (e.g. http://

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:45:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 20:45:00 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1271018700.2.0.576289862622.issue5650@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #2987

----------
title: Obsolete RFC's should be removed from doc of urllib.urlparse -> Obsolete RFCs should be removed from doc of urllib.urlparse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Sun Apr 11 22:54:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 20:54:25 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <4BC234BE.70906@netwok.org>
Message-ID: <1271019387.23110.8.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Isn?t ?http://dead:beef::]/foo/? and invalid URI?

That's the point, it shouldn't parse as a valid one IMO.

----------
title: RFC2732 support for urlparse (e.g. http:// -> RFC2732 support for urlparse (IPv6 addresses)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:00:26 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Apr 2010 21:00:26 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1271019626.05.0.750010924238.issue7301@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The changes in main.c in r79881 don't look right:

strtok() is used on the string returned by getenv(), which must not
be modified.

Also (and this admittedly cosmetic), perhaps use a static buffer like
wchar_t warning[128] or use a single allocation before the for loop.
What is the maximum length for a single warning?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:10:50 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Sun, 11 Apr 2010 21:10:50 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1271020250.02.0.421808640271.issue7301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

The pending patch for py3k fixes the modification of the env value (trunk already has a fix for that).

That patch is also doing the conversion to wchar_t via the char2wchar function now, with that reusing a single buffer seems out of the question

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:18:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Apr 2010 21:18:06 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1271020686.28.0.521288670466.issue8070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't have time to write a better patch, please improve mine :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8070>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:19:01 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 11 Apr 2010 21:19:01 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271020741.01.0.979373850491.issue7946@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

A couple remarks on BFS-based patch:
- nothing guarantees that you'll get a msec resolution
- gettimeofday returns you wall clock time: if a process that modifies time is running, e.g. ntpd, you'll likely to run into trouble. the value returned is _not_ monotonic, but clock_gettime(CLOCK_MONOTONIC) is
- inline functions are used, but it's not ANSI
- static inline long double get_timestamp(void) {
    struct timeval tv;
    GETTIMEOFDAY(&tv);
    return (long double) tv.tv_sec + tv.tv_usec * 0.000001;
}
the product is computed as double, and then promoted as (long double).
- the code uses a lot of floating point calculation, which is slower than integer

Otherwise:
"- You know, I almost wonder whether this whole issue could be fixed by just adding a user-callable function to optionally set a thread priority number.  For example:

    sys.setpriority(n)

Modify the new GIL code so that it checks the priority of the currently running thread against the priority of the thread that wants the GIL.  If the running thread has lower priority, it immediately drops the GIL."

The problem with this type of fixed-priority is starvation. And it shouldn't be up to the user to set the priorities. And some threads can mix I/O and CPU intensive tasks.

> It's a dual-core Linux x86-64 system. But, looking at the patch again, the reason is obvious:
>
> #define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted || (tstate
> >tick_counter % 1000 == 0))
>
> `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, which based its speculative operation on the number of elapsed opcodes (and which also gave bad latency numbers on the regex workload).

I find this suspicous too. I haven't looked at the patch in detail, but what does the number of elapsed opcodes offers you over the timesplice expiration approach ?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:20:24 2010
From: report at bugs.python.org (Luke Jennings)
Date: Sun, 11 Apr 2010 21:20:24 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>


New submission from Luke Jennings <ubuntujenkins at googlemail.com>:

In the locale module there are some locales that are not supported these the ones that I am aware of are nl_AW, sr_RS sr_ME. This information was due to a project that captures screenshots in different languages and we have to retrieve the language code. Related to the origin of the bug https://bugs.edge.launchpad.net/quickshot/+bug/554861 .

If any more information is required please let me know.

----------
components: Extension Modules
messages: 102891
nosy: ubuntujenkins
severity: normal
status: open
title: Some locales are unsupported
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:38:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 21:38:38 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271021918.21.0.45437032334.issue8374@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Not a local expert here, but since this module relies on the underlying libc locale support. Do other programs work correctly with this locale?

Apart from that, your program needs to catch and handle exceptions anyway.

Martin, I?m making you nosy, since you?re listed as locale area expect in the maintainers file. Hope it?s okay to do so.

Regards

----------
components: +Library (Lib) -Extension Modules
nosy: +loewis, merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:43:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 21:43:12 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271022192.33.0.350032477932.issue8374@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry for sending this too fast. The beginning should read:

Not a locale expert here, but since this module relies on the underlying libc locale support, the bug is not Python-specific.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:47:53 2010
From: report at bugs.python.org (Luke Jennings)
Date: Sun, 11 Apr 2010 21:47:53 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271022473.84.0.29922358725.issue8374@psf.upfronthosting.co.za>


Luke Jennings <ubuntujenkins at googlemail.com> added the comment:

Other programs do work with the local. 

I am working on dealing with exceptions, I am rather new to programing and thought it would also be good to try and get this fixed in the original module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:49:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 21:49:10 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271022473.84.0.29922358725.issue8374@psf.upfronthosting.co.za>
Message-ID: <4BC243CF.9090908@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

What I?m saying is that the original module is not a bug. I?ll let 
Martin confirm or infirm :)

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:52:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 21:52:27 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271022747.52.0.448448347799.issue8374@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This doesn't look like a bug. You must install a locale before it gets available to Python.
Furthermore, according to the original traceback ( http://launchpadlibrarian.net/43012745/quickshot-latin.log ), the locale module isn't even involved.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:58:07 2010
From: report at bugs.python.org (Luke Jennings)
Date: Sun, 11 Apr 2010 21:58:07 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271023087.79.0.73728574651.issue8374@psf.upfronthosting.co.za>


Luke Jennings <ubuntujenkins at googlemail.com> added the comment:

Sorry for the confusion but that bug report has two very similar problems to it if you look at https://bugs.edge.launchpad.net/quickshot/+bug/554861/comments/7
and https://bugs.edge.launchpad.net/quickshot/+bug/554861/comments/6 .

I think that is calling the locale module. I apologize if i have put this down to the wrong thing I am new to python.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Sun Apr 11 23:59:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 21:59:38 +0000
Subject: [issue1004696] translate Windows newlines when installing scripts on
	POSIX
Message-ID: <1271023178.59.0.802825358553.issue1004696@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m shocked to learn this bug is still valid.

Reassigning to Distutils2, as Distutils is frozen. This bug is a particular case of #870479

Regards

----------
components: +Distutils2 -Distutils
title: translate Windows cr-lf when installing scripts on Linux -> translate Windows newlines when installing scripts on POSIX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1004696>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:00:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 22:00:38 +0000
Subject: [issue8368] Memory leak on multi-threaded PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1271023238.03.0.159109708753.issue8368@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, it consumes more memory - why do you think there is a leak?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8368>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:02:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 22:02:15 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271023335.58.0.479236301553.issue8374@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, my diagnosis was wrong. The locale module contains a list of locale aliases and some of the Serbian ones are missing. A recent locale.alias file from X11 is more complete.

----------
nosy: +lemburg
priority:  -> normal
resolution: invalid -> 
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:13:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 22:13:08 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271023988.71.0.895984687077.issue8374@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

getdefaultlocale is inherently unmaintainable, and shouldn't be used by applications. I wish it was removed from Python (but unfortunately, too many people got tricked into believing that it does something useful).

That said, if anybody feels like updating the tables from the various data sources, please go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:15:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 22:15:30 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271023988.71.0.895984687077.issue8374@psf.upfronthosting.co.za>
Message-ID: <4BC24A00.5070009@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Can we tell about getdefaultlocale?s uselessness in the docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:23:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 22:23:51 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <4BC24A00.5070009@netwok.org>
Message-ID: <4BC24BF4.2040307@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Can we tell about getdefaultlocale?s uselessness in the docs?

I haven't quite understood what people want to use that function for. If
we knew the typical use cases, we could make recommendations what they
should use instead.

One use case is to find out the encoding of the locale, in order to
encode files. People should use locale.getpreferredencoding instead, or
trust that the io module will find out on its own.

However, these cases seem to be different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:27:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 22:27:29 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <4BC24BF4.2040307@v.loewis.de>
Message-ID: <1271024972.23110.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, these cases seem to be different.

I think it can be used to find out the current language setting of the
user, and trigger a third-party translation system (other than e.g.
gettext).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:27:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 22:27:58 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271024878.72.0.107820590438.issue8374@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

When the table is updated in trunk, can it be backported to 2.6?
It does change a couple of mappings (example here is from sr_CS.* to sr_RS.*).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:36:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 22:36:05 +0000
Subject: [issue7905] Shelf 'keyencoding' keyword argument is undocumented and
	does not work.
In-Reply-To: <1265858045.44.0.437187909795.issue7905@psf.upfronthosting.co.za>
Message-ID: <1271025365.43.0.23701725662.issue7905@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One remark: In ?The *keyencoding* parameter is the encoding used to encode key values?, what are ?key values?? Don?t we just say ?keys? in such cases?

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7905>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:44:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 22:44:17 +0000
Subject: [issue870479] Scripts need platform-dependent handling
Message-ID: <1271025857.48.0.991062935467.issue870479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This bug supersedes #1004696.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue870479>
_______________________________________

From report at bugs.python.org  Mon Apr 12 00:50:38 2010
From: report at bugs.python.org (Tony Locke)
Date: Sun, 11 Apr 2010 22:50:38 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271026238.01.0.879350315909.issue2987@psf.upfronthosting.co.za>


Changes by Tony Locke <tlocke at tlocke.org.uk>:


Removed file: http://bugs.python.org/file16886/parse.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Mon Apr 12 01:03:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 23:03:01 +0000
Subject: [issue8375] test_distutils fails when run with -j
In-Reply-To: <1271026981.38.0.880810451818.issue8375@psf.upfronthosting.co.za>
Message-ID: <1271026981.38.0.880810451818.issue8375@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_distutils fails in py3k when run with -j (e.g. 
"python -m test.regrtest -j1 -v test_distutils")


======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpyn8Vpj'

======================================================================
ERROR: test_check_extensions_list (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp4r36LO'

======================================================================
ERROR: test_compiler_deprecation_warning (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpGz62QC'

======================================================================
ERROR: test_compiler_option (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpUoqcH9'

======================================================================
ERROR: test_ext_fullpath (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpqHPvDG'

======================================================================
ERROR: test_finalize_options (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp2WXDKn'

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp_kkj2U'

======================================================================
ERROR: test_get_source_files (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp13Y9c9'

======================================================================
ERROR: test_optional_extension (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp6f6ENV'

======================================================================
ERROR: test_solaris_enable_shared (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpNXs6vs'

======================================================================
ERROR: test_user_site (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpDcrnD8'

----------------------------------------------------------------------

----------
assignee: tarek
components: Distutils
messages: 102908
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils fails when run with -j
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8375>
_______________________________________

From report at bugs.python.org  Mon Apr 12 01:04:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Apr 2010 23:04:24 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271024878.72.0.107820590438.issue8374@psf.upfronthosting.co.za>
Message-ID: <4BC25576.3080204@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> When the table is updated in trunk, can it be backported to 2.6?

With the changes to the encodings for some of the locales (e.g. 'ru'), I
would advise against such a backport.

This also demonstrates one fundamental flaw of the approach: even if X11
decides that 'ru' should be using "UTF-8", some local installations will
certainly differ. Likewise when they decided that "ru" uses iso-8859-5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 01:08:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 23:08:37 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271027317.58.0.91195508566.issue8374@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, the fix (updated tables) has been committed in trunk (r79977) and py3k (r79978). I suppose Ubuntu can backport the patch if they want their Python to be in sync with their own locales.
(even better, distributions should include the regeneration of locale aliases from their own locale.alias in their build scripts)

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 01:09:11 2010
From: report at bugs.python.org (Tony Locke)
Date: Sun, 11 Apr 2010 23:09:11 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271027351.89.0.628695793244.issue2987@psf.upfronthosting.co.za>


Tony Locke <tlocke at tlocke.org.uk> added the comment:

Regarding the RFC list issue, I've posted a new patch with a new RFC list that combines ndim's list and the comments from #5650.

Pitrou argues that http://dead:beef::]/foo/ should fail because it's a malformed URL. My response would be that the parse() function has historically assumed that a URL is well formed, and so this change to accommodate IPv6 should continue to assume the URL is well formed.

I'd say that a separate bug should be raised if it's thought that parse() should be changed to check that any URL is well-formed.

----------
Added file: http://bugs.python.org/file16888/parse.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Mon Apr 12 01:15:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 23:15:29 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271027729.78.0.76091256024.issue2987@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Mon Apr 12 02:23:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 00:23:11 +0000
Subject: [issue7905] Shelf 'keyencoding' keyword argument is undocumented and
	does not work.
In-Reply-To: <1265858045.44.0.437187909795.issue7905@psf.upfronthosting.co.za>
Message-ID: <1271031791.15.0.802336733339.issue7905@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, that would be clearer wording.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7905>
_______________________________________

From report at bugs.python.org  Mon Apr 12 04:00:32 2010
From: report at bugs.python.org (George Boutsioukis)
Date: Mon, 12 Apr 2010 02:00:32 +0000
Subject: [issue6409] 2to3 -j 4 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1271037632.92.0.397944711784.issue6409@psf.upfronthosting.co.za>


George Boutsioukis <gboutsioukis at gmail.com> added the comment:

Flushing stdout is still necessary, though not enough. The processes will still have to use some kind of synchronization, and the performance toll of adding a lock to synchronize output is negligible, given that printing to stdout takes a tiny amount of time compared to the rest of the 2to3 code. This patch seems to fix the issue without affecting performance.

----------
nosy: +gboutsioukis
Added file: http://bugs.python.org/file16889/output_lock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Mon Apr 12 04:01:48 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 12 Apr 2010 02:01:48 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1271037708.58.0.840994260197.issue7370@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Instead of ?email.utils.formatdate(time, usegmt=True)? we can simply use time.strftime() and clean the code in a better way. The duplication is there in date_time_string() as well as log_date_time_string(). Submitting the patch for review.

----------
nosy: +l0nwlf
Added file: http://bugs.python.org/file16890/BaseHTTPServer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Apr 12 06:55:53 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 12 Apr 2010 04:55:53 +0000
Subject: [issue5250] Document __instancecheck__ and __subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1271048153.99.0.297823257081.issue5250@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________

From report at bugs.python.org  Mon Apr 12 07:11:02 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Apr 2010 05:11:02 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271049062.18.0.00751937534362.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

With respect to msg98314 (http://bugs.python.org/msg98314) referenced in this bug, which I thought is easy to handle, does not appear so. It is bit tricky.

The problem is the relative url is given of the format '07.11.2009-9:54:12-1.jpg' and urlparse wrongly assumes that it is VALID url with the scheme as 07.11.2009-9 ( Surprisingly, this falls under valid characters for a URL Scheme, but we know that there no url scheme like that).

But when you give ./07.11.2009-9, ./ is identified a relative path and urljoin happens properly. 

My inclination for this specific msg9814, is the allow the user to give the proper path like ./07.11.2009-9 or use urljoin from different directory, images/07.11.2009-9 and this should handle it.

This date-time relative url is not a typical scenario, but for  typical scnerios, urlparse behaves as expected.

>>> x = 'http://a.b.c'
>>> urlparse.urljoin(x,'foo')
'http://a.b.c/foo'
>>> urlparse.urljoin(x,'./foo')
'http://a.b.c/foo'
>>> 

I shall provide my comments on the IPv6 parse in next msg.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Mon Apr 12 07:14:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 12 Apr 2010 05:14:40 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1271049280.39.0.306078338089.issue8279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch in file16727 was applied as part of issue8316.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8279>
_______________________________________

From report at bugs.python.org  Mon Apr 12 07:23:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 12 Apr 2010 05:23:32 +0000
Subject: [issue8330] Failures seen in test_gdb on buildbots
In-Reply-To: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>
Message-ID: <1271049812.5.0.658104622657.issue8330@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now applied file16808 as r79986. I'm detaching file16804, as it was superceded by the other patch. I also reenabled all tests in r79987, to see how the buildbots react.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8330>
_______________________________________

From report at bugs.python.org  Mon Apr 12 08:22:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Apr 2010 06:22:44 +0000
Subject: [issue8026] strftime bug when timedelta is negative
In-Reply-To: <1267206102.75.0.187323607292.issue8026@psf.upfronthosting.co.za>
Message-ID: <1271053364.23.0.174536739461.issue8026@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8026>
_______________________________________

From report at bugs.python.org  Mon Apr 12 08:35:58 2010
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 12 Apr 2010 06:35:58 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

The Python tutorial offers some dangerous advice about adding iterator behavior to a class:
http://docs.python.org/tutorial/classes.html#iterators
?By now you have probably noticed that most container objects can be looped over using a for statement:
?
Having seen the mechanics behind the iterator protocol, it is easy to add iterator behavior to your classes. Define a __iter__() method which returns an object with a next() method. If the class defines next(), then __iter__() can just return self:?

This is reasonable advice for writing an iterator class, but terrible advice for writing a container class, because it encourages you to associate a single iterator with the container, which breaks nested iteration and leads to hard-to-find bugs.  (One of those bugs recently made its way into the code handout for a problem set in MIT?s introductory CS course, 6.00.)

A container class?s __iter__() should return a generator or an instance of a separate iterator class, not self.  The tutorial should make this clearer.

----------
assignee: georg.brandl
components: Documentation
messages: 102918
nosy: andersk, georg.brandl
severity: normal
status: open
title: Tutorial offers dangerous advice about iterators: ?__iter__() can just return self?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 08:36:20 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 12 Apr 2010 06:36:20 +0000
Subject: [issue5250] Document __instancecheck__ and __subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1271054180.39.0.309908619545.issue5250@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Here's a draft of an updated version of the "Data model" docs reflecting the changes in the PEP.

----------
keywords: +patch
type:  -> feature request
Added file: http://bugs.python.org/file16891/datamodel.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________

From report at bugs.python.org  Mon Apr 12 08:42:08 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Apr 2010 06:42:08 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271054528.86.0.912962444229.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

After spending a sufficient amount of time looking at patches and the RFC 2732, I tend to agree with the patch provided by tlocke. It does cover the behavior for parsing IPv6 URL with '[' hostname ']'. RFC 2732 is very short and just says that hostname in the IPv6 should not have '[' and ']' characters. The patch does just that, which is fine.

If hard pressed on detecting invalid IPv6 , I would add and extra 

+        if "[" in netloc and "]" in netloc:
+                return netloc.split("]")[0][1:].lower()
+        elif "[" in netloc or "]" in netloc:
+                raise ValueError("Invalid IPv6 URL")

Which should take care of Invalid IPv6 urls as discussed in this bug.

- Any comments on this?

Also regarding the urlparse header docs, (it was long pending on me and sorry), here is a patch for current one for review. When we address this bug, I shall include RFC 2732 as well in the list.

----------
resolution:  -> accepted
Added file: http://bugs.python.org/file16892/urlparse-module-header.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Mon Apr 12 08:45:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Apr 2010 06:45:22 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1271054722.17.0.585969466502.issue7026@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I am unable to reproduce this issue in the trunk/py3k. Buildbots have not complained either. I am closing this bug.
srid: If you have steps to reproduce, feel free to reopen it.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7026>
_______________________________________

From report at bugs.python.org  Mon Apr 12 08:52:44 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 12 Apr 2010 06:52:44 +0000
Subject: [issue5250] Document __instancecheck__ and __subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1271055164.75.0.841392372862.issue5250@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Added file: http://bugs.python.org/file16893/datamodel.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________

From report at bugs.python.org  Mon Apr 12 09:08:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Apr 2010 07:08:10 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1271056090.35.0.182075750538.issue8339@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Added additional examples of valid urls in r79988 and branches under the roundtrip test cases.

Michael, RDM: If you have any comments on msg102737, let me know. Otherwise we can close this issue as wont-fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Mon Apr 12 10:19:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 12 Apr 2010 08:19:32 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271023988.71.0.895984687077.issue8374@psf.upfronthosting.co.za>
Message-ID: <4BC2D7AD.4020201@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> getdefaultlocale is inherently unmaintainable, and shouldn't be used by applications. I wish it was removed from Python (but unfortunately, too many people got tricked into believing that it does something useful).

I disagree on that.

getdefaultlocale() provides a way to access the default locale
(and encoding) on a platform without requiring a call to
setlocale(LC_ALL, "") which would affect the currently running
application and is not thread-safe (just like most other locale
C APIs in the C lib).

getpreferredencoding() just provides encoding information. It doesn't
provide locale information, so I don't see how that could be used
as replacement for getdefaultlocale().

The table needed for normalizing the various locale strings used in
the LANG environment variable (and others) needs to be updated every
now and then, but that's natural for a resource that changes based
on what people use locales for in real life.

> That said, if anybody feels like updating the tables from the various data sources, please go ahead.

I last updated the table in 2008. Will do that again this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 10:25:54 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Apr 2010 08:25:54 +0000
Subject: [issue8375] test_distutils fails when run with -j
In-Reply-To: <1271026981.38.0.880810451818.issue8375@psf.upfronthosting.co.za>
Message-ID: <1271060754.4.0.364411775628.issue8375@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r79992

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8375>
_______________________________________

From report at bugs.python.org  Mon Apr 12 10:38:57 2010
From: report at bugs.python.org (=?utf-8?b?2LnYqNiv2KfZhNmE2Ycg2LTZhNmKIChBYmRlbGxhaCBDaGVsbGkp?=)
Date: Mon, 12 Apr 2010 08:38:57 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1271061537.44.0.781107934278.issue8359@psf.upfronthosting.co.za>


??????? ??? (Abdellah Chelli) <sneetsher at gmail.com> added the comment:

Mapping  works too, I don't know how I didn't get it. Thank you Eric.

Ex:
gettext.ngettext("%(package)d package", "%(package)d packages", countInstall) % { 'package': countInstall}

https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/409785/comments/9

Thank you guys, Eric & Georg.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Mon Apr 12 10:55:28 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 12 Apr 2010 08:55:28 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <4BC2D7AD.4020201@egenix.com>
Message-ID: <4BC2E01A.6090805@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

M.-A. Lemburg wrote:
>> That said, if anybody feels like updating the tables from the various data sources, please go ahead.
> 
> I last updated the table in 2008. Will do that again this week.

I saw that Antoine already did this for me: thanks, Antoine !

Could you tell me which X11 version you used ? I've modified the
generation script to also output the added aliases and would like
to list them as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:02:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Apr 2010 09:02:33 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271062953.59.0.0227343044648.issue8376@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:11:45 2010
From: report at bugs.python.org (Jatin Sanghvi)
Date: Mon, 12 Apr 2010 09:11:45 +0000
Subject: [issue8377] Errata on
	page:http://docs.python.org/library/stdtypes.html
In-Reply-To: <1271063505.25.0.821351537014.issue8377@psf.upfronthosting.co.za>
Message-ID: <1271063505.25.0.821351537014.issue8377@psf.upfronthosting.co.za>


New submission from Jatin Sanghvi <jatin085 at gmail.com>:

Open link: http://docs.python.org/library/stdtypes.html

The statement:

If i or j is negative, the index is relative to the end of the string: len(s) + i or len(s) + j is substituted.

is incorrect, should be:

If i or j is negative, the index is relative to the end of the string: len(s) - i or len(s) - j is substituted.

----------
assignee: georg.brandl
components: Documentation
messages: 102927
nosy: georg.brandl, jatin085
severity: normal
status: open
title: Errata on page:http://docs.python.org/library/stdtypes.html
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8377>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:17:07 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 12 Apr 2010 09:17:07 +0000
Subject: [issue8377] Errata on
	page:http://docs.python.org/library/stdtypes.html
In-Reply-To: <1271063505.25.0.821351537014.issue8377@psf.upfronthosting.co.za>
Message-ID: <1271063827.52.0.855982100582.issue8377@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

This is a common thinko. ;)

If i is negative then len(s) - i would be greater that len(s). However len(s) + i  is correct. Example:

foo[-1] is foo[len(foo) + (-1)] is foo[len(foo)-1]

----------
nosy: +doerwalter
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8377>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:19:13 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Apr 2010 09:19:13 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1271063953.81.0.53698498147.issue3581@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Applied test_uuid3.patch to trunk (r79954), release26-maint (r79959),
py3k (r79960) and release31-maint (r79961).

No buildbot failures so far, so I'm closing this.

----------
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:22:38 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Apr 2010 09:22:38 +0000
Subject: [issue7650] test_uuid is invalid
In-Reply-To: <1262828995.4.0.365764114727.issue7650@psf.upfronthosting.co.za>
Message-ID: <1271064158.44.0.161504696151.issue7650@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Fixed in issue 3581. Thanks for the report and the comments!

----------
assignee:  -> skrah
dependencies: +failures in test_uuid
keywords: +patch
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> failures in test_uuid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7650>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:25:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Apr 2010 09:25:36 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1271064336.25.0.550142254016.issue7370@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nice catch. The patch looks good to me and applies correctly on my trunk copy. There seems to be no test about this in the test suite; do you have a little test script to compare old and new code?

On a sidenote, I find all this business with time.time, time.gmtime, time.localtime and time.strftime always confusing. We have datetime objects now, would it be ok to use them in this module?

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:28:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Apr 2010 09:28:57 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1271064537.01.0.0781133317309.issue8339@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

By the way, I?ve been meaning to file a bug against the Mercurial schemes extension since I saw how it misused URIs (i.e. ?py://trunk/? should be ?py:trunk/?); I hope it?s not too late now that this extension is shipped with the program.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:32:46 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Apr 2010 09:32:46 +0000
Subject: [issue1481] test_uuid is warning about unreliable functions
In-Reply-To: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za>
Message-ID: <1271064766.55.0.0382049085598.issue1481@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Issue fixed by test_uuid3.patch from issue 3581 in trunk (r79954),
release26-maint (r79959), py3k (r79960) and release31-maint (r79961).

----------
assignee:  -> skrah
keywords:  -needs review
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:44:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Apr 2010 09:44:29 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1271065469.13.0.919698043235.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi

r79951 fixes ?simplies? and add the typo ?specifyication? <Muphry?s Law wink>. Updated my patch to remove that and add this.

Regards

----------
Added file: http://bugs.python.org/file16894/functools-typos-pep8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Mon Apr 12 11:53:12 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Apr 2010 09:53:12 +0000
Subject: [issue4639] Build failure on OpenBSD 4.4-current regarding lstat()
In-Reply-To: <1229091079.2.0.148699699558.issue4639@psf.upfronthosting.co.za>
Message-ID: <1271065992.57.0.769953723899.issue4639@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This has been fixed in issue 7903.

----------
assignee:  -> skrah
keywords: +patch
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Configure script incorrect for reasonably recent OpenBSD

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4639>
_______________________________________

From report at bugs.python.org  Mon Apr 12 12:57:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Apr 2010 10:57:49 +0000
Subject: [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
Message-ID: <1271069869.81.0.691424486077.issue1818@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also this python-ideas thread: http://mail.python.org/pipermail/python-ideas/2010-April/006991.html

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1818>
_______________________________________

From report at bugs.python.org  Mon Apr 12 13:38:27 2010
From: report at bugs.python.org (George Boutsioukis)
Date: Mon, 12 Apr 2010 11:38:27 +0000
Subject: [issue6409] 2to3 -j 4 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1271072307.53.0.381785302098.issue6409@psf.upfronthosting.co.za>


Changes by George Boutsioukis <gboutsioukis at gmail.com>:


Removed file: http://bugs.python.org/file16889/output_lock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Mon Apr 12 13:47:46 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Apr 2010 11:47:46 +0000
Subject: [issue8371] Add a command to download distributions
In-Reply-To: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za>
Message-ID: <1271072866.2.0.656716814119.issue8371@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

What would this command do precisely ? Are you thinking about a command that scans PyPI ?

why this would be a command btw ? downloading a distribution is not a final goal, imho.

Wouldn't it be simpler to have a simple function that provides this feature ? 

> Is it okay to post this as a bug or should I rather mail distutils-sig first? Or mail them now?


A feature request on the distutils2 component is fine. Although for topics that needs discussion, a round in the Mailing list is probably better to start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8371>
_______________________________________

From report at bugs.python.org  Mon Apr 12 13:49:10 2010
From: report at bugs.python.org (George Boutsioukis)
Date: Mon, 12 Apr 2010 11:49:10 +0000
Subject: [issue6409] 2to3 -j 4 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1271072950.93.0.457144774132.issue6409@psf.upfronthosting.co.za>


George Boutsioukis <gboutsioukis at gmail.com> added the comment:

I updated the patch to keep the new code as local as possible.

----------
Added file: http://bugs.python.org/file16895/output_lock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Mon Apr 12 13:50:57 2010
From: report at bugs.python.org (Michael Glassford)
Date: Mon, 12 Apr 2010 11:50:57 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1271073057.05.0.615685762358.issue8339@psf.upfronthosting.co.za>


Michael Glassford <glassfordmjg at gmail.com> added the comment:

> In those cases, I would assume that 'x://y', x:/y','x:/','/' 
> as valid URLS, but not the two examples you mentioned.

Only 2 comments about this:
1) Although the urlparse documentation does mention the relevant RFCs, on a quick read-through I don't see that it actually requires its input to be a valid URL.
2) Obviously, some code is using it for invalid URLs.

> Michael, RDM: If you have any comments on msg102737, 
> let me know. Otherwise we can close this issue as wont-fix.

I don't have a problem with this. I reported the issue to bring attention to the fact that the change affected real code and to see if anyone had suggestions for dealing with the problem in a better way (at the moment, I don't).

> By the way, I?ve been meaning to file a bug against the 
> Mercurial schemes extension...

Please do. I don't have anything to do with the Schemes extension except that I found this issue while investigating a unit test failure, but if you file an issue probably I will look into it--or if I don't, then someone else probably will.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Mon Apr 12 14:25:19 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Apr 2010 12:25:19 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1271073057.05.0.615685762358.issue8339@psf.upfronthosting.co.za>
Message-ID: <20100412122505.GA29009@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Mon, Apr 12, 2010 at 11:50:57AM +0000, Michael Glassford wrote:
> 1) Although the urlparse documentation does mention the relevant RFCs, on a quick read-through I don't see that it actually requires its input to be a valid URL.
> 2) Obviously, some code is using it for invalid URLs.

Which is true, because in some cases like urlparse.urljoin(base, rel),
the rel is a relative url it undergoes the same parsing mechanism
applicable to any url and thus there is no way a 'rigorous' check for
authorized url is happening. 

Checks are done for valid chars in scheme and other parsing
behaviours.

> I don't have a problem with this. I reported the issue to bring attention to the fact that the change affected real code and to see if anyone had suggestions for dealing with the problem in a better way (at the moment, I don't).
>

Yeah, I understand the situation with 'changes which break the
existing code', which we try to avoid many times. I shall if this can
be addressed without reverting any recent changes and still being
complaint.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Mon Apr 12 14:44:00 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Apr 2010 12:44:00 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1271015036.58.0.946906137681.issue2054@psf.upfronthosting.co.za>
Message-ID: <20100412124348.GD29009@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Apr 11, 2010 at 07:43:56PM +0000, ?ric Araujo wrote:
> httplib.Client, ftplib.Client, ftplib.SecureClient would be much more descriptive than httplib.HTTP and ftplib.FTP. Any interest about adding aliases?

Aliases would be a bad idea. -1. It is fine the way the issue is
moving forth now, FTP_TLS.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Mon Apr 12 14:48:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Apr 2010 12:48:37 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <4BC2E01A.6090805@egenix.com>
Message-ID: <1271076639.3846.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Could you tell me which X11 version you used ? I've modified the
> generation script to also output the added aliases and would like
> to list them as well.

It's the file supplied on my Mandriva system, from
libx11-1.2.2-2mdv2010.0.src.rpm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 14:49:11 2010
From: report at bugs.python.org (John Van Praag)
Date: Mon, 12 Apr 2010 12:49:11 +0000
Subject: [issue8378] PYTHONSTARTUP broken on Windows
In-Reply-To: <1271076551.49.0.597917544476.issue8378@psf.upfronthosting.co.za>
Message-ID: <1271076551.49.0.597917544476.issue8378@psf.upfronthosting.co.za>


New submission from John Van Praag <john at jvp247.com>:

The PYTHONSTARTUP environment variable does not work--does not import the indicated startup file--when IDLE is started under Windows. I have tested under Windows XP SP2, and under Windows Vista Ultimate 64 bit.

The os.environ variable does list the startup file, but IDLE fails to run it.

----------
messages: 102943
nosy: jvanpraag
severity: normal
status: open
title: PYTHONSTARTUP broken on Windows
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8378>
_______________________________________

From orsenthil at gmail.com  Mon Apr 12 14:43:48 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 12 Apr 2010 18:13:48 +0530
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1271015036.58.0.946906137681.issue2054@psf.upfronthosting.co.za>
References: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
	<1271015036.58.0.946906137681.issue2054@psf.upfronthosting.co.za>
Message-ID: <20100412124348.GD29009@remy>

On Sun, Apr 11, 2010 at 07:43:56PM +0000, ?ric Araujo wrote:
> httplib.Client, ftplib.Client, ftplib.SecureClient would be much more descriptive than httplib.HTTP and ftplib.FTP. Any interest about adding aliases?

Aliases would be a bad idea. -1. It is fine the way the issue is
moving forth now, FTP_TLS.

From report at bugs.python.org  Mon Apr 12 15:05:29 2010
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Mon, 12 Apr 2010 13:05:29 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271077529.37.0.670361026348.issue8374@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

That nl_AW is an interesting one. Aruba is part of the Kingdom of the Netherlands, so in essence it should follow nl_NL. From what I can see that locale seems to be limited to (certain) Linux systems. I'll raise the issue with the CLDR guys as well, since I wonder if this warrants its own locale or not (some monetary and number formatting).

But I think the outcome will be to add a nl_AW as well in similar vein as to what bo_CN does.

----------
nosy: +asmodai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 15:25:38 2010
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 12 Apr 2010 13:25:38 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1271078738.12.0.402826616591.issue7150@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Can someone update this issue ? Is the 2nd patch tested... ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Mon Apr 12 15:31:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 13:31:11 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1271079071.11.0.912759352819.issue7370@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There are a couple problems with this patch.  The first is that fixing date_time_string by using strftime rather than email.utils.formatdate is suboptimal from a code reuse standpoint.  The reason is that the date in HTTP message headers is required to conform to the same RFC standard as that generated by formatdate, so it is better to use the same routine to generate it.  That way any bug fixes needed to handle RFC compliance are centralized in once place.

The second problem with the patch is that strftime generates locale-aware week and month names, but per RFC the header timestamps must use English names (see for example msg53731 in issue 665194; the comment about locale applies to both strftime and strptime).

If issue 665194 were implemented formatdate could use it, and then BaseHTTPServer could also use it directly.  But absent that it should use email.util.formatdate.  (That issue should also answer ?ric's question about whether we can use DateTime here: not yet.)

Now, the logging routine is a different story.  That timestamp isn't required to follow the RFC, and one could argue that it makes sense for its timestamp to use the locale.  (One could also ask whether BaseHTTPServer should use the logging module, but that is a whole separate issue.)

We definitely should have a unit test before applying this patch, that makes sure the timestamp gets generated without error.  Checking the detailed format of the timestamp can be assumed to be covered by the unit tests for formatdate.  (I don't think those tests are completely adequate; for example they don't test that the date remains in English if the locale is different, but again that is a different issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Apr 12 15:33:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Apr 2010 13:33:51 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1271079071.11.0.912759352819.issue7370@psf.upfronthosting.co.za>
Message-ID: <4BC3213C.10709@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

?One could also ask whether BaseHTTPServer should use the logging 
module, but that is a whole separate issue.?
Indeed: http://www.python.org/dev/peps/pep-0337/

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Apr 12 15:57:42 2010
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 12 Apr 2010 13:57:42 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1271080662.69.0.986238609276.issue8319@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


----------
nosy: +pythonhacker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8319>
_______________________________________

From report at bugs.python.org  Mon Apr 12 16:13:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 12 Apr 2010 14:13:56 +0000
Subject: [issue8378] PYTHONSTARTUP broken on Windows
In-Reply-To: <1271076551.49.0.597917544476.issue8378@psf.upfronthosting.co.za>
Message-ID: <1271081636.41.0.204616951811.issue8378@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +IDLE, Windows
nosy: +brian.curtin
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8378>
_______________________________________

From report at bugs.python.org  Mon Apr 12 16:35:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Apr 2010 14:35:34 +0000
Subject: [issue8026] strftime bug when timedelta is negative
In-Reply-To: <1267206102.75.0.187323607292.issue8026@psf.upfronthosting.co.za>
Message-ID: <1271082934.89.0.495719114642.issue8026@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is not a bug.  The issue boils down to the following:

>>> from datetime import *
>>> d = datetime(2010, 1, 1)
>>> d, d.strftime("%G")
(datetime.datetime(2010, 1, 1, 0, 0), '2009')

and OP expects '2010' instead.  Python behavior is correct as can be verified using GNU date utility:

$ date --date=20100101 +%G
2009

The confusion comes from the fact that %G is formatted as the ISO 8601 year.  This year is the one that contains the greater part of the week (Monday as the first day of the week).


Here is another illustration:
>>> d = date(2009,12,31)
>>> for i in range(7):
...    (d+timedelta(i)).strftime("%F %a %G %V")
... 
'2009-12-31 Thu 2009 53'
'2010-01-01 Fri 2009 53'
'2010-01-02 Sat 2009 53'
'2010-01-03 Sun 2009 53'
'2010-01-04 Mon 2010 01'
'2010-01-05 Tue 2010 01'
'2010-01-06 Wed 2010 01'

Note that week 1 of 2010 started on Monday, 2010-01-04.

OP is advised to change %G to %Y in his code.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8026>
_______________________________________

From report at bugs.python.org  Mon Apr 12 16:36:23 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 12 Apr 2010 14:36:23 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271082983.38.0.121491674729.issue8376@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 16:53:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 14:53:34 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1271084014.93.0.354855539963.issue7472@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've applied the fix to trunk in r79994, and py3k in r79996, but I'm leaving this open because I still want a unit test for it.

----------
keywords: +easy -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7472>
_______________________________________

From report at bugs.python.org  Mon Apr 12 16:54:52 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Apr 2010 14:54:52 +0000
Subject: [issue8026] strftime bug when timedelta is negative
In-Reply-To: <1267206102.75.0.187323607292.issue8026@psf.upfronthosting.co.za>
Message-ID: <1271084092.3.0.918230853445.issue8026@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8026>
_______________________________________

From report at bugs.python.org  Mon Apr 12 17:02:50 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Apr 2010 15:02:50 +0000
Subject: [issue6467] PyOS_Readline: treatment of "1234EOF";
	behavior of builtin_raw_input
In-Reply-To: <1247399845.7.0.918611986455.issue6467@psf.upfronthosting.co.za>
Message-ID: <1271084570.61.0.8582598394.issue6467@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

There are two cases:

1) stdin and stdout go to a tty:

my_fgets() from Parser/myreadline.c does not handle the case
where fgets() reads some characters followed by an EOF. One
way to deal with this is to consider a sequence like 1234EOF
an empty line.

This is what the patch consider_1234EOF_empty_line.patch
does and it fixes problem 1.

[Another option would be to consider 1234EOF a line and
insert a newline.]


2) stdout is not a tty:

In this case, builtin_raw_input() uses PyFile_GetLine() to
read from stdin. I'm not sure why this is the case.

Perhaps 2) should be a separate issue.

----------
components: +Interpreter Core -IO
keywords: +needs review, patch
nosy: +skrah
priority:  -> normal
stage:  -> patch review
title: raw_input() doesn't work as expected when it gets multiple ^D -> PyOS_Readline: treatment of "1234EOF"; behavior of builtin_raw_input
type:  -> behavior
Added file: http://bugs.python.org/file16896/consider_1234EOF_empty_line.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6467>
_______________________________________

From report at bugs.python.org  Mon Apr 12 17:09:28 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 12 Apr 2010 15:09:28 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271084968.84.0.176807120772.issue8376@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

I think there is not much ploblem. Please notice this sentence in the previous paragraph in the toturial :

"Behind the scenes, the for statement calls iter() on the container object. The function returns an iterator object that defines the method next() which accesses elements in the container one at a time."

I think it's clear enough that the container object is different from the iterator object, what exactly has the iterator behavior is the iterator object, not the container object. And this sentence you mentioned:

"If the class defines next(), then __iter__() can just return self:"

is to teach you define a iterator, not a container. So by reading it carefully, you won't define something that is both a container and a iterator, will you? 

If you really define a next() on a class which you want it be a container, and then define a __iter__() on it and return self, then your container is exactly a generator, not a container. And a generator can certainly iterate only once.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 17:15:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 15:15:14 +0000
Subject: [issue8378] PYTHONSTARTUP is not run by default when Idle is started
In-Reply-To: <1271076551.49.0.597917544476.issue8378@psf.upfronthosting.co.za>
Message-ID: <1271085314.01.0.379988470144.issue8378@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Believe it or not, this is the documented behavior of Idle on all platforms.  You have to specify -s to have PYTHONSTARTUP run.

See the last comment in Issue5594, and also the referenced issue 5233, which has a patch that apparently changes this behavior, although that isn't mentioned in that issue itself.

I'm making this a feature request for changing the default behavior, to see what people think.

----------
components:  -Windows
nosy: +kbk, r.david.murray
title: PYTHONSTARTUP broken on Windows -> PYTHONSTARTUP is not run by default when Idle is started
type: behavior -> feature request
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8378>
_______________________________________

From report at bugs.python.org  Mon Apr 12 17:30:43 2010
From: report at bugs.python.org (David Coconut)
Date: Mon, 12 Apr 2010 15:30:43 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1271086243.93.0.39527645801.issue8326@psf.upfronthosting.co.za>


David Coconut <coconut at redbrick.dcu.ie> added the comment:

Issue 3770 is not relevant because this code works in Python 2.6 on both machines (x86 and x86-64). These machines run plenty of other concurrent processes also, which would imply to me that sem_open() does work.

I could be completely wrong as I'm no expert on the inner workings of either Python or Ubuntu, but that's what I've been able to deduce so far.

Ubuntu bug in package python3.1 is here: https://bugs.launchpad.net/ubuntu/+source/python3.1/+bug/556477

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Mon Apr 12 17:37:52 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Apr 2010 15:37:52 +0000
Subject: [issue8367] test_winsound: failure on systems without soundcard
In-Reply-To: <1270980470.8.0.919577975963.issue8367@psf.upfronthosting.co.za>
Message-ID: <1271086672.69.0.441860931943.issue8367@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed in r80000, r80001, r80002 and r80003.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8367>
_______________________________________

From report at bugs.python.org  Mon Apr 12 17:47:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Apr 2010 15:47:21 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271084968.84.0.176807120772.issue8376@psf.upfronthosting.co.za>
Message-ID: <4BC34085.7010200@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I thought about two bits in your message: ?I think it's clear enough? 
and ?So by reading it carefully?. They show that the doc is a bit 
ambiguous here, and while I agree that people should take the time to 
read and understand, I think that documentation can always be made 
clearer. The doc about iterables could tell to return an instance of 
another class or use a generator, and then a separate paragraph would 
explain about using next to define iterators, explaining that iterators 
may or may not be iterable.

Does that sound good?

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 18:14:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Apr 2010 16:14:16 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271088856.36.0.627393478427.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Is there a good reason why this issue is languishing? The requested functionality seems to be well motivated, simple to implement with few objections resolved in the discussion.

I wonder if it would be helpful to limit this patch to 3.x series.  That way some of the controversies about true vs. floor division would disappear and it will be easier to accept new features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 12 18:54:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 16:54:37 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1271091277.41.0.247827561357.issue8326@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I guess I wasn't clear.  The error you are seeing is exactly the error that issue 3770 talks about.  The *build* process wasn't able to find a functioning sem_open implementation, and therefore you see that error.  Now, clearly your platform does have a functioning sem_open implementation, so something must have gone wrong during the build process.  Since the build works fine on our Ubuntu buildbots (http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.1/builds/475), and since you are working from a prepackaged Lucid binary, I conclude that this is most likely an Ubuntu packaging problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Mon Apr 12 18:59:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 16:59:48 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1271091588.47.0.685735683163.issue7585@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied to trunk in r8004 and py3k in r8006.

----------
resolution: accepted -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Mon Apr 12 19:08:28 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 12 Apr 2010 17:08:28 +0000
Subject: [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
Message-ID: <1271092108.69.0.836318693102.issue1818@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Type conversion is a whole 'nuther kettle of fish.  This particular thread is long and complex enough that it shouldn't be made more complex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1818>
_______________________________________

From report at bugs.python.org  Mon Apr 12 19:14:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Apr 2010 17:14:29 +0000
Subject: [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: <1271092469.87.0.574860206819.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch fixing more issues about undecodable filenames.

 Lib/test/test_subprocess.py |    4 -
 Lib/unittest/runner.py      |    4 +
 Modules/_posixsubprocess.c  |   21 ++++++++--
 Modules/getpath.c           |   90 +++++++++++++++++++++++++++++++++++++++-----
 Modules/posixmodule.c       |    5 +-
 Modules/python.c            |    6 +-
 Modules/zipimport.c         |   11 ++++-
 Objects/fileobject.c        |    6 +-
 Objects/unicodeobject.c     |   22 ++++++++--
 Parser/tokenizer.c          |   14 ++++--
 Python/_warnings.c          |    7 +++
 Python/ast.c                |   10 +++-
 Python/ceval.c              |    2
 Python/errors.c             |    2
 Python/import.c             |   37 +++++++++++++-----
 Python/traceback.c          |   38 ++++++++++++++----
 16 files changed, 225 insertions(+), 54 deletions(-)

TODO:
 - Remove assert(PyBytes_Check(opath)); from NullImporter_init() and zipimporter_init()
 - Fix setup_context() (_warnings.c)
 - Reencode module filenames if the system default encoding changes
 - Lib/unittest/runner.py and Lib/test/test_subprocess.py contain hacks to fix tests. It might be rewritten
 - Fix the 3 "FIXME: use _Py_char2wchar" in getpath.c

I restored code setting the system encoding.

The patch fixes also _posixsubprocess.fork_exec() to support undecodable current working directory.

----------
Added file: http://bugs.python.org/file16897/surrogates-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Mon Apr 12 19:20:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Apr 2010 17:20:54 +0000
Subject: [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: <1271092854.93.0.236884629772.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed 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  Mon Apr 12 19:24:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 17:24:05 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271093045.27.0.901934425307.issue8376@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It might be worth mentioning in the tutorial the specific problem the OP points out: that if an object returns itself in __iter__, then that object can have only one iteration state.  And that therefor only an object that is itself a unique iterator (as opposed to a collection wanting to allow iteration) should return itself as __iter__.

Also note that in the example in the tutorial it says "easy to add the behavior", which *in context* is wrong; pedagogically the better thing to do would be to say "it is easy to write a class that implements an iterator".  As ?ric said, splitting the text so that returning an iterator from a collection and constructing an iterator class are distinct topics would greatly improve the exposition.

I'm an experienced Python coder, and I've made this mistake myself.  Often it doesn't break because the code only iterates the object once, but it would be better to have the tutorial encourage doing this correctly by providing good examples and explanations.

----------
nosy: +r.david.murray
priority:  -> normal
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/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 19:32:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 17:32:24 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271093544.38.0.855769219518.issue2706@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's too late for 2.7 anyway.

----------
nosy: +r.david.murray
priority:  -> normal
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 12 20:08:00 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Apr 2010 18:08:00 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271095680.46.0.103794854952.issue8376@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think the docs are fine as-is.  At that point in the tutorial, we're trying to teach what the iterator protocol is.

The considerations of what makes a good design can be discussed elsewhere.  It is not a one-liner.  For example, files are self iterators but lists are not -- there are good reasons for either choice.  Explaining those design choices is not a good way to *introduce* the iterator protocol.

Recommend closing this report.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 20:08:32 2010
From: report at bugs.python.org (David Watson)
Date: Mon, 12 Apr 2010 18:08:32 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271095712.18.0.624691647332.issue8372@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Attaching the C test programs I forgot to attach yesterday -
sorry about that.  I've also tried these programs, and the
patches, on FreeBSD 5.3 (an old version from late 2004).  I found
that it accepted unterminated addresses as well, and unlike Linux
it did not normally null-terminate addresses at all - the
existing socket code only worked for addresses shorter than
sun_path because it zero-filled the structure beforehand.  The
return-unterminated patches worked with or without the
zero-filling.

Unlike Linux, FreeBSD also accepted oversized sockaddr_un
structures (sun_path longer than its definition), so just
allowing unterminated addresses wouldn't make the full range of
addresses usable there.  That said, I did get a kernel panic
shortly after testing with oversized addresses, so perhaps it's
not a good idea to actually use them :)

----------
Added file: http://bugs.python.org/file16898/bindconn.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Mon Apr 12 20:09:32 2010
From: report at bugs.python.org (David Watson)
Date: Mon, 12 Apr 2010 18:09:32 +0000
Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX
	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271095773.0.0.908056493223.issue8372@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file16899/accept.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8372>
_______________________________________

From report at bugs.python.org  Mon Apr 12 20:11:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 12 Apr 2010 18:11:09 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1271095869.11.0.264921333485.issue1220212@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Ported to py3k in r80008.

FAQ text updated in r80009 and r80010.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Mon Apr 12 20:44:23 2010
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 12 Apr 2010 18:44:23 +0000
Subject: =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dangerous_advice_about_iterator?=
	=?utf-8?b?czog4oCcX19pdGVyX18oKSBjYW4ganVzdCByZXR1cm4gc2VsZuKAnQ==?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271097863.27.0.306228199253.issue8376@psf.upfronthosting.co.za>


Anders Kaseorg <andersk at mit.edu> added the comment:

As an experienced Python programmer I am obviously aware that the tutorial is trying to teach how to make an iterator class, not how to make a container class.

But the tutorial doesn?t make that *clear*.  It should be much more explicit about what it is explaining to avoid confusing those concepts in the minds of beginners.  (Or even the staff of the MIT introductory CS course.)

One way to fix this confusion would be to explain what one should do for both container classes and iterator classes:

"""
Having seen the mechanics behind the iterator protocol, it is easy to add iterator behavior to your container classes.  Define a :meth:`__iter__` method which returns an object of a separate iterator class.  The iterator class should have a :meth:`next` method and an :meth:`__iter__` method (the :meth:`__iter__` method of the iterator class should just return ``self``)::

   class ReverseList(object):
       "Container that lets you iterate over the items backwards"
       def __init__(self, data):
           self.data = data
       def __iter__(self):
           return ReverseIterator(self.data)

   class ReverseIterator(object):
       "Iterator for looping over a sequence backwards"
       def __init__(self, data):
           self.data = data
           self.index = len(data)
       def __iter__(self):
           return self
       def next(self):
           if self.index == 0:
               raise StopIteration
           self.index = self.index - 1
           return self.data[self.index]

   >>> for char in ReverseIterator('spam'):
   ...     print char
   ...
   m
   a
   p
   s
   >>> for char in ReverseList([1,2,3]):
   ...     print char
   ...
   3
   2
   1
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8376>
_______________________________________

From report at bugs.python.org  Mon Apr 12 21:06:52 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 12 Apr 2010 19:06:52 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1271099212.7.0.895999575207.issue7370@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Quoting from the docstring of trunk/Lib/email/utils.py -> formatdate()

"We cannot use strftime() because that honors the locale and RFC 2822 requires that day and month names be the English abbreviations."

So yes, I do agree that email.utils.formatdate() should be used instead of time.strftime() to remove duplicate codes and be compliant with RFC.
Removing previous patch and submitting another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Apr 12 21:07:12 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 12 Apr 2010 19:07:12 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1271099232.31.0.423156414562.issue7370@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


Removed file: http://bugs.python.org/file16890/BaseHTTPServer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Apr 12 22:00:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Apr 2010 20:00:59 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1271102459.85.0.695989183788.issue7947@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7947>
_______________________________________

From report at bugs.python.org  Mon Apr 12 22:02:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Apr 2010 20:02:16 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1271102536.32.0.884874945465.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Many thanks for the patch.

Applied (minus trailing whitespace :) in r80013.

Leaving open to remind me to merge to other branches.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Mon Apr 12 22:09:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 12 Apr 2010 20:09:27 +0000
Subject: [issue8374] Some locales are unsupported
In-Reply-To: <4BC2D7AD.4020201@egenix.com>
Message-ID: <4BC37DF2.8060702@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> getdefaultlocale() provides a way to access the default locale
> (and encoding) on a platform without requiring a call to
> setlocale(LC_ALL, "")

That's what it's meant to do, but this is not what it actually does.
In fact, there is no way of determining the locale's encoding without
the help o fthe C library. As for "default locale": this is a flawed
notion in itself. If I use one locale for messages, and the other for
date representation - which one should be the "default" locale?
Also, "default" in what respect?

> getpreferredencoding() just provides encoding information. It doesn't
> provide locale information, so I don't see how that could be used
> as replacement for getdefaultlocale().

Many applications use getdefaultlocale()[1], i.e. ignore the locale part
of the result. They can easily be rewritten to use getpreferredencoding.

> The table needed for normalizing the various locale strings used in
> the LANG environment variable (and others) needs to be updated every
> now and then, but that's natural for a resource that changes based
> on what people use locales for in real life.

However, it also changes based on local administrator preferences -
something that the implementation does not take into account at all.
It may also depend on OS vendor preferences, which is also not
considered in the implementation.

IOW, it returns bogus results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8374>
_______________________________________

From report at bugs.python.org  Mon Apr 12 22:36:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Apr 2010 20:36:03 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1271104563.29.0.0543536834815.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  I note that the examples are for a big-endian machine.  I wonder whether they should be converted to little-endian, given that most users are on x86 or x86_64 hardware these days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Mon Apr 12 22:39:39 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Apr 2010 20:39:39 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1271104779.75.0.259704400092.issue7355@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> wonder whether they should be converted to little-endian

I thought about that as well.  It sure would make creating new examples easier :)  I had to construct the new examples "by hand".

I can regenerate the examples for little-endian if you would like?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Mon Apr 12 22:51:55 2010
From: report at bugs.python.org (Forest Wilkinson)
Date: Mon, 12 Apr 2010 20:51:55 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1271105515.74.0.480213094477.issue3143@psf.upfronthosting.co.za>


Forest Wilkinson <forest at users.sourceforge.net> added the comment:

I just noticed Ezio's change to the title of this bug.  Does the proposed fix address the original bug title ("docs waste a lot of horizontal space on left nav bar") for third-party packages that use docutils to generate their docs?  Or, does it only avoid the problem in the official python documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Mon Apr 12 22:59:54 2010
From: report at bugs.python.org (lasizoillo)
Date: Mon, 12 Apr 2010 20:59:54 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1271105994.53.0.0416366305599.issue6692@psf.upfronthosting.co.za>


Changes by lasizoillo <lasizoillo at gmail.com>:


----------
nosy: +lasizoillo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:01:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 12 Apr 2010 21:01:56 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1271106116.42.0.968575338003.issue6692@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:08:14 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 12 Apr 2010 21:08:14 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1271106494.68.0.857312740065.issue7370@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


Added file: http://bugs.python.org/file16900/BaseHTTPServer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:09:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Apr 2010 21:09:04 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1271106544.82.0.688929691223.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sure, if you want to.  [Then I won't be able to reproduce what's in the docs on either of my machines. :)  One's 32-bit big-endian;  the other's 64-bit little-endian.]

Merged your changes and subsequent tweaks to py3k in r80016.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:12:29 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Apr 2010 21:12:29 +0000
Subject: [issue6409] 2to3 -j 4 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1271106749.22.0.519862213579.issue6409@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80018. Thanks for the patch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:34:07 2010
From: report at bugs.python.org (Andy Friesen)
Date: Mon, 12 Apr 2010 21:34:07 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>


New submission from Andy Friesen <andy at imvu.com>:

In certain circumstances, "if __debug__" seems to be evaluating its "else" clause even when -O is not specified.  This can cause very  surprising behavior.

a.zip contains a single file named a/__init__.pyo.  It is the compiled form of the following code:

    if __debug__:
        print 'DEBUG'
    else:
        print 'RELEASE'
        if __debug__ == True:
            raise Exception("this is impossible")

pythonbug.py evaluates this script with the following:

    import sys
    sys.path = ['a.zip']
    import a

When using Windows Python 2.6.2 and 2.6.5, running pythonbug.py produces this output:

    RELEASE
    Traceback (most recent call last):
      File "pythonbug.py", line 3, in <module>
        import a
      File "__init__.py", line 8, in <module>
        raise Exception("this is impossible")
    Exception: this is impossible

When -O is passed, the exception is not raised.

My best guess is that the Python bytecode is optimizing the "if __debug__" test away in the produced .pyo, but does not actually affect the value of __debug__ or check more complex expressions involving __debug__.

----------
files: pythonbug.zip
messages: 102975
nosy: afriesen
severity: normal
status: open
title: if __debug__: has nonobvious behaviour when evaluating .pyo without -O
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16901/pythonbug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:48:45 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 12 Apr 2010 21:48:45 +0000
Subject: [issue5277] email message.get_params() and related methods sometimes
	fail.
In-Reply-To: <1234758915.75.0.150242965655.issue5277@psf.upfronthosting.co.za>
Message-ID: <1271108925.92.0.573095808926.issue5277@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

According to RFC2231 the named disposition (content disposition field) is provided by the MIME mechanism. The encoded parameter like the following:

Content-Disposition: inline;
 filename*0="Re: [Mailman-Users] Messages shunted with \"TypeError: ";
 filename*1="decodingUnicode is not supported\".eml"

is not behaving the way it should be.
The patch by rcoyner seems fine to me as it rectifies the wrong behaviour of _parseparam i.e. the counting issue of nested 'double quotes' and clears the unit tests.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5277>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:52:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Apr 2010 21:52:38 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1271109158.87.0.203043434302.issue3143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm pretty sure it only applies to the python docs, since this is the Python tracker, not the Sphinx or docutils tracker.  (I'm not sure how the 'Documentation tools (Sphinx)' component gets in there...as far as I know Sphinx bugs go the Sphinx bug tracker.)

----------
nosy: +r.david.murray
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Mon Apr 12 23:55:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Apr 2010 21:55:18 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271109318.67.0.163445964945.issue8379@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's probably caused by optimizations in the peepholer indeed.

----------
nosy: +pitrou, rhettinger
priority:  -> low
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:00:06 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Apr 2010 22:00:06 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271109606.03.0.171426800641.issue8379@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Your assessment of what is going on, Andy, is correct; the peephole optimizer for bytecode optimizes away the `if __debug__` section of the `if` statement for .pyo files.

But that is actually a reasonable thing for the compiler to do as you are not supposed to run optimized bytecode with the interpreter not running under -O. Running a .pyo file under an interpreter run w/o -O is like compiling for 64-bit but then running on a 32-bit system; you are not following assumptions you told the compiler could be made about the runtime.

So I am closing this as 'wont fix'. Best solution is to simply not run bytecode directly and instead execute the source as bytecode should be treated more as an optimization than some directly executable file format. But if you must execute the bytecode directly, simply make sure you don't mix .pyo/.pyc with an improper setting of -O.

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:09:33 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 12 Apr 2010 22:09:33 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I'm attaching a patch for the py3k branch to port the gdb hooks to Python 3.

The libpython.py code installed to python-gdb.py "knows" about the internal details of the Python within the tree.  This patch makes the necessary changes to that code for the internals of Python 3, rather than Python 2.

Note that libpython.py is intended to run inside a gdb linked against libpython2, and so libpython.py is still Python 2 code; however I've updated it to expect the so-called "inferior process" to be Python 3:
* Py_TPFLAGS_STRING_SUBCLASS becomes Py_TPFLAGS_BYTES_SUBCLASS
* PyStringObjectPtr becomes PyBytesObjectPtr
* change PyObjectPtr to correctly locate "ob_size": with Python 2 variable-sized subclasses we could simply look it up as a field of the subclass struct, but for Python 3 the field may be in an ob_base member, or in an ob_base.ob_base member.  We have to cast to a PyVarObject* to find it
* PyIntObject went away; PyBoolObject is now a subclass of PyLongObject
* writing out frames needed a slight rewrite with the change from co_filename and co_name from PyStringObject* to PyUnicodeObject*

This makes the "proxy values" concept a bit awkward; for example a "str" in the inferior Python 3 process looks like a "unicode" to the gdb Python 2 process.  This and the int->long change required a lot of minor updating to expected values in the selftests.

The test_gdb.py and gdb_sample.py code _are_ for Python 3.  I've assumed that all output is in UTF-8 for now.

For Python 2, I was testing the code by putting a breakpoint on PyObject_Print, and printing objects, as a convenient hook for scraping gdb's stdout.

PyObject_Print still exists in Python 3, but isn't used by the "print" implementation, so I needed a handy function that I could put a breakpoint on, and invoke from the Python side: I looked for something with METH_O that isn't called by site.py and doesn't require an import.  I chose the "id" builtin, which corresponds to Python/ceval.c:builtin_id ()

Some minor 2to3-style fixes were also needed in the test code

All of the selftests are currently commented out to keep the buildbot clean (apparently from a merge from trunk), and I've kept them commented out.  They all pass on my machine with:
  make -j4 ; ./python -Wd ./Lib/test/regrtest.py -v test_gdb

This also contains a port of the (partial?) fix for issue 8330 from trunk's r79986 that doesn't seem to have been merged to py3k (it needed a fair amount of rewriting).

----------
assignee: loewis
components: Demos and Tools
files: port-gdb7-hooks-to-py3k.patch
keywords: patch
messages: 102980
nosy: dmalcolm, loewis
severity: normal
stage: patch review
status: open
title: Port of the gdb7 debugging hooks to the "py3k" branch
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16902/port-gdb7-hooks-to-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:11:19 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Apr 2010 22:11:19 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1271106544.82.0.688929691223.issue7355@psf.upfronthosting.co.za>
Message-ID: <h2z4095897c1004121511n7de443bepe1cc13ea15b8e0c1@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

> Sure, if you want to.  [Then I won't be able to reproduce what's in the
> docs on either of my machines. :)  One's 32-bit big-endian;  the other's
> 64-bit little-endian.]
>

I guess it's painful either way.  I think the only fair thing to do is
provide examples for multiple scenarios, e.g. 32-bit little-endian, 64-bit
big-endian, etc...  Share the pain :)

Cool, thanks!  Your padding note tweak is a definite improvement over what I
originally had.

----------
Added file: http://bugs.python.org/file16903/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________
-------------- next part --------------
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Sure, if you want to. ??[Then I won&#39;t be able to reproduce what&#39;s in the docs on either of my machines. :) ??One&#39;s 32-bit big-endian; ??the other&#39;s 64-bit little-endian.]<br>
</blockquote><div><br></div><div>I guess it&#39;s painful either way. ??I think the only fair thing to do is provide examples for multiple scenarios, e.g. 32-bit little-endian, 64-bit big-endian, etc... ??Share the pain :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Merged your changes and subsequent tweaks to py3k in r80016.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>Cool, thanks! ??Your padding note tweak is a definite improvement over what I originally had.</div></div><br>

From report at bugs.python.org  Tue Apr 13 00:15:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Apr 2010 22:15:01 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271110501.02.0.29132842946.issue8380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should we call it libpython3.py, in order to distinguish it from the 2.x version?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:19:30 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Apr 2010 22:19:30 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1271110770.11.0.459327203533.issue7355@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Those last two sentences where meant to be in response to your "Merged your changes and subsequent tweaks to py3k in r80016." comment.  I tried to reply to the tracker from my mail client and things got reformatted :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:21:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Apr 2010 22:21:16 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1271110876.76.0.674158437651.issue8314@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It should be ported to py3k, the sparc buildbots still fail there.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8314>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:21:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Apr 2010 22:21:31 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1271110891.01.0.687469913404.issue8314@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8314>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:40:25 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Apr 2010 22:40:25 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271112025.43.0.155290974029.issue4970@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This type of failure appears again in current builds:

http://www.python.org/dev/buildbot/builders/x86 gentoo 3.x/builds/2160/steps/test/logs/stdio

----------
nosy: +skrah
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:44:20 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 12 Apr 2010 22:44:20 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271112260.26.0.899614299059.issue8380@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> Should we call it libpython3.py, in order to distinguish it from the 2.x
> version?

We could; it gets copied to python-gdb.py by the Makefile though.

The code is intended to track the low-level implementation details of the tree that its in, so I'd expect the python 2 and python 3 versions to drift apart over time, FWIW

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Tue Apr 13 00:48:49 2010
From: report at bugs.python.org (Aaron)
Date: Mon, 12 Apr 2010 22:48:49 +0000
Subject: [issue8381] New Window Error
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>


New submission from Aaron <aaron.the.cow at gmail.com>:

When ever I try to open a new window or open a saved file in the IDLE (on a mac) it freezes. I am running snow leppord on a very new mac.

----------
components: IDLE
messages: 102987
nosy: aaron.the.cow
severity: normal
status: open
title: New Window Error
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Tue Apr 13 01:34:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 12 Apr 2010 23:34:58 +0000
Subject: [issue8364] Update site.setquit docstring
In-Reply-To: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>
Message-ID: <1271115298.51.0.469003264611.issue8364@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r80022 and r80023. Thanks.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8364>
_______________________________________

From report at bugs.python.org  Tue Apr 13 01:38:58 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Apr 2010 23:38:58 +0000
Subject: [issue8381] IDLE 2.6 freezes on OS X 10.6
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271115538.14.0.244540139223.issue8381@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This is a duplicate of Issue6864.  The problem is seen with the Apple-supplied IDLE in OS X 10.6 and appears to be an interaction with IDLE 2.6 and the Apple-supplied Cocoa Tk 8.5. One workaround is to install Python 2.6.5 using the python.org OS X installer and use its IDLE which does not exhibit this problem because it is linked with Tk 8.4.  Or, if you can use Python 2.5 instead, you may be OK with Apple's built-in /usr/bin/idle2.5 .

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren
title: New Window Error -> IDLE 2.6 freezes on OS X 10.6
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Tue Apr 13 01:52:46 2010
From: report at bugs.python.org (Timothy Fitz)
Date: Mon, 12 Apr 2010 23:52:46 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271116366.04.0.210785650032.issue8379@psf.upfronthosting.co.za>


Timothy Fitz <timothyfitz at gmail.com> added the comment:

In this case bytecode isn't an optimization, it's a distribution choice (this bug reared it's ugly head in our closed-source downloadable client).

I think that implausible execution paths are still a bug. 

Running a .pyo without -O should be explicitly an error. For instance can we change python to reliably blow up at import time? Or implicitly run as if you added -O?

----------
nosy: +Timothy.Fitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________

From report at bugs.python.org  Tue Apr 13 01:56:53 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Apr 2010 23:56:53 +0000
Subject: [issue8382] cStringIO and StringIO doesn't behave the same way
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Looks like the python version of StringIO can write tuples, but not the C version. I am not sure this is intended:

>>> from cStringIO import StringIO as cStringIO
>>> from StringIO import StringIO as StringIO
>>> string = StringIO()
>>> string.write(('my', 'tuple'))
>>> cstring = cStringIO()
>>> cstring.write(('my', 'tuple'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: write() argument 1 must be string or read-only character buffer, not tuple

----------
components: Library (Lib)
messages: 102991
nosy: tarek
severity: normal
status: open
title: cStringIO and StringIO doesn't behave the same way
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 01:56:59 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Apr 2010 23:56:59 +0000
Subject: [issue8382] cStringIO and StringIO don't behave the same way
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271116619.47.0.361606315039.issue8382@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
title: cStringIO and StringIO doesn't behave the same way -> cStringIO and StringIO don't behave the same way

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:02:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 00:02:40 +0000
Subject: [issue8364] Update site.setquit docstring
In-Reply-To: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>
Message-ID: <1271116960.68.0.539782219323.issue8364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Answer to myself by Brian Curtin on the chatroom:

Him: it?s in the code so i would file it like code. "Library" for py modules, "Extension Modules" if its a C extension

Me: Your answer implies that components are mapped to directories, not areas (i.e. Library == Lib, documentation == Doc, not the general concept of documentation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8364>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:05:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 00:05:15 +0000
Subject: [issue8382] cStringIO and StringIO don't behave the same way
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271117115.76.0.683104565485.issue8382@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Probably not. I guess an implicit str() is done on the argument given to write():

>>> s = StringIO()
>>> s.write((1,2))
>>> s.write(3)
>>> s.getvalue()
'(1, 2)3'

----------
nosy: +pitrou
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:07:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 00:07:49 +0000
Subject: [issue8382] StringIO.write() takes any argument and converts it to a
	string
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271117269.84.0.199837005305.issue8382@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: cStringIO and StringIO don't behave the same way -> StringIO.write() takes any argument and converts it to a string

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:10:20 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 13 Apr 2010 00:10:20 +0000
Subject: [issue8382] StringIO.write() takes any argument and converts it to a
	string
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271117420.71.0.111179063946.issue8382@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes, I am not sure what would be the best fix though. We cannot raise an error on StringIO now because this will break lots of code out there. 

In the meantime, I think it's cleaner to avoid doing implicit str() conversions, so I think cStringIO has a better approach.

I would be in favor of a status quo for 2.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:22:16 2010
From: report at bugs.python.org (Kyle VanderBeek)
Date: Tue, 13 Apr 2010 00:22:16 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1271118136.32.0.465521783503.issue1692335@psf.upfronthosting.co.za>


Kyle VanderBeek <kylev at kylev.com> added the comment:

Ping?  Is anyone working on this?  Have Eric's concerns been addressed and can we pickle/unpickle all exceptions yet?

----------
nosy: +kylev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:39:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 00:39:57 +0000
Subject: [issue8383] pickle is unable to encode unicode surrogates
In-Reply-To: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>
Message-ID: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python3 uses unicode surrogates to store undecodable filenames. Eg. the filename b"abc\xff.py" is encoded as "abc\xdcff.py" if the file system encoding is ASCII. Pickle is unable to store them:

./python -c 'import pickle; pickle.dumps("abc\udcff")'
(...)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 20: surrogates not allowed

This is a limitation of pickle (in the binary mode): Python accepts to store any unicode character, but pickle doesn't.

Using "surrogatepass" error handler should be enough to fix this issue.

Related issue: #3672 (Reject surrogates in utf-8 codec) -> r72208 creates "surrogatepass" error handler.

----------
components: Library (Lib)
messages: 102996
nosy: haypo, lemburg, loewis
severity: normal
status: open
title: pickle is unable to encode unicode surrogates
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8383>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:44:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 00:44:40 +0000
Subject: [issue8383] pickle is unable to encode unicode surrogates
In-Reply-To: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>
Message-ID: <1271119480.84.0.31965663177.issue8383@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16904/pickle_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8383>
_______________________________________

From report at bugs.python.org  Tue Apr 13 02:51:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 00:51:34 +0000
Subject: [issue8383] pickle is unable to encode unicode surrogates
In-Reply-To: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>
Message-ID: <1271119894.84.0.188816920199.issue8383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I found this bug indirectly: test_logging failed on a SocketHandler if LogRecord.pathname contains a surrogate character. SocketHandler uses pickle to serialize the record.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8383>
_______________________________________

From report at bugs.python.org  Tue Apr 13 03:00:58 2010
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 13 Apr 2010 01:00:58 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1271120458.58.0.893691688495.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I tried it in Python 3.1.2.

    \Python31\python.exe setup.py build --compiler=mingw32

I got a stack-trace:

...
  File "C:\Python31\lib\distutils\cygwinccompiler.py", line 280, in __init__
    CygwinCCompiler.__init__ (self, verbose, dry_run, force)
  File "C:\Python31\lib\distutils\cygwinccompiler.py", line 124, in __init__
    if self.ld_version >= "2.10.90":
TypeError: unorderable types: NoneType() >= str()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Tue Apr 13 03:04:31 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 13 Apr 2010 01:04:31 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1271120671.91.0.203356765996.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Craig, that's another bug, can you open another issue for that?

The missing vcvarsall.bat bug is cleared and I will close this issue once I've reverted distutils state in the 3.x branch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Tue Apr 13 03:15:38 2010
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 13 Apr 2010 01:15:38 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I tried to build a C extension in Python 3.1.2.

    \Python31\python.exe setup.py build --compiler=mingw32

I got a stack-trace:

...
  File "C:\Python31\lib\distutils\cygwinccompiler.py", line 280, in __init__
    CygwinCCompiler.__init__ (self, verbose, dry_run, force)
  File "C:\Python31\lib\distutils\cygwinccompiler.py", line 124, in __init__
    if self.ld_version >= "2.10.90":
TypeError: unorderable types: NoneType() >= str()

This is Windows 2000 SP4, with MinGW 5.1.6.

----------
assignee: tarek
components: Distutils
messages: 103000
nosy: cmcqueen1975, tarek
severity: normal
status: open
title: Distutils C extension build with MinGW on Windows fails
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Tue Apr 13 03:17:23 2010
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 13 Apr 2010 01:17:23 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1271121443.83.0.42319470719.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Sure can--done. Issue #8384.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Tue Apr 13 03:41:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 01:41:17 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1271122877.55.0.628522009933.issue5341@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file16855/functools-typos-pep8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Tue Apr 13 03:41:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 01:41:22 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1271122882.4.0.543503325512.issue5341@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file16894/functools-typos-pep8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Tue Apr 13 04:17:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 02:17:20 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1271125040.38.0.784540167692.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I saw the author of functools on the chatroom and asked for feedback. Summary:

* Rewrapping, whitespace changes, quote changes and other minor PEP?8 stuff is not worth the trouble it creates (eats time without improving Python?s quality, and also disturbing use of $vcs blame);
* Doc changes have to apply to all four branches, not just trunk and py3k.

This leaves the two typos.  I?ll port the ?built{-,}in? fixes to 2.6 and 3.1 later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Tue Apr 13 04:21:52 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 13 Apr 2010 02:21:52 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1271125312.0.0.396708397334.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100413.zip is a new version of the regex module.

It includes additional speed-ups.

----------
Added file: http://bugs.python.org/file16905/issue2636-20100413.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Apr 13 04:40:51 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 13 Apr 2010 02:40:51 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1271126451.84.0.178165494807.issue7306@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r80026-r80029.

----------
assignee:  -> brian.curtin
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7306>
_______________________________________

From report at bugs.python.org  Tue Apr 13 05:01:07 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 13 Apr 2010 03:01:07 +0000
Subject: [issue8382] StringIO.write() takes any argument and converts it to a
	string
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271127667.65.0.569676479176.issue8382@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

It's clear you can't change it for 2.6 or 2.7, almost certainly not 3.1.
Maybe you could change it for 3.2.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 05:04:52 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 13 Apr 2010 03:04:52 +0000
Subject: [issue8382] StringIO.write() takes any argument and converts it to a
	string
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271127892.45.0.63331384621.issue8382@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Whoops.  No stringio.py in 3.x.  This should be closed as won't fix since it's not a problem in py3k and can't be changed in 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 05:33:44 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 13 Apr 2010 03:33:44 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1271129624.41.0.912022624589.issue4487@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

MIMEText doesn't support unicode input. This was the reason OP Test case  failed. For reference : http://bugs.python.org/issue1368247

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4487>
_______________________________________

From report at bugs.python.org  Tue Apr 13 05:33:47 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 13 Apr 2010 03:33:47 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1271129627.91.0.197884678794.issue1368247@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

After applying maxua's patch we do not get the unicode error but as david stated the support is not there. Here is the test.

>>> import email
>>> msg = email.MIMEText.MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> msg.as_string()
'MIME-Version: 1.0\nContent-Transfer-Encoding: 8bit\nContent-Type: text/plain; charset="utf8"\n\n\xd0\xba\xd0\xb8\xd1\x80\xd0\xb8\xd0\xbb\xd0\xb8\xd1\x86\xd0\xb0'

This does not seems a viable general solution to the problem.

I guess, this issue should be closed and emphasis should be now on development of 'email 6.0'. By the way I mailed Marius, the author of the blog-post http://mg.pov.lt/blog/unicode-emails-in-python , if I can borrow his example for the doc-patch.

----------
nosy: +l0nwlf
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368247>
_______________________________________

From report at bugs.python.org  Tue Apr 13 06:12:21 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 13 Apr 2010 04:12:21 +0000
Subject: [issue6521] Contradictory documentation for email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1271131941.24.0.338646863898.issue6521@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)

The lack of unicode encoding support should be mentioned explicitly.
Attaching a doc patch.

----------
keywords: +patch
nosy: +l0nwlf, r.david.murray
Added file: http://bugs.python.org/file16906/email.mime.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6521>
_______________________________________

From report at bugs.python.org  Tue Apr 13 06:14:29 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Apr 2010 04:14:29 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1271132069.95.0.0175869262258.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Even if I tested it only with Python documentation, the script should work for other docs generated by Sphinx (at least with the default theme).
Last time I tried the script it wasn't working on Chrome, so there's still some work to do. If you want to try it and see if it works with your doc, it should be enough to copy the .js file and include it in the HTML page using a <script> tag.

----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Tue Apr 13 07:20:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 05:20:22 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1271136022.28.0.868362380209.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

r80004 and r80006 to be exact. 

Great! Thanks! =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Tue Apr 13 07:24:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 05:24:41 +0000
Subject: [issue4022] 2.6 dependent on c:\python26\ on windows
In-Reply-To: <1222989342.94.0.529774628368.issue4022@psf.upfronthosting.co.za>
Message-ID: <1271136281.68.0.0288587283375.issue4022@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I it still actual for 2.6.5 and 2.7?

----------
components: +Installation
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4022>
_______________________________________

From report at bugs.python.org  Tue Apr 13 07:56:37 2010
From: report at bugs.python.org (Christopher Paolini)
Date: Tue, 13 Apr 2010 05:56:37 +0000
Subject: [issue7509] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
Message-ID: <1271138197.16.0.42484568768.issue7509@psf.upfronthosting.co.za>


Christopher Paolini <stormlifter at gmail.com> added the comment:

actually this isn't a duplicate. This is for version 2.6, that issue you said it was a duplicate of is for Python 2.5.

----------
nosy: +Christopher.Paolini

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7509>
_______________________________________

From report at bugs.python.org  Tue Apr 13 08:32:05 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Apr 2010 06:32:05 +0000
Subject: [issue7509] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
Message-ID: <1271140325.85.0.597530926772.issue7509@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"This is for version 2.6". But how? the traceback shows C:\Python25 on almost every line.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7509>
_______________________________________

From report at bugs.python.org  Tue Apr 13 08:32:08 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 13 Apr 2010 06:32:08 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1271140328.39.0.579143863949.issue8366@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Setting CPPFLAGS is needed to ensure that the configure tests use the correct header files, as Ned noted.

I agree that this should be cleaned up, I also agree with MAL's comment in Issue8211: the entire machinery for setting up the compiler in Python's configure script is a mess.

I'll see what can be done to fix this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Tue Apr 13 08:43:15 2010
From: report at bugs.python.org (Christopher Paolini)
Date: Tue, 13 Apr 2010 06:43:15 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1271140995.93.0.874003493979.issue2698@psf.upfronthosting.co.za>


Christopher Paolini <stormlifter at gmail.com> added the comment:

There is an issue with Visual Studio 2008 and the latest 2.6.5
It searches using

productdir = Reg.get_value(r"%s\Setup\VC" % vsbase,
                                   "productdir")

I just fresh installed Visual Studios and there is no registry "setup" folder. So you can't find the install directory that way at least not on my machine. Windows 7 64-bit and I installed Microsoft Visual Studio 2008 SP1

----------
nosy: +Christopher.Paolini

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Tue Apr 13 08:58:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 13 Apr 2010 06:58:36 +0000
Subject: [issue7509] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
Message-ID: <1271141916.36.0.690214285542.issue7509@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I don't know about 2.5 but:

Reading the MSVCCompiler class code in trunk, I can see a case where __init__ doesn't create self.__root. (if self.__arch != Intel)
making any call to get_msvc_paths() leading to an error.

You certainly have some kind of unexpected environment when MSVCCompiler is called.

I need to fix this.

If you could help me out by tracing how the compiler is instanciated, taht could help me.

----------
priority:  -> normal
resolution:  -> accepted
status: closed -> open
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7509>
_______________________________________

From report at bugs.python.org  Tue Apr 13 09:01:52 2010
From: report at bugs.python.org (Christopher Paolini)
Date: Tue, 13 Apr 2010 07:01:52 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1271142112.23.0.470665483639.issue7511@psf.upfronthosting.co.za>


Christopher Paolini <stormlifter at gmail.com> added the comment:

I'm running into the same issue myself. I even installed Visual Studio 2008. Issue is it installed as a 32-bit application in the x86 directory, not sure why. I have 64-bit Windows 7. I'm installing the SDK to see if that helps.

Also I need this for pycrypto too. If anyone has a 64-bit AMD build for the latest crypto that'd be amazing.

----------
nosy: +Christopher.Paolini

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Apr 13 10:03:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 08:03:27 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271145807.11.0.947231485545.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

-0 eric.smith     for concerns about people relying on current behaviour
-0 brian.curtin   the same
counterarg: current behavior will be broken anyway with compatibility fix in r80004

+0 r.david.murray   the policy that we shouldn't change stdlib interfaces without a strong reason, but Tools is not stdlib

+0.5 merwok   as diff.py can not be considered unix diff replacement


Wouldn't it be nice if you haven't need to say your tool how to do the thing you like?

Don't you want to add a recommendation to use diff.py tool so that Windows users can also send patches?
http://python.org/dev/patches/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 10:30:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 08:30:25 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271147425.56.0.309761394725.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> This type of failure appears again in current builds:

Unfortunately, I think you mean 'still' rather than 'again'.  :)
As far as I can tell, the failure's never gone away, though it may have been obscured by other failures from time to time.

Maybe it's time to do something.  I propose we:

  1. create a new branch py3k-issue4970
  2. Hack Lib/test/regrtest.py in that branch so that it runs
     *only* test_os and test_wait3, in that order (ignoring the -r
     flag).  Check that we're still getting the failure.
  3. Do a binary search (remove half the test_os tests; trigger
     buildbot run; see if we're still getting the signal; rinse;
     repeat) to narrow down the cause to a particular test.
  4. While doing 3, ruthlessly kill all other non-trunk
     checkin-triggered buildbot runs on this machine
     to speed up the search process a bit.  (Keeping trunk builds
     for the sake of the upcoming 2.7 release.)

I'll try to start this this evening (no ssh access at the moment) unless someone else beats me to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 10:34:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 08:34:13 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271147653.3.0.790494246286.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Should also modify regrtest to print out the result of the command

getconf GNU_LIBPTHREAD_VERSION

that Antoine suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:01:51 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 13 Apr 2010 09:01:51 +0000
Subject: [issue8383] pickle is unable to encode unicode surrogates
In-Reply-To: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>
Message-ID: <1271149311.54.0.285836752323.issue8383@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Both pickle and marshal will need to use the new error handler in order to stay compatible with Python 3.0 (and 2.x) and also to enable creating Unicode literals that include lone surrogates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8383>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:02:01 2010
From: report at bugs.python.org (David Planella)
Date: Tue, 13 Apr 2010 09:02:01 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1271149321.04.0.212207516154.issue8359@psf.upfronthosting.co.za>


David Planella <david.planella at ubuntu.com> added the comment:

It would be nice that %-formatting had the same functionality as in C when it comes to discarding unnamed arguments, but from the comments I understand that being deprecated no changes in functionality are contemplated.

However, before recommending using str.format, the fact that gettext does not yet seem to support it should also be taken into account. Some examples:

= %-formatting =

print gettext.ngettext("%(package)d package", "%(package)d packages", countInstall) % { 'package': countInstall}

Renders the following in a POT template:

#, python-format
msgid "%(package)d package"
msgid_plural "%(package)d packages"
msgstr[0] ""
msgstr[1] ""

-- All good. The string is marked as a python-format one and the %(package) argument can be dropped in the translation for the languages which need it. No program crash.

= str.format() formatting =

print gettext.ngettext("{no_of_packages} package", "{no_of_packages} packages", countInstall).format(no_of_packages=countInstall)

Renders the following in a POT template:

msgid "{no_of_packages} package"
msgid_plural "{no_of_packages} packages"
msgstr[0] ""
msgstr[1] ""

-- Not marked as python-format, since gettext does not seem to support the {} notation. No error-checking can take place for arguments. Not good.

print _("{day} day").format(day=countInstall)

msgid "{day} day"
msgstr ""

-- Same comment as above.

print _("{0} package").format(countInstall)

Extracted string in a POT template:

msgid "{0} package"
msgstr ""

-- Same comment as above

I understand that part of the error is in gettext, but I thought I'd mention it here as well, since this has caused quite a lot of crashes in Hebrew and Arabic translations in Ubuntu in the past, and will continue to do it until addressed.

----------
nosy: +dpm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:13:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 09:13:35 +0000
Subject: [issue6090] zipfile DeprecationWarning Python in 2.6, failure in 2.7
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1271150015.36.0.881080512356.issue6090@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Martin]
> I think the error message could be better, though; it should probably be a ValueError.

Do you mean a ValueError at the level of the struct module, or the zipfile module.

I'd quite like to change all the exceptions raised by the struct module to ValueError or TypeError (as appropriate);  I'm not sure what the point of struct.error is supposed to be.  I've resisted making this change up until now for backwards compatibility reasons, but perhaps it could be considered for 3.2 (but not for 2.7).

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6090>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:18:15 2010
From: report at bugs.python.org (Thijs Triemstra)
Date: Tue, 13 Apr 2010 09:18:15 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1271150295.59.0.541019697408.issue1722344@psf.upfronthosting.co.za>


Thijs Triemstra <lists at collab.nl> added the comment:

Looks like this influenced mod_wsgi as well: http://groups.google.com/group/modwsgi/browse_thread/thread/ba82b2643564d2dd

----------
nosy: +thijs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:19:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 09:19:54 +0000
Subject: [issue5377] Strange behavior when performing int on a Decimal
	made	from -sys.maxint-1
In-Reply-To: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
Message-ID: <1271150394.76.0.327056539537.issue5377@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing: it's too late for Python 2.x.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5377>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:20:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 09:20:58 +0000
Subject: [issue7873] Remove precision restriction for integer formatting.
In-Reply-To: <1265548818.49.0.927659235166.issue7873@psf.upfronthosting.co.za>
Message-ID: <1271150458.92.0.903697996042.issue7873@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing:  it's too late for 2.x.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7873>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:27:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 09:27:30 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1271150850.62.0.425921035129.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Unassigning myself for now.  The most recent patch still needs work before it can be considered for inclusion.

----------
assignee: mark.dickinson -> 
status: open -> languishing
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:28:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 09:28:23 +0000
Subject: [issue8383] pickle is unable to encode unicode surrogates
In-Reply-To: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>
Message-ID: <1271150903.31.0.546007726769.issue8383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Both pickle and marshal will need to use the new error handler 
> in order to stay compatible with Python 3.0 (and 2.x) 
> and also to enable creating Unicode literals that include 
> lone surrogates.

Attached patch fixes pickle. Marshal does already use surrogatepass since Martin's commit r72208 (Issue #3672).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8383>
_______________________________________

From report at bugs.python.org  Tue Apr 13 11:44:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 13 Apr 2010 09:44:31 +0000
Subject: [issue8383] pickle is unable to encode unicode surrogates
In-Reply-To: <1271150903.31.0.546007726769.issue8383@psf.upfronthosting.co.za>
Message-ID: <4BC43D1E.9050908@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> Both pickle and marshal will need to use the new error handler 
>> in order to stay compatible with Python 3.0 (and 2.x) 
>> and also to enable creating Unicode literals that include 
>> lone surrogates.
> 
> Attached patch fixes pickle. Marshal does already use surrogatepass since Martin's commit r72208 (Issue #3672).

Looks good !

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8383>
_______________________________________

From report at bugs.python.org  Tue Apr 13 12:37:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 10:37:35 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1271155055.02.0.19303034745.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Many thanks for reviewing, Stefan, and for the patch.

Here's an updated patch:
 - specify 32-bit/64-bit C long rather than 32-bit/64-bit machine
 - apply hash->hash_ fix to Python hash recipe
 - use _PyHASH_MODULUS instead of _PyHASH_MASK throughout (this
   was bugging me).
 - reorganize the stdtypes doc entry slightly
 - update against current svn, and remove outdated test_float tests
   for the values of float('inf') and float('nan')

One unresolved issue:  it would probably make sense to specify (publicly) a hash algorithm for complex types, too, so that someone implementing e.g. Gaussian integers can make their hash function agree with that for the complex type where appropriate.

That hash algorithm would probably be as simple as:

  hr = hash(x.real)
  hi = hash(x.imag)
  return <some suitably bit-mixing combination of hi and hr>

where the algorithm for the combination needs to be specified explicitly, and any relevant parameters put into sys.hash_info.
(Unfortunately, -1 doesn't have square roots modulo the prime P used, else we could do the cute thing and make use of a square root of -1 modulo P.)

Another tiny detail:  I'm wondering whether hash(m/P) should care about the sign of m:  currently it doesn't, which means that the symmetry hash(-x) = -hash(x) *almost* always holds for a rational x, but not always.  An almost-always-true symmetry seems like a recipe for hard-to-find bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Tue Apr 13 12:37:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 10:37:47 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1271155067.09.0.560692674119.issue8188@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Tue Apr 13 12:39:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 10:39:03 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1271155143.71.0.531107859978.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

... and here's the actual patch...  Forget my own head next. :)

----------
Added file: http://bugs.python.org/file16907/numeric_hash7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Tue Apr 13 12:41:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 10:41:40 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1271155300.2.0.474872264643.issue8188@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Tue Apr 13 12:50:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Apr 2010 10:50:31 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271155831.21.0.20432427681.issue4970@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This bugreport http://bugs.gentoo.org/28193 indeed suggests that
the failure occurs on systems without nptl.

Would it be possible for someone with an affected system to run
the test program from the bug report?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 13:10:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 11:10:23 +0000
Subject: [issue8383] pickle is unable to encode unicode surrogates
In-Reply-To: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>
Message-ID: <1271157023.85.0.287681115697.issue8383@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r80031 (py3k) and r80032 (3.1), fix also pickletools.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8383>
_______________________________________

From report at bugs.python.org  Tue Apr 13 13:19:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Apr 2010 11:19:03 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271157543.27.0.88282854389.issue8384@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you run the following command:
   ld -v
and paste the result?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Tue Apr 13 13:24:23 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Apr 2010 11:24:23 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271157863.11.0.940917608691.issue8355@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

You can use http://gnuwin32.sourceforge.net/packages/diffutils.htm or
cygwin or msys.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 13:34:16 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 11:34:16 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271158456.25.0.309947156154.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I hope this is not a support tracker. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 13:34:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 11:34:56 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271158496.82.0.16041403484.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Do you really think that Python users shouldn't use tools written in Python if they are available?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:03:29 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 13 Apr 2010 12:03:29 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271160209.0.0.02613812488.issue4970@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Signal 32 is the first real-time signal, and is indeed used by linuxthreads, so it's very likely a linuxthreads bug, since this signal shouldn't leak to application.
Since linuxthreads is no longer maintained, I'm afraid we can't do much about this, except check for the threading library used and say "linuxthreads is obsolete and has known issues - please upgrade your system for reliable threading support".

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:06:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 12:06:35 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271160395.05.0.783829885488.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Since linuxthreads is no longer maintained, I'm afraid we can't do much
> about this.

Agreed.  But I think it's still worth trying to narrow down (and possibly work around) the cause of failure, just so that we can make this buildbot useful again on 3.x.  Perhaps we can get by with a conditional skip of one of the test_os tests, but we have to figure out which one first.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:09:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Apr 2010 12:09:14 +0000
Subject: [issue8382] StringIO.write() takes any argument and converts it to a
	string
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271160554.73.0.103042791538.issue8382@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8382>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:15:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Apr 2010 12:15:03 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1271160903.64.0.702641244973.issue7585@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, thanks for the typo correction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:21:01 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 13 Apr 2010 12:21:01 +0000
Subject: [issue8385] _winreg remaining in test_winsound
In-Reply-To: <1271161261.72.0.0289506148873.issue8385@psf.upfronthosting.co.za>
Message-ID: <1271161261.72.0.0289506148873.issue8385@psf.upfronthosting.co.za>


New submission from Tim Golden <mail at timgolden.me.uk>:

There is a reference to _winreg left in test_winsound. Trivial patch attached renames this to winreg.

----------
components: Tests
files: test_winsound.patch
keywords: patch
messages: 103042
nosy: tim.golden
severity: normal
status: open
title: _winreg remaining in test_winsound
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file16908/test_winsound.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8385>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:24:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 12:24:46 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271161486.6.0.0929352374931.issue4970@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of the Prelude ticket https://dev.prelude-ids.com/issues/show/133 : "commenting out sigprocmask(SIG_SETMASK, &set, NULL) seems to fixes the problem (...)"

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:36:55 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 13 Apr 2010 12:36:55 +0000
Subject: [issue8385] _winreg remaining in test_winsound
In-Reply-To: <1271161261.72.0.0289506148873.issue8385@psf.upfronthosting.co.za>
Message-ID: <1271162215.6.0.605516352457.issue8385@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8385>
_______________________________________

From report at bugs.python.org  Tue Apr 13 14:45:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 13 Apr 2010 12:45:14 +0000
Subject: [issue8385] _winreg remaining in test_winsound
In-Reply-To: <1271161261.72.0.0289506148873.issue8385@psf.upfronthosting.co.za>
Message-ID: <1271162714.86.0.529148167201.issue8385@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Whoops, thanks for catching that, Tim. Fixed in r80044 and 80046.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8385>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:04:26 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 13 Apr 2010 13:04:26 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <4BC46BD2.2070102@timgolden.me.uk>
Message-ID: <4BC46BD2.2070102@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

test_pickle failing on WinXP

http://svn.python.org/projects/python/branches/py3k/Lib r80044

======================================================================
ERROR: test_unicode (__main__.CPicklerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test\pickletester.py", line 523, in test_unicode
     p = self.dumps(u, proto)
   File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 30, in dumps
     p.dump(arg)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 1: surrogates not allowed

======================================================================
ERROR: test_unicode (__main__.CDumpPickle_LoadPickle)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test\pickletester.py", line 523, in test_unicode
     p = self.dumps(u, proto)
   File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 30, in dumps
     p.dump(arg)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 1: surrogates not allowed

======================================================================
ERROR: test_unicode (__main__.DumpPickle_CLoadPickle)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test\pickletester.py", line 524, in test_unicode
     u2 = self.loads(p)
   File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 37, in loads
     return u.load()
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3: illegal encoding

----------------------------------------------------------------------

----------
messages: 103045
nosy: tim.golden
severity: normal
status: open
title: test_pickle failing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:18:50 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Apr 2010 13:18:50 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <4BC46BD2.2070102@timgolden.me.uk>
Message-ID: <1271164730.54.0.846228051056.issue8386@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> haypo
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:20:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 13:20:35 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271164835.5.0.175250282501.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Results of my simple-minded strategy (see r80033-4, r80037, r80042, r80045, r80047-51):

test_execvpe_with_bad_program in ExecTests by itself is enough to trigger the signal 32 error (in combination with test_wait3).  See:

http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x/builds/2174

If just this single test is disabled and all other tests in test_os are allowed to run, there's no problem (at least with test_wait3;  (I haven't tried re-enabling *all* other tests in the test suite yet).  See:

http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x/builds/2176

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:28:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 13:28:30 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <4BC46BD2.2070102@timgolden.me.uk>
Message-ID: <1271165310.9.0.430569626148.issue8386@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The failing test was introduced by r80031 by me: see issue #8383.

I don't understand why the test fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:30:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 13:30:12 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <4BC46BD2.2070102@timgolden.me.uk>
Message-ID: <1271165412.53.0.206600009921.issue8386@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Does the follow code work on Windows?

>>> '\uDC80'.encode("utf8", "surrogatepass")
b'\xed\xb2\x80'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:37:49 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 13 Apr 2010 13:37:49 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <1271165412.53.0.206600009921.issue8386@psf.upfronthosting.co.za>
Message-ID: <4BC473A8.9090700@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Yes:

<dump>
C:\temp>\work_in_progress\make-snapshots\branches
Python 3.2a0 (py3k:80030, Apr 13 2010, 11:13:13)
Type "help", "copyright", "credits" or "license"
>>> '\uDC80'.encode("utf8", "surrogatepass")
b'\xed\xb2\x80'
>>>

</dump>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:44:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 13:44:51 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <4BC46BD2.2070102@timgolden.me.uk>
Message-ID: <1271166291.22.0.581705169888.issue8386@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

How did you get these errors? I don't see them in the buildbots (x86 Windows7 3.x, x86 XP-4 3.x):
 * http://www.python.org/dev/buildbot/builders/x86 Windows7 3.x/builds/408/steps/test/logs/stdio
 * http://www.python.org/dev/buildbot/builders/x86 XP-4 3.x/builds/1874/steps/test/logs/stdio

Is it in your local computer? Did you recompiled Python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 15:57:59 2010
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 13 Apr 2010 13:57:59 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1271167079.89.0.278777370528.issue7584@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I've made a patch.

This patch adds a datetime_rfcformat function to datetimemodule.c which is available from Python as the datetime.rfcformat method in the datetime module.  This method returns the date in RFC 3339 format: YYYY-MM-DDTHH:MM:SS[.mmmmmm]+HH:MM.  Documentation and tests are also added.

----------
keywords: +patch
nosy: +durban
Added file: http://bugs.python.org/file16909/issue7584.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Tue Apr 13 16:03:21 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 13 Apr 2010 14:03:21 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <1271166291.22.0.581705169888.issue8386@psf.upfronthosting.co.za>
Message-ID: <4BC479A4.3060607@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Well that's embarrassing: I updated but didn't rebuild. Sorry for the noise; all tests passing now. Please close the call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 16:07:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 14:07:02 +0000
Subject: [issue8386] test_pickle failing
In-Reply-To: <4BC46BD2.2070102@timgolden.me.uk>
Message-ID: <1271167622.02.0.0851487065147.issue8386@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

he he, ok, no problem.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8386>
_______________________________________

From report at bugs.python.org  Tue Apr 13 17:02:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 15:02:09 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271170929.51.0.287767293863.issue8355@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Do you really think that Python users shouldn't use tools written in
> Python if they are available?

Sure, they can. For example, they can use Mercurial and type "hg diff".
Or even TortoiseHg and do it all from a GUI.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 17:16:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 15:16:41 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271171801.98.0.657567826005.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's some fairly minimal Python code that produces the signal:

### begin example ###
import os
import time
import _thread

try:
    os.execv('/usr/bin/dorothyq', ['dorothyq'])
except OSError:
    pass

def f():
    time.sleep(1.0)  # probably irrelevant to the failure

_thread.start_new(f, ())
### end example ###

It looks as though the failed os.execv call messes something up internally, so that any attempt thereafter to start a thread produces this signal.  I can't see anything obviously wrong with the os.execv implementation (see posix_execv in Modules/posixmodule.c).

There's still the question of what changed between 2.x and 3.x:  on 2.x, this buildbot seems perfectly happy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 17:28:40 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 13 Apr 2010 15:28:40 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271172520.03.0.428028835245.issue8355@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> Don't you want to add a recommendation to use diff.py tool so 
> that Windows users can also send patches?
> http://python.org/dev/patches/

We could add that note but it should not be a recommendation. Patches should ideally be generated using "svn diff" at the moment, and "hg diff" when we switch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 17:52:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 15:52:10 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271173930.25.0.0272594008396.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, I think I've got as far as I can, but if anyone else wants to hack on this, please do.

The branch name is py3k-issue4970

In that branch:

 - there's an extra test Lib/test/test_issue4970 that demonstrates
   the signal 32 failure

 - Lib/test/regrtest.py has been hacked to run only that test,
   in verbose mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 18:00:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_Duc=C3=A1r?=)
Date: Tue, 13 Apr 2010 16:00:44 +0000
Subject: [issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za>
Message-ID: <1271174444.52.0.224906801674.issue2554@psf.upfronthosting.co.za>


Changes by Martin Duc?r <ducarm1 at gmail.com>:


----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2554>
_______________________________________

From report at bugs.python.org  Tue Apr 13 18:11:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 13 Apr 2010 16:11:13 +0000
Subject: [issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za>
Message-ID: <1271175073.75.0.471821105573.issue2554@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Removing 2.5 as it's only receiving security fixes.

----------
nosy: +brian.curtin
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2554>
_______________________________________

From report at bugs.python.org  Tue Apr 13 18:16:13 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 16:16:13 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271175373.94.0.257814575508.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I'll add a note about preferred "svn diff" way and "diff.py" as a fallback.  But first I'd like to see this patch committed to streamline patch submission process by removing requirement to remember "-u" option.

Do agree that "diff.py" is not a replacement for "diff (1)", but our own custom tool that produces diffs?

If that's true when why don't you let this tool produce unified diffs by default if you and everybody else here want diffs in this format?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 18:23:43 2010
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 13 Apr 2010 16:23:43 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1271125312.0.0.396708397334.issue2636@psf.upfronthosting.co.za>
Message-ID: <g2w425e93af1004130923p1ad0f2d6se6b0cca687213864@mail.gmail.com>


Alex Willmer <alex at moreati.org.uk> added the comment:

On 13 April 2010 03:21, Matthew Barnett <report at bugs.python.org> wrote:
> issue2636-20100413.zip is a new version of the regex module.

Matthew, When I run test_regex.py 6 tests are failing, with Python
2.6.5 on Ubuntu Lucid and my setup.py. Attached is the output, do all
the tests pass in your build?

Alex

----------
Added file: http://bugs.python.org/file16910/test_regex_20100413

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_regex_20100413
Type: application/octet-stream
Size: 3077 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100413/d0eaf0f8/attachment-0001.obj>

From report at bugs.python.org  Tue Apr 13 18:52:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 16:52:43 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271177563.94.0.154752298507.issue4970@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

signal.__dict__:
{...
 'NSIG': 65,
 'SIGABRT': 6,
 'SIGALRM': 14,
 'SIGBUS': 7,
 'SIGCHLD': 17,
 'SIGCLD': 17,
 'SIGCONT': 18,
 'SIGFPE': 8,
 'SIGHUP': 1,
 'SIGILL': 4,
 'SIGINT': 2,
 'SIGIO': 29,
 'SIGIOT': 6,
 'SIGKILL': 9,
 'SIGPIPE': 13,
 'SIGPOLL': 29,
 'SIGPROF': 27,
 'SIGPWR': 30,
 'SIGQUIT': 3,
 'SIGRTMAX': 64,
 'SIGRTMIN': 35,
 'SIGSEGV': 11,
 'SIGSTOP': 19,
 'SIGSYS': 31,
 'SIGTERM': 15,
 'SIGTRAP': 5,
 'SIGTSTP': 20,
 'SIGTTIN': 21,
 'SIGTTOU': 22,
 'SIGURG': 23,
 'SIGUSR1': 10,
 'SIGUSR2': 12,
 'SIGVTALRM': 26,
 'SIGWINCH': 28,
 'SIGXCPU': 24,
 'SIGXFSZ': 25,
 'SIG_DFL': 0,
 'SIG_IGN': 1,
 ...}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:04:23 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Apr 2010 17:04:23 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271178263.2.0.777236667637.issue8355@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The requirement to remember the "-u" option is a benefit for the user.
If he ever wants to use a standard diff, he doesn't have to relearn
things.

I don't agree that diff.py should be a custom tool. It's unfortunate
that it already deviates from standard diffs, but that's no reason to
deviate further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:08:52 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 17:08:52 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271178532.44.0.888515037861.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Stefan, do you use "diff.py"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:10:37 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 13 Apr 2010 17:10:37 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1271178637.66.0.331948926306.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Yes, it passed all the tests, although I've since found a minor bug that isn't covered/caught by them, so I'll need to add a few more tests.

Anyway, do:

    regex.match(ur"\p{Ll}", u"a")
    regex.match(ur'(?u)\w', u'\xe0')

really return None? Your results suggest that they won't.

I downloaded Python 2.6.5 (I was using Python 2.6.4) just in case, but it still passes (WinXP, 32-bit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:11:43 2010
From: report at bugs.python.org (Keegan Carruthers-Smith)
Date: Tue, 13 Apr 2010 17:11:43 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271178703.05.0.522173947087.issue2987@psf.upfronthosting.co.za>


Keegan Carruthers-Smith <keegan.csmith at gmail.com> added the comment:

Just thought I'd point out that RFC2732 was obsoleted by RFC3986 http://www.rfc-editor.org/rfc/rfc3986.txt

----------
nosy: +Keegan.Carruthers-Smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:15:53 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 13 Apr 2010 17:15:53 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271178953.48.0.233028912071.issue8384@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:18:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 17:18:19 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271179099.0.0.575972608571.issue2987@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Thanks for the precision. This particular topic is discussed on #5650, feel free to help there!

Better update the code before the doc, though.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:24:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 13 Apr 2010 17:24:10 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1271179099.0.0.575972608571.issue2987@psf.upfronthosting.co.za>
Message-ID: <20100413172359.GA12692@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Actually, this bug is just for parsing the IPv6 url. We are having the
right set of patches in the bug. I shall commit it soon.
The RFC part is separate and we will slowly achieve a good compliance
with STD 66.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:24:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 17:24:27 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271179467.19.0.070668578797.issue4970@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There are many references to "unknown signal 32" errors in Google.

Gdb mailing list, December 2002: "SIG32/SIGTRAP issues"
http://sources.redhat.com/ml/gdb/2002-12/msg00057.html

Gdb mailing list, September 2003: "pthread_create, Program received signal ?, Unknown signal"
http://sources.redhat.com/ml/gdb/2003-09/msg00003.html
=> extract: "A change in the definition of SIGRTMIN
causes this symptom."

There is a thread "SIGRT_0 (Unknown signal 32)" in the Linux Kernel mailing list, in July 2005:
http://lkml.org/lkml/2005/7/30/93

Extract of a Debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298982
-------------
There are actually three earlier instances in the trace of
 rt_sigsuspend([]  <unfinished ...>
in those cases it gets "SIGRTMIN (Unknown signal 32)" and carries on.
The one prior to the hanging instance is

 open("/dev/sequencer", O_WRONLY)        = 10
 ioctl(10, SNDCTL_SEQ_NRSYNTHS, 0x40095b20) = 0
 ioctl(10, SNDCTL_SEQ_NRMIDIS, 0x40094c20) = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
 write(9, " \357\24@\0\0\0\0P\370\377\277\240\341\16@\220\376\23\10"..., 148) = 148
 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
 rt_sigsuspend([] <unfinished ...>
 --- SIGRTMIN (Unknown signal 32) @ 0 (0) ---
 <... rt_sigsuspend resumed> )           = -1 EINTR (Interrupted system call)
 sigreturn()                             = ? (mask now [RTMIN])

(...)

This is not very helpful, as it means the thread is waiting for another
thread, nothing else. Could you run it with strace -f ?
-------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:24:58 2010
From: report at bugs.python.org (James Cooper)
Date: Tue, 13 Apr 2010 17:24:58 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1271179498.49.0.104085921913.issue1856@psf.upfronthosting.co.za>


Changes by James Cooper <james.cooper at solidodesign.com>:


----------
nosy: +jamescooper

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:47:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 17:47:35 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271180855.75.0.697087139274.issue4970@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

NPTL was introduced in Linux kernel 2.6(.0). glibc 2.4 requires NPTL:

"The LinuxThreads add-on, providing pthreads on Linux 2.4 kernels, is no longer supported. The new NPTL implementation requires Linux 2.6 kernels. For a libc and libpthread that works well on Linux 2.4 kernels, we recommend using the stable 2.3 branch."

NPTL 0.1 was released in September 2002. So the bug requires a Linux kernel 2.4 (and gblic 2.3.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:51:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 17:51:00 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1271181060.14.0.4501758068.issue7316@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch against current py3k.
About the timeout limit, an useful point of comparison is select(), which doesn't try to loop either: it just throws OverflowError if the specified timeout value is too large to be represented in a timeval struct.

----------
Added file: http://bugs.python.org/file16911/timedlock6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Tue Apr 13 19:55:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 17:55:27 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271181327.57.0.336361295675.issue4970@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I suggest simply skipping the "offending" test on linuxthread platforms.
(perhaps as simple as checking for sys.platform == "linux2" and signal.SIGRTMIN == 35)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 20:41:19 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 13 Apr 2010 18:41:19 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1271184079.32.0.66483650697.issue1722344@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Tue Apr 13 20:51:23 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 13 Apr 2010 18:51:23 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271184683.38.0.743809922868.issue8379@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So technically Python does not know that some bytecode was compiled with optimization flags on; that is simply not carried in the bytecode format. You also cannot rely on file name extensions as the bytecode could have been generated by an interpreter that used .pyo as the file extension for non-optimized bytecode. So you can't really make this an "explicit error" without changing the format of bytecode files.

As for a distribution choice for only shipping bytecode, you should then only ship .pyc files to avoid this issue.

Raymond who (most likely) added the optimization is already on the nosy list so he can decide to disagree with me if he wants, but I am personally still not viewing this as a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:03:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 19:03:47 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1271185427.46.0.47206800047.issue3783@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:13:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 19:13:30 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271186010.46.0.963029973666.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Seems like I have to remind that everybody can still paint their bikeshed in classic colors with "-c" option, but if you all prefer unified colors, why do you resist on painting them in these by default? Custom color options add more to a total price, you know. More customers would be happy if the basic version included their favorite flavor.

>From another side unix 'diff' users are smart enough to read command line help for 'diff.py' if they won't like default unified output and choose the option they need. BTW, what option should I specify to unix diff to get HTML or ndiff output?

Let me remind that there are tools like 'svnmerge' that do even more things that standard 'svn merge' does not.


Your arguments could be more convincing if you could show at least one real world example against "diff.py" that outweighs the benefit of having unified diff generated without any additional options. IIUC Python scripts are installed with .py extension even on Unix platform, and you can't execute 'diff.py' instead of 'diff' by mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:19:34 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 13 Apr 2010 19:19:34 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271186374.55.0.8493536494.issue8355@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

To change the default, you need to know how many people it will benefit, and how many people will be negatively impacted by the change. I personally suspect that both numbers are zero, which is why I have a hard time getting excited about it.

Are there any real-world reports of users (Windows or otherwise) who would use this tool, if only it had a different default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:20:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 19:20:38 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1271186010.46.0.963029973666.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271186559.3592.26.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Seems like I have to remind that everybody can still paint their
> bikeshed in classic colors with "-c" option, but if you all prefer
> unified colors, why do you resist on painting them in these by
> default? Custom color options add more to a total price, you know.
> More customers would be happy if the basic version included their
> favorite flavor.

Hey, could you please stop complaining? You opened the issue, you are
the own bikeshedding here.

Besides, Python's goal is /not/ to produce a tool chain of replacement
programs for the standard Unix utilities. There are certainly more
constructive things to do for the Python community, than to keep
insisting on this issue. Micro-problems don't warrant stressing
everyone's patience with aggressive hand-waving. Thanks in advance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:20:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 19:20:59 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271186459.44.0.419788454588.issue4970@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I suggest simply skipping the "offending" test on linuxthread
> platforms.

Good idea

> (perhaps as simple as checking for sys.platform == "linux2" 
> and signal.SIGRTMIN == 35)

I would prefer to rely on confstr():

import os
try:
    # 'linuxthreads-0.10' or 'NPTL 2.10.2'
    pthread = os.confstr("CS_GNU_LIBPTHREAD_VERSION")
    linuxthreads = pthread.startswith("linuxthreads")
except ValueError:
    linuxthreads = False

^^ this example requires attached patch for the two CS_GNU_* constants.

Which tests should be disabled?

----------
keywords: +patch
Added file: http://bugs.python.org/file16912/confstr_libpthread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:21:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 13 Apr 2010 19:21:16 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271186476.39.0.63158952785.issue8355@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:21:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 19:21:36 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271186496.22.0.12700767608.issue8355@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:33:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 19:33:25 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271187205.68.0.807057516077.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Skipping test_execvpe_with_bad_program sounds good to me.

I'd ideally like to understand why 3.x is failing where 2.x is happy, but life's too short to stuff a mushroom.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:33:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 13 Apr 2010 19:33:27 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271187207.96.0.532229378599.issue8355@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy:  -eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 21:46:47 2010
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 13 Apr 2010 19:46:47 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1271178637.66.0.331948926306.issue2636@psf.upfronthosting.co.za>
Message-ID: <p2s425e93af1004131246qa014f09fr7ed9a9d8d1fed153@mail.gmail.com>


Alex Willmer <alex at moreati.org.uk> added the comment:

On 13 April 2010 18:10, Matthew Barnett <report at bugs.python.org> wrote:
> Anyway, do:
>
> ?? ??regex.match(ur"\p{Ll}", u"a")
> ?? ??regex.match(ur'(?u)\w', u'\xe0')
>
> really return None? Your results suggest that they won't.

Python 2.6.5 (r265:79063, Apr  3 2010, 01:56:30)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import regex
>>> regex.__version__
'2.3.0'
>>> print regex.match(ur"\p{Ll}", u"a")
None
>>> print regex.match(ur'(?u)\w', u'\xe0')
None

I thought I might be a 64 bit issue, but I see the same result in a 32
bit VM. That leaves my build process. Attached is the setup.py and
build output, unicodedata_db.h was taken from the Ubuntu source deb
for Python 2.6.5.

----------
Added file: http://bugs.python.org/file16913/setup.py
Added file: http://bugs.python.org/file16914/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________
-------------- next part --------------
#!/usr/bin/env python

import os
import shutil
import sys

from distutils.core import setup, Extension

MAJOR, MINOR = sys.version_info[:2]
BASE_DIR = os.path.dirname(os.path.abspath(__file__))

if MAJOR == 2:
    SRC_DIR = BASE_DIR
elif MAJOR == 3:
    SRC_DIR = os.path.join(BASE_DIR, 'Python3')

if (MAJOR, MINOR) in ((2,5), (2,6), (2,7)):
    unicodedata_db_h = os.path.join(SRC_DIR, 'Python%i%i' % (MAJOR, MINOR), 
                                    'unicodedata_db.h')
    shutil.copy(unicodedata_db_h, SRC_DIR)
else:
    sys.exit("No unicodedata_db.h could be prepared.")

setup(
    name='regex',
    version='0.1.2010413',
    description='Alternate regular expression module, to replace re.',
    long_description=open(os.path.join(SRC_DIR, 'Features.rst')).read(),
    
    # PyPI does spam protection on email addresses, no need to do it here
    author='Matthew Barnett',
    author_email='regex at mrabarnett.plus.com',

    # PyPI appears to overwrite author field with maintainer field
    # avoid apparent plagarism for now.
    #maintainer='Alex Willmer',
    #maintainer_email='alex at moreati.org.uk',

    url='http://bugs.python.org/issue2636',
    classifiers=[
        'Development Status :: 3 - Alpha',
        'Intended Audience :: Developers',
        'License :: OSI Approved :: Python Software Foundation License',
        'Operating System :: OS Independent',
        'Programming Language :: Python',
        'Topic :: Scientific/Engineering :: Information Analysis',
        'Topic :: Software Development :: Libraries :: Python Modules',
        'Topic :: Text Processing',
        'Topic :: Text Processing :: General',
        ],
    license='Python Software Foundation License',

    py_modules = ['regex'],
    ext_modules=[Extension('_regex', ['_regex.c'])],
    )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.log
Type: text/x-log
Size: 1572 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100413/5a328155/attachment.bin>

From report at bugs.python.org  Tue Apr 13 21:59:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 19:59:58 +0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1271188798.02.0.00871448912814.issue1152248@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:00:00 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 13 Apr 2010 20:00:00 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271188800.34.0.414988244523.issue4970@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> It looks as though the failed os.execv call messes something up internally, so that any attempt thereafter to start a thread produces this signal.  I can't see anything obviously wrong with the os.execv implementation (see posix_execv in Modules/posixmodule.c).

Upon execve, signals handler are reset to default. So maybe the error makes the linuxthread API screw up latter when it tries to set up handlers for SIGRTMIN and friend. But what's weird is that when the executable given does not exist, the call should fail and return before having done anything...

> There's still the question of what changed between 2.x and 3.x:  on 2.x, this buildbot seems perfectly happy.

I think it's simply because we didn't test a wrong program path with execve in 2.X version of test_os.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:04:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 20:04:13 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271189053.19.0.952773138024.issue4970@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think it's simply because we didn't test a wrong program path 
> with execve in 2.X version of test_os.

Oh, we should add this test to Python2 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:07:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Apr 2010 20:07:39 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271189259.63.0.896439037016.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I think it's simply because we didn't test a wrong program path with execve in 2.X version of test_os.

D'oh!  Thank you very much.

I'm happy now:  my mushroom's stuffed.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:12:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 20:12:45 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1271189565.21.0.734413296889.issue7651@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The link has gone.  Is this the message you?re refering to? http://mail.python.org/pipermail/python-dev/2010-January/097115.html

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7651>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:14:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 20:14:45 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1271189685.96.0.489256519421.issue6626@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:14:52 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Apr 2010 20:14:52 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271189692.81.0.942016196506.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Seems like a bikeshed was too much of an argument, but I've run out of them discussing such minor issue. The last is that if anybody here has 0's - does my +1 value something? Why can't anybody just commit it and close this, so I can concentrate on resolution for the next issue in my list like #7582 or #               7584

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:25:49 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 13 Apr 2010 20:25:49 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1271190349.39.0.605116502105.issue7651@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Yes, that's the posting I was referring to. I wonder why the link is gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7651>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:28:49 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Apr 2010 20:28:49 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271190529.66.0.2845579602.issue8355@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy:  -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:31:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 13 Apr 2010 20:31:27 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271190687.61.0.710158955347.issue8355@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Tentatively closing as rejected.  There were quite a lot of -0 or -1, and you can include one from me as well.

----------
nosy: +georg.brandl
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:54:44 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 13 Apr 2010 20:54:44 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1271192084.78.0.543468418211.issue7559@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Tue Apr 13 22:55:38 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 13 Apr 2010 20:55:38 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1271192138.74.0.223432969845.issue8370@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Tue Apr 13 23:11:26 2010
From: report at bugs.python.org (sfinnie)
Date: Tue, 13 Apr 2010 21:11:26 +0000
Subject: [issue8387] use universal newline mode in csv module examples
In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za>
Message-ID: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za>


New submission from sfinnie <scott.finnie at gmail.com>:

Running the examples in the csv module docs (http://docs.python.org/library/csv.html) causes problems reading file on a mac.  This is highlighted in issue 1072404 (http://bugs.python.org/issue1072404).

Commentary on the bug indicates a no fix, meaning most/many people using a mac will get an error if they use the sample code in the docs.

A simpler solution would be to use universal newline mode in the doc examples.  This is actually mentioned in commentary on the bug, and appears to work.

Proposal
--------
In all example code blocks, use mode 'rU' when opening the file.  1st code block, for example, would become:

spamReader = csv.reader(open('eggs.csv', 'rU'), delimiter=' ', quotechar='|')

That should solve the problem on mac without impacting compatibility on other operating systems.  Note: Haven't been able to verify this on other platforms.

----------
assignee: georg.brandl
components: Documentation
messages: 103086
nosy: georg.brandl, sfinnie
severity: normal
status: open
title: use universal newline mode in csv module examples
type: feature request
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8387>
_______________________________________

From report at bugs.python.org  Tue Apr 13 23:16:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Apr 2010 21:16:27 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1271193387.19.0.90009800375.issue8362@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Tue Apr 13 23:20:54 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 13 Apr 2010 21:20:54 +0000
Subject: [issue8297] AttributeError message text should include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1271193654.12.0.236382502124.issue8297@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8297>
_______________________________________

From report at bugs.python.org  Wed Apr 14 00:48:42 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Apr 2010 22:48:42 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271198922.88.0.338644168251.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Maybe the state of this discussion is my fault for not being clear enough.
Let's abandon terms such as "broken" and "roundrobin."  CS theory has the perfectly useful terms "fair" and "unfair."  The fact of the matter is this:
the pthread GIL (implemented as LEGACY gil) is an "unfair" syncronization primitve.  The GIL on windows, (and the poorly named ROUNDROBIN_GIL) is a  "fair" synchronization primitive.

Unfair mutexes have their place, and such is the behaviour of the windows condition variable (and the pthreads mutex, I suspect).  But they are not useful if you want to provide fair access to a resource that is held all the time.

Until after that GIL business at PyCon I wasn't aware of this fundamental difference between the GIL on windows and pthreads platforms in 2.x.  It is astonishing to me that no one appears to have noticed the difference, or made much of it.  CPU threads are scheduled fairly on windows, and incredibly unfairly on pthreads.

with the ROUNDROBIN_GIL I'm not proposing anything radical, I'm just suggesting that we adopt the superior behaviour that has been on windows all along.  Yes, people actually do use windows.

Antoine, I understand that your point about do_yield, yet the results for 3 seconds without it are telling on their own, and worthy of being studied, which is why I suggested disabling it.

Also, I think you will find that he imbalance in the throughput of the threads won't go away even after 30 seconds.  Unfortunately, the unfairness is such that it may actually diverge.

I've improved my patch some more.  I'll upload it soon.  In particular, I've addea a PyThread_gil_yield() method to enable whatever underlying gil there is to possible deal with this particular locking case differently, if possible, perhaps suggesting to the OS not to switch cores.


I?ve also created a simple program in visual studio to examine a GIL outside the context of python.  I'll put it here tomorrow too, for those interested.  It allows for simpler experimentation, although because the loop is small, you won't see the effect of the instruction cache problems.


David, I actually think that the checkinterval is a perfectly good mechanism, especially if augmented with an interrupt mechanism  What does it matter if some opcodes are slower than others?  when we are checking every 100 or 1000 (or 10000 as I am proposing) that hardly matters.  We just need to have an order of magnitude thing there.  But there are other ways to do it.  You can use a timer on windows, and on pthreads too, I think.

But the whole point of this patch is to take a step back, and to see if there is a way to fix the "gil problem" in a simpler way by first trying to understand it fully, and then apply minimal changes to solve it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:01:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Apr 2010 23:01:23 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271198922.88.0.338644168251.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271199805.3592.45.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Kristjan,

> Maybe the state of this discussion is my fault for not being clear enough.

It's quite a bit simpler. The first 2.7 beta has been released and
there's IMO no way such patches will be accepted. It doesn't seem to be
a pressing enough issue to be considered a real bug. As you said
yourself, most people actually aren't really affected, or not enough.

> CPU threads are scheduled fairly on windows, and incredibly unfairly
> on pthreads.

pthreads doesn't schedule anything. The kernel does. I'm sure that on
non-tiny periods (>= 5s) they are scheduled quite fairly. It's just that
switching occurs less often and less regularly than you'd might hope.

> Antoine, I understand that your point about do_yield, yet the results
> for 3 seconds without it are telling on their own, and worthy of being
> studied, which is why I suggested disabling it.

As I said, they will render 2.x results completely wrong (at least under
Linux).

> Also, I think you will find that he imbalance in the throughput of the
> threads won't go away even after 30 seconds.

I'm actually not really interested in confirming this, but as I said
there's no reason to think that the Linux kernel does a bad job.
(the one reputed to do a bad job at scheduling, especially for desktop
environments, is the Windows kernel)

> I've improved my patch some more.  I'll upload it soon.

If you are interested in taking it further, I would recommend publishing
your patch (and prebuilt binaries, if you care) somewhere else as well,
because as I said there's probably no way it gets integrated during what
remains of the 2.x timeline.

Of course, other developers might disagree with me, in which case your
patch /can/ be integrated. But I don't see a lot of interest showing
honestly.

> We just need to have an order of magnitude thing there.

Duration of opcodes can vary by more than an order of magnitude.
ccbench includes such testing by the way (different CPU-bound workloads)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:01:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Apr 2010 23:01:54 +0000
Subject: [issue8388] None shouldn't be passed to traceback.format_exception
In-Reply-To: <1271199714.1.0.812266738214.issue8388@psf.upfronthosting.co.za>
Message-ID: <1271199714.1.0.812266738214.issue8388@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

When porting recent unittest patches to py3k, I encountered a failure in testBufferOutputAddErrorOrFailure. The reason is that the test passes None to traceback.format_exception, which works by accident in 2.x.

I added these lines in _exc_info_to_string to fix it:
            chain = exctype is not None
            msgLines = traceback.format_exception(exctype, value, tb,
                                                  chain=chain)

It would be nice if the nice didn't have to rely on that behavior and that hack could be removed.

----------
assignee: michael.foord
components: Library (Lib)
messages: 103089
nosy: benjamin.peterson, michael.foord
priority: normal
severity: normal
status: open
title: None shouldn't be passed to traceback.format_exception
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8388>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:11:42 2010
From: report at bugs.python.org (Mike Beachy)
Date: Tue, 13 Apr 2010 23:11:42 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1271200302.34.0.0992478750284.issue7291@psf.upfronthosting.co.za>


Mike Beachy <mbeachy at gmail.com> added the comment:

I have worked up a monkey patch for urllib2/httplib for the issue of setting the authentication using a Proxy(Basic|Digest)AuthHandler.

The basic approach was to create a new httplib exception (ProxyTunnelError) and raise that with the http response attached so that the HTTPSHandler can determine when 407 Proxy authentication required is present, and then reroute the urllib2.OpenerDirector to error handling mode.

Unfortunately, there is a backwards compatibility issue - cases where a socket.error was previously being raised now get an ProxyTunnelError. Not that you could do much useful with the socket.error in the first place, but I suppose you could look for '407' in the text. Ugh.

If you think this might prove useful, let me know and I can rework it into a real patch - just let me know what branch/version to base it off of. (My monkey patch is for python 2.6.4.)

----------
nosy: +mbeachy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:19:18 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 13 Apr 2010 23:19:18 +0000
Subject: [issue8389] Incomprehensibly import error
In-Reply-To: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>
Message-ID: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

I ran into an ImportError I was unable to explain:

$ python -c "import a.b"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "a/b/__init__.py", line 1, in <module>
    import a.b.c
  File "a/b/c.py", line 2, in <module>
    import a.b.t as t
AttributeError: 'module' object has no attribute 'b'

This is the source code:
$ tail `find -name \*.py`
==> ./demo.py <==
import a.b

==> ./a/__init__.py <==

==> ./a/b/c.py <==
# Does not work:
import a.b.t as t
# Works:
# import a.b
# from a.b import t

==> ./a/b/t.py <==

==> ./a/b/__init__.py <==
import a.b.c
# Works:
# import a.b.t

Replacing any import with one of the versions annotated as working fixes it. Stripping another level from the package tree fixes it as well. Why!?

----------
components: Interpreter Core
files: import_error.tar.gz
messages: 103091
nosy: torsten
severity: normal
status: open
title: Incomprehensibly import error
versions: Python 2.6
Added file: http://bugs.python.org/file16915/import_error.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8389>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:21:07 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 13 Apr 2010 23:21:07 +0000
Subject: [issue8389] Incomprehensibly import error
In-Reply-To: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>
Message-ID: <1271200867.23.0.57291420256.issue8389@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Err, typo, in c.py I meant to write

# Does not work:
import a.b.t as t
# Works:
# import a.b.t

So without renaming it it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8389>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:23:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 13 Apr 2010 23:23:00 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271198922.88.0.338644168251.issue8299@psf.upfronthosting.co.za>
Message-ID: <4BC4FCD1.6090408@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Maybe the state of this discussion is my fault for not being clear
> enough. Let's abandon terms such as "broken" and "roundrobin."  CS
> theory has the perfectly useful terms "fair" and "unfair."  The fact
> of the matter is this: the pthread GIL (implemented as LEGACY gil) is
> an "unfair" syncronization primitve.

That's not really true. The Linux condition variable (from glibc
linuxthreads), for example, implements "fair" synchronization. Other
implementations may do the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:26:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Apr 2010 23:26:36 +0000
Subject: [issue8389] Incomprehensible import error
In-Reply-To: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>
Message-ID: <1271201196.58.0.670909650889.issue8389@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
title: Incomprehensibly import error -> Incomprehensible import error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8389>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:29:49 2010
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 13 Apr 2010 23:29:49 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271201389.53.0.0888973915836.issue8384@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

\MinGW\bin\ld.exe -v

GNU ld (GNU Binutils) 2.20

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:33:14 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 13 Apr 2010 23:33:14 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1271201594.96.0.330078207913.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100414.zip is a new version of the regex module.

I think I might have identified the cause of the problem, although I still haven't been able to reproduce it, so I can't be certain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:34:51 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 13 Apr 2010 23:34:51 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1271201691.04.0.0984628102335.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Oops, forgot the file! :-)

----------
Added file: http://bugs.python.org/file16916/issue2636-20100414.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:37:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 23:37:47 +0000
Subject: [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: <1271201867.16.0.200024181875.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +test_xmlrpc fails with non-ascii path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:39:59 2010
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 13 Apr 2010 23:39:59 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1271201594.96.0.330078207913.issue2636@psf.upfronthosting.co.za>
Message-ID: <m2h425e93af1004131639ofd5a04c1jdb541d79a96874d7@mail.gmail.com>


Alex Willmer <alex at moreati.org.uk> added the comment:

On 14 April 2010 00:33, Matthew Barnett <report at bugs.python.org> wrote:
> I think I might have identified the cause of the problem, although I still haven't been able to reproduce it, so I can't be certain.

Performed 76

Passed

Looks like you got it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:41:47 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 13 Apr 2010 23:41:47 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271202107.61.0.138320135649.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

What bothers me most about this discussion is that the Windows implementation (legacy GIL) is being held up as an example of what we should be doing on posix.  Yet, if I go run the same thread tests that I presented in my GIL talks on a multicore Windows machine, the performance is every bit as bad, if not worse, than what I reported in my talk.    Therefore, why would we want that?   I just don't get it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Wed Apr 14 01:53:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 23:53:15 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

When reading a tar archive, tarfile decodes fields using "replace" error handler by default. The result is that we loose informations if there is an undecodable character.

Since the PEP 383, undecodable filenames are stored using surrogates in Python3. I think that it's a good idea to use surrogates for tar, because it's a common problem to have undecodable data in a tar archive (see the unicode section of the tarfile documentation).

----------
components: Library (Lib), Unicode
files: tarfile_surrogates.patch
keywords: patch
messages: 103099
nosy: haypo, loewis
severity: normal
status: open
title: tarfile: use surrogates for undecode fields
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16917/tarfile_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8390>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:01:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:01:38 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It would be nice to support the PEP 383 (surrogateescape) for environment variables in os.execvpe(). Attached patch uses PyUnicode_AsEncodedString(val, Py_FileSystemDefaultEncoding, "surrogateescape") to encode an environment variable value.

I'm not sure that PyUnicode_AsEncodedString(val, Py_FileSystemDefaultEncoding, "surrogateescape") does always return a PyBytes object.

I not patched environment keys, but it might be useful.

----------
components: Library (Lib), Unicode
files: os_execvpe_surrogates.patch
keywords: patch
messages: 103100
nosy: haypo
severity: normal
status: open
title: os.execvpe() doesn't support surrogates in env
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16918/os_execvpe_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:02:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:02:04 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271203324.47.0.301925502955.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #4036.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:02:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:02:40 +0000
Subject: [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: <1271203360.68.0.534349696237.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +os.execvpe() doesn't support surrogates in env

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:03:32 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 14 Apr 2010 00:03:32 +0000
Subject: [issue8392] unit tests rather light on testing __import__(..., level)
In-Reply-To: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>
Message-ID: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

At work we are in the process of migrating from Python 2.4 to 2.6.  One
bit of Boost.Python code needs to use PyImport_ImportModuleLevel which
references the __import__ docs.  That describes the use of the level arg.
I then went around looking for examples and didn't find much, certainly not in the Lib/test directory.  I only saw a couple examples which used
level and they both use level=0, so don't test relative imports or
level=-1.

I don't know that I have enough knowledge of how this stuff is supposed
to work, but will give it a shot.

----------
assignee: skip.montanaro
components: Tests
messages: 103102
nosy: skip.montanaro
priority: normal
severity: normal
stage: unit test needed
status: open
title: unit tests rather light on testing __import__(..., level)
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8392>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:22:06 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 14 Apr 2010 00:22:06 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1271204526.59.0.893342250739.issue7316@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Thanks, looks good. Sorry for the delay.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:34:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:34:32 +0000
Subject: [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: <1271205272.8.0.68549284021.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch: all tests pass except of 3 (test_ftplib, test_pep3120, test_traceback).

----------
Added file: http://bugs.python.org/file16919/surrogates-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:55:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:55:24 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In py3k, subprocess uses _posixsubprocess.fork_exec() function. This function uses surrogateescape error handler for most arguments, but not for the current working directory (cwd).

Attached patch uses PyUnicode_FSConverter() as done for other arguments. I don't know if PyUnicode_FSConverter() result is always a PyBytes, so I added an assertion. It should be fixed.

----------
components: Library (Lib), Windows
files: posixsubprocess_cwd.patch
keywords: patch
messages: 103105
nosy: haypo
severity: normal
status: open
title: subprocess: support undecodable current working directory on POSIX OS
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16920/posixsubprocess_cwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:55:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:55:52 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271206552.15.0.078581428916.issue8393@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8391.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Wed Apr 14 02:56:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:56:12 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271206572.79.0.630950502535.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8393.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Wed Apr 14 03:09:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 01:09:07 +0000
Subject: [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: <1271207347.99.0.726767567608.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +subprocess: support undecodable current working directory on POSIX OS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Wed Apr 14 03:16:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 01:16:20 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The PEP 383 introduces filename using surrogates. ctypes.dlopen() support them. ctypes.cdll.LoadLibrary('libc\uDCff.so.6') fails with:

   UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' 
   in position 4: surrogates not allowed

Attached patch fixes this issue.

TODO: Remove the assert(PyBytes_Check(name2)). I don't know if PyUnicode_FSConverter() does always return a PyBytes object or not.

----------
components: Library (Lib), Unicode
files: ctypes_dlopen_surrogates.patch
keywords: patch
messages: 103108
nosy: haypo
severity: normal
status: open
title: ctypes.dlopen() doesn't support surrogates
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16921/ctypes_dlopen_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Wed Apr 14 03:16:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 01:16:36 +0000
Subject: [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: <1271207797.0.0.460539971522.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +ctypes.dlopen() doesn't support surrogates

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Wed Apr 14 03:18:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 01:18:17 +0000
Subject: [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: <1271207897.17.0.334393667884.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16897/surrogates-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Wed Apr 14 04:21:38 2010
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 14 Apr 2010 02:21:38 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271211698.26.0.284607252159.issue8384@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I just realised--I didn't have c:\mingw\bin in my path. Once I added that to the path, then the build worked fine.

So I guess the issue is only that the error message is somewhat cryptic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Wed Apr 14 04:23:16 2010
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 14 Apr 2010 02:23:16 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1271189259.63.0.896439037016.issue4970@psf.upfronthosting.co.za>
Message-ID: <q2zee2a432c1004131923z51bd862cj760ca0ecf1004ab3@mail.gmail.com>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Thanks for taking care of this guys.  Sorry, I got swamped with mail
and had to archive 3,000+ messages.  It looks like it's in good hands.

Let me know if there's anything you need.  I may not have access to
the box anymore, however, I can always contact Kurt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Wed Apr 14 05:04:21 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Apr 2010 03:04:21 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1271214261.61.0.909441305138.issue7559@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
assignee: michael.foord -> cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Wed Apr 14 05:20:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 14 Apr 2010 03:20:42 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271215242.74.0.430846227358.issue8394@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> theller
components: +ctypes
nosy: +theller
stage:  -> unit test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Wed Apr 14 06:29:29 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 14 Apr 2010 04:29:29 +0000
Subject: [issue8395] shutil.copytree() add a copy_func parameter.
In-Reply-To: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>
Message-ID: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

The shutil.copytree() function copies the whole tree recursively, and copy one single regular file with copy2(). I hope it can be more powerful(), that is, allow specifying a customerized copy function, rather than copy2(). To be specific, add an optional keyword argument, named "copy_func" or something like, default to copy2.

It will be useful for doing some customerized filesystem tree copying.

For example, when writing something like the project install script, or update script, which need to ignore some file while copying the whole directory, or changing ".ini" file after copying, or rename the file name after copying. All the specific copy action can be done in our customerized copy function instead of copy2().

Is there anybody who has the same feature request? Or is there some other module already provides the same functionality?

If so, I can provide a patch for it.

Thanks!

----------
components: Library (Lib)
messages: 103111
nosy: ysj.ray
severity: normal
status: open
title: shutil.copytree() add a copy_func parameter.
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8395>
_______________________________________

From report at bugs.python.org  Wed Apr 14 09:44:23 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Apr 2010 07:44:23 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271231063.71.0.577381081123.issue8384@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Wed Apr 14 09:47:34 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 14 Apr 2010 07:47:34 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271231254.97.0.913206499094.issue8384@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok thanks for you test.

If it can't get the ld version I'll display this message:

"could not detect the ld version. Make sure MinGW is installed and its bin directory is in the path"

I'll do this for 2.7/3.2

----------
priority:  -> low
type: crash -> behavior
versions: +Python 2.7, Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Wed Apr 14 10:37:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 14 Apr 2010 08:37:27 +0000
Subject: [issue1083299] Distutils doesn't pick up all the files it should.
Message-ID: <1271234247.18.0.293204524432.issue1083299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello.

(If this comes out of the blue, since the bug was opened years ago, read http://bugs.python.org/issue1083299.)

Akira is right about ?depends?. Regarding ?data_files?, if they?re not picked up it?s a bug. Mike, can you still reproduce it with current Python versions?

Reference: http://docs.python.org/distutils/setupscript#installing-additional-files

(Not assigning this to Distutils2 since it will have a different behavior with respect to data files, and because it?s really a bug to fix in Distutils. There can?t be any tool that depends on this bug, right?)

Regards

----------
nosy: +merwok
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083299>
_______________________________________

From report at bugs.python.org  Wed Apr 14 10:57:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Apr 2010 08:57:43 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1271235463.45.0.970017570979.issue5341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, fixed the two typos in r80067, r80068.  Please open a new issue for further fixes, this one gets a bit confusing :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Wed Apr 14 11:08:24 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Apr 2010 09:08:24 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271236104.12.0.876063646819.issue8394@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PyUnicode_FSConverter returns bytes and bytearray objects unchanged; otherwise it always return bytes.

Your patch should handle the case when name2 is a bytearray.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Wed Apr 14 11:11:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 14 Apr 2010 09:11:38 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1271236298.18.0.704575743645.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Raymond didn?t want the quote characters changed, sorry if I failed to channel him.

I?ll port the ?builtin? typo fixes to the other branches and let this report closed. Thanks for the guidance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Wed Apr 14 11:19:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 14 Apr 2010 09:19:12 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1271236752.77.0.301258094718.issue7559@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee: cjerdonek -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Wed Apr 14 11:50:04 2010
From: report at bugs.python.org (Parth Malwankar)
Date: Wed, 14 Apr 2010 09:50:04 +0000
Subject: [issue8396] tarfile.open does fails with UnicodeDecodeError if parent
	dir is unicode
In-Reply-To: <1271238603.95.0.608393654552.issue8396@psf.upfronthosting.co.za>
Message-ID: <1271238603.95.0.608393654552.issue8396@psf.upfronthosting.co.za>


New submission from Parth Malwankar <parth.malwankar at gmail.com>:

If any directory higher up in the hierarchy contains unicode chars, tarfile.open fails with UnicodeDecodeError. Attached script reproduces this error.

[tmp]% python tarfilefail.py 
Traceback (most recent call last):
  File "tarfilefail.py", line 9, in <module>
    tarfile.open(file_name, 'w')
  File "/usr/lib/python2.6/tarfile.py", line 1682, in open
    return cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python2.6/tarfile.py", line 1692, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python2.6/tarfile.py", line 1527, in __init__
    self.name = os.path.abspath(name) if name else None
  File "/usr/lib/python2.6/posixpath.py", line 338, in abspath
    path = join(os.getcwd(), path)
  File "/usr/lib/python2.6/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 17: ordinal not in range(128)
[tmp]%

----------
files: tarfilefail.py
messages: 103117
nosy: parthm
severity: normal
status: open
title: tarfile.open does fails with UnicodeDecodeError if parent dir is unicode
versions: Python 2.6
Added file: http://bugs.python.org/file16922/tarfilefail.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8396>
_______________________________________

From report at bugs.python.org  Wed Apr 14 11:54:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 09:54:32 +0000
Subject: [issue8396] tarfile.open does fails with UnicodeDecodeError if parent
	dir is unicode
In-Reply-To: <1271238603.95.0.608393654552.issue8396@psf.upfronthosting.co.za>
Message-ID: <1271238872.34.0.94171474413.issue8396@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like tarfile doesn't support unicode filenames. You should try to encode your input filename to the file system default encoding (sys.getfilesystemencoding()), or avoid using unicode for tar filenames.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8396>
_______________________________________

From report at bugs.python.org  Wed Apr 14 12:00:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 10:00:18 +0000
Subject: [issue8396] tarfile.open does fails with UnicodeDecodeError if parent
	dir is unicode
In-Reply-To: <1271238603.95.0.608393654552.issue8396@psf.upfronthosting.co.za>
Message-ID: <1271239218.08.0.62836539613.issue8396@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I proposed a workaround, the real bug is that os.path.abspath() doesn't support unicode... And this bug was already fixed 7 weeks ago by r78247 (issue #3426).
http://svn.python.org/view/python/trunk/Lib/posixpath.py?r1=78247&r2=78246&pathrev=78247

Python 2.6.5 and 2.7b1 are fixed. So please upgrade :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8396>
_______________________________________

From report at bugs.python.org  Wed Apr 14 13:31:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Apr 2010 11:31:19 +0000
Subject: [issue8389] Incomprehensible import error
In-Reply-To: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>
Message-ID: <1271244679.26.0.965562436015.issue8389@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8389>
_______________________________________

From report at bugs.python.org  Wed Apr 14 13:48:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Apr 2010 11:48:54 +0000
Subject: [issue8395] shutil.copytree() add a copy_func parameter.
In-Reply-To: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>
Message-ID: <1271245734.78.0.475042709602.issue8395@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +tarek
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8395>
_______________________________________

From report at bugs.python.org  Wed Apr 14 13:51:34 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 14 Apr 2010 11:51:34 +0000
Subject: [issue8395] shutil.copytree() add a copy_func parameter.
In-Reply-To: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>
Message-ID: <1271245894.55.0.150963343442.issue8395@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Have you seen the ignore option ?

You can use it to filter out some files.

See the doc and the examples in docs.python.org

----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8395>
_______________________________________

From report at bugs.python.org  Wed Apr 14 13:56:56 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 14 Apr 2010 11:56:56 +0000
Subject: [issue8395] shutil.copytree() add a copy_func parameter.
In-Reply-To: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>
Message-ID: <1271246216.8.0.149773943083.issue8395@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Thanks for your help!

I see the 'ignore' parameter, but I need not just ignore some file, but also treat some file totally differently, for example, changing file name, or replace some text in the destination file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8395>
_______________________________________

From report at bugs.python.org  Wed Apr 14 14:43:32 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 14 Apr 2010 12:43:32 +0000
Subject: [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1271249012.5.0.0182858978116.issue2028@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Why Guido can't speak for py3k here in personal? I've just wasted two days debugging this O_BINARY flag when HgGit stopped to work on windows.
https://bugs.edge.launchpad.net/dulwich/+bug/557585

We need at least document this for os.open() properly.

----------
nosy: +techtonik
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
_______________________________________

From report at bugs.python.org  Wed Apr 14 14:45:55 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 14 Apr 2010 12:45:55 +0000
Subject: [issue8389] Incomprehensible import error
In-Reply-To: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>
Message-ID: <1271249155.01.0.729530280361.issue8389@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

The 'as' trigger some more instructions after import, not just renaming the loaded file name, to be specific in your example is, load attribute 'b' from 'a', and then load attribute 'c' from 'b'.

'import a.b.t' do import a.b.t and then just store 'a' in local namespace which is a reference of module 'a'
while, 
'import a.b.t as t' do import a.b.t and then load attribute 'b' from module 'a', then load attribute 't' from module 'b', finally store 't' in local namespace as a reference of a.b.t

But at that time('import a.b.t as t'), the statement 'import a.b' in demo.py hasn't finished executing yet, (because it triggers the statement 'import a.b.c' in a/b/__init__.py, which then triggers the statement 'import a.b.t as t' in a/b/c.py), along with the a/b/__init.py__.py file, although the module a has been imported, but module 'b' hasn't finished importing, it't only put in sys.modules, its module's code hasn't finishing executing(the code in a/b/__init__.py). In this case the module 'b' is considered not finishing importing, so it   hasn't been put in module a's dict as an attribute yet. 

So when the statement 'import a.b.t as t' executes in a/b/c.py, the module 'a' hasn't the attribute 'b'. But after the statement 'import a.b' in demo.py, the a/b/__init__.py file has complete executing, and the module b has finished importing, module 'b' has been put in module a's dict, at this time, 'load attribute b from a' is valid. So the import a.b as b in demo.py also works.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8389>
_______________________________________

From report at bugs.python.org  Wed Apr 14 14:52:43 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 14 Apr 2010 12:52:43 +0000
Subject: [issue8392] unit tests rather light on testing __import__(..., level)
In-Reply-To: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>
Message-ID: <1271249563.95.0.42701809573.issue8392@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

The attached diff adds a PackageTest class which exercises
both "from . import blah" and its __import__() equivalent.
The diff is against the release26-maint branch but I 
suspect it will apply cleanly to trunk and probably py3k.

----------
keywords: +patch
Added file: http://bugs.python.org/file16923/ti.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8392>
_______________________________________

From report at bugs.python.org  Wed Apr 14 14:56:06 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 14 Apr 2010 12:56:06 +0000
Subject: [issue8392] unit tests rather light on testing __import__(..., level)
In-Reply-To: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>
Message-ID: <1271249766.28.0.0692580448505.issue8392@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Unassigning so someone else can pick it up and review to
see if this makes sense.

----------
assignee: skip.montanaro -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8392>
_______________________________________

From report at bugs.python.org  Wed Apr 14 15:01:16 2010
From: report at bugs.python.org (Alex Stapleton)
Date: Wed, 14 Apr 2010 13:01:16 +0000
Subject: [issue8397] BZ2File doesn't protect against mixed iterator and read
	usage
In-Reply-To: <1271250076.58.0.0616490142802.issue8397@psf.upfronthosting.co.za>
Message-ID: <1271250076.58.0.0616490142802.issue8397@psf.upfronthosting.co.za>


New submission from Alex Stapleton <alex.stapleton at gmail.com>:

Normal files throw exceptions if you mix methods.

>>> f = open("words")
>>> for l in f:
...     break
... 
>>> f.tell()
8192L
>>> f.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Mixing iteration and read methods would lose data



BZ2Files silently do the wrong thing. (Output is a coincidence. Honest!)

>>> import bz2
>>> f = bz2.BZ2File("words.bz2")
>>> for l in f:
...     break
... 
>>> f.tell()
8192L
>>> f.readline()
'lose\n'


Expected behaviour is for it to throw a ValueError like normal file objects.

----------
components: None
messages: 103126
nosy: Alex.Stapleton
severity: normal
status: open
title: BZ2File doesn't protect against mixed iterator and read usage
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8397>
_______________________________________

From report at bugs.python.org  Wed Apr 14 15:15:01 2010
From: report at bugs.python.org (marco stamazza)
Date: Wed, 14 Apr 2010 13:15:01 +0000
Subject: [issue8398] Modules with a dot in the filename don't load
In-Reply-To: <1271250901.88.0.682481223536.issue8398@psf.upfronthosting.co.za>
Message-ID: <1271250901.88.0.682481223536.issue8398@psf.upfronthosting.co.za>


New submission from marco stamazza <giunghi at gmail.com>:

On my windows Xp system running Python 2.6 (from the (x,y) package) I tried to load a module named "GetMy.com_MOD.py". I kept receiving the error 
Traceback (most recent call last):
  File "D:\Docs\Futures-Strategy\StCHF\Test\GetMy.com_2.py", line 6, in <module>
    import GetMy.com_MOD
ImportError: No module named GetMy.com_MOD

Until I removed the dot renaming it to GetMycom_MOD.py, which works very nicely. Maybe the search should be smart enough to look for the last word after a dot to determine if the module exists or not?

Many thanks guys, Python rocks. marco

----------
components: Interpreter Core
messages: 103127
nosy: giunghi
severity: normal
status: open
title: Modules with a dot in the filename don't load
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8398>
_______________________________________

From report at bugs.python.org  Wed Apr 14 15:26:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 14 Apr 2010 13:26:04 +0000
Subject: [issue8399] Document os.open
In-Reply-To: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>
Message-ID: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Need to document the that os.O_BINARY flag is obligatory for cross-platform behavior of os.open() on Windows. By default os.open() opens file as binary on Unix, but as text on Windows.


See also issue2028 for discussion of making os.O_BINARY default on py3k. I can reopen this issue.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 103128
nosy: georg.brandl, techtonik
severity: normal
status: open
title: Document os.open
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/issue8399>
_______________________________________

From report at bugs.python.org  Wed Apr 14 15:26:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Apr 2010 13:26:58 +0000
Subject: [issue8398] Modules with a dot in the filename don't load
In-Reply-To: <1271250901.88.0.682481223536.issue8398@psf.upfronthosting.co.za>
Message-ID: <1271251618.13.0.384189049845.issue8398@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you do "import GetMy.com_MOD" Python will search for the module named "com_MOD" in the package "GetMy".
The name of the module should be a valid Python identifier -- possibly all lowercase (see PEP8). GetMy.com_MOD is not a valid identifier, so you wouldn't even be able to do GetMy.com_MOD.some_func() once you imported it.

See http://docs.python.org/reference/simple_stmts.html#the-import-statement for more information.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8398>
_______________________________________

From report at bugs.python.org  Wed Apr 14 15:40:03 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 14 Apr 2010 13:40:03 +0000
Subject: [issue8399] Document os.open
In-Reply-To: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>
Message-ID: <1271252403.35.0.91584758293.issue8399@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

s/ can / can't /

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8399>
_______________________________________

From report at bugs.python.org  Wed Apr 14 15:50:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Apr 2010 13:50:48 +0000
Subject: [issue8399] Document os.open
In-Reply-To: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>
Message-ID: <1271253048.59.0.21199323202.issue8399@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Since there is no distinction between text and binary mode on Unix, you shouldn't claim the behavior is not consistent - you get text mode.  You need O_BINARY on Windows to get binary mode.  O_BINARY is already documented; I've added a better link to it from the description of os.open() in r80069.

Do not reopen #2028, it was not about os.open() anyway.  For os.open(),
as it is only a wrapper for the OS's own POSIX layer, the flags argument
shouldn't be touched.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8399>
_______________________________________

From report at bugs.python.org  Wed Apr 14 16:54:41 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Apr 2010 14:54:41 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1271256881.66.0.150217182568.issue8370@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Wed Apr 14 17:20:42 2010
From: report at bugs.python.org (Karen Tracey)
Date: Wed, 14 Apr 2010 15:20:42 +0000
Subject: [issue8400] zipimporter find_module fullname mis-documented
In-Reply-To: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>
Message-ID: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>


New submission from Karen Tracey <kmtracey at gmail.com>:

The fullname parameter to zipimporter find_module is documented to be a "fully qualified (dotted) module name". (From http://docs.python.org/library/zipimport.html#zipimport.zipimporter.find_module.) However, passing a fully-qualified dotted module appears to never work. Rather it appears that you must use the file system path separator instead of dots. For example on Windows:

C:\>echo %pythonpath%
\tmp\blah-1.0-py2.6.egg

C:\>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.
>>> from blah.models import speak
>>> speak.__file__
'C:\\tmp\\blah-1.0-py2.6.egg\\blah\\models\\speak.pyc'
>>> speak.sayhi()
Hi from blah.models.speak sayhi function.

The egg has top-level blah package and under it models, it appears to work fine for normal use.  But zipimport zipimporter find_module won't find the models sub-module using dotted path notation:

>>> import sys
>>> sys.path[1]
'C:\\tmp\\blah-1.0-py2.6.egg'
>>> import zipimport
>>> zi = zipimport.zipimporter(sys.path[1])
>>> zi.find_module('blah')
<zipimporter object "C:\tmp\blah-1.0-py2.6.egg">
>>> zi.find_module('blah.models')
>>> zi.find_module('blah/models')
>>> zi.find_module('blah\\models')
<zipimporter object "C:\tmp\blah-1.0-py2.6.egg">
>>>

On Linux, the 'blah/models' version is the one that works.

Tested as far back as Python2.3 and as far forward as 2.7a3.

----------
messages: 103132
nosy: kmtracey
severity: normal
status: open
title: zipimporter find_module fullname mis-documented
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8400>
_______________________________________

From report at bugs.python.org  Wed Apr 14 17:41:50 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Wed, 14 Apr 2010 15:41:50 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>


New submission from Eugene Kapun <abacabadabacaba at gmail.com>:

>>> a = bytearray()
>>> a[:] = 0 # Is it a feature?
>>> a
bytearray(b'')
>>> a[:] = 10 # If so, why not document it?
>>> a
bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
>>> a[:] = -1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: negative count
>>> a[:] = -1000000000000000000000 # This should raise ValueError, not TypeError.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> a[:] = 1000000000000000000
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> a[:] = 1000000000000000000000 # This should raise OverflowError, not TypeError.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> a[:] = [] # Are some empty sequences better than others?
>>> a[:] = ()
>>> a[:] = list("")
>>> a[:] = ""
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument without an encoding

----------
components: Interpreter Core
messages: 103133
nosy: abacabadabacaba
severity: normal
status: open
title: Strange behavior of bytearray slice assignment
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Wed Apr 14 17:45:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Apr 2010 15:45:11 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1271259911.24.0.0313261847867.issue7316@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you! Checked in in r80071.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Wed Apr 14 17:47:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Apr 2010 15:47:06 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271260026.16.0.407094106515.issue8401@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It looks rather like a bug to me, and should be forbidden.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Wed Apr 14 19:36:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Apr 2010 17:36:46 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271266606.67.0.722633222168.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Victor, that patch looks fine to me.  Do you want to go ahead and apply it, and add the skip to test_execvpe_with_bad_program ?

The fix should be backported to 3.1, but not to 2.x (I think), since we don't have a problem there, and arguably the new os.confstr items could be considered a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Wed Apr 14 19:39:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Apr 2010 17:39:30 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271266770.09.0.58469048889.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And just for reference, 

http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x/builds/2192

shows that the relevant versions on this machine are:

glibc 2.3.4
linuxthreads-0.10

and from http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x, it looks like the kernel version is 2.6.9 (actually, 2.6.9-gentoo-r1).

----------
assignee:  -> haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Wed Apr 14 20:39:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 14 Apr 2010 18:39:06 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271270346.11.0.12881728628.issue8401@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

pitrou: I agree, it should be a TypeError.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Wed Apr 14 20:53:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 14 Apr 2010 18:53:48 +0000
Subject: [issue8399] Document os.open
In-Reply-To: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>
Message-ID: <1271271228.07.0.394699354264.issue8399@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Unix all files are opened in binary mode. On Windows linefeeds are translated to CRLF corrupting files that are meant to be binary. This is the reason of HgGit failure - it uses Dulwich library that creates corrupted Git index file, because on Windows it is opened without os.O_BINARY flag. Developers do not know anything about it, because they develop on Unix. This could be prevented if we supply a note about how to preserve crossplatform behavior.
https://bugs.edge.launchpad.net/dulwich/+bug/557585

I've attached a patch that adds required note. Please revise it. It should clearly apply over your changes in r80069. I reworded description towards Python users without C background, but I am still worried that they need a POSIX background to understand umask part.

----------
keywords: +patch
status: closed -> open
Added file: http://bugs.python.org/file16924/8399.os-open-default-behavior.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8399>
_______________________________________

From report at bugs.python.org  Wed Apr 14 21:08:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Apr 2010 19:08:10 +0000
Subject: [issue5277] email message.get_params() and related methods sometimes
	fail.
In-Reply-To: <1234758915.75.0.150242965655.issue5277@psf.upfronthosting.co.za>
Message-ID: <1271272090.19.0.139913453238.issue5277@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks Mark and Ryan for the patches, and Shashwat for the review.  Committed to trunk in r80062, 2.6 in r80063, py3k in r80078, and 3.1 in r80079.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5277>
_______________________________________

From report at bugs.python.org  Wed Apr 14 21:09:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 14 Apr 2010 19:09:25 +0000
Subject: [issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of
	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1271272165.78.0.140757421542.issue8339@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

It looks like any change for this specific case would make tests like handling anyscheme fail.  I am less inclined to do that as opposed to handling this case for invalid url,

I suggest this be handled at user end to fix the proper parsing and constructing correct url. I am closing this as wont-fix.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________

From report at bugs.python.org  Wed Apr 14 21:17:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Apr 2010 19:17:47 +0000
Subject: [issue8399] Document os.open
In-Reply-To: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>
Message-ID: <1271272667.63.0.644107138923.issue8399@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've added a paragraph about O_BINARY in r80080.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8399>
_______________________________________

From report at bugs.python.org  Wed Apr 14 22:09:27 2010
From: report at bugs.python.org (Brian Scearce)
Date: Wed, 14 Apr 2010 20:09:27 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271275767.58.0.627161340132.issue4356@psf.upfronthosting.co.za>


Brian Scearce <bls at pathetique.com> added the comment:

This was closed over a year ago, but since mark.dickinson was asking for convincing use-cases: I'm breaking up a file into line-delimited chunks.  These chunks are non-overlapping, contiguous, and tend to be fairly large, so I'm just recording the start line of each chunk in a 2-ple:

mapping = [
  (10, 'first chunk'),
  (50, 'second chunk'),
  (60, 'third chunk')
]

Lines 10-49 are in the first chunk, lines 50-59 are in the second, lines 60+ are in the third.  So:

def CategorizeLine(line, mapping):
   loc = bisect.bisect([m[0] for m in mapping], line)
   if loc == 0:
      return None # before first chunk
   return mapping[loc-1][1]

It Would Be Nice if I could write the second line as:

   loc = bisect.bisect(mapping, line, key=lambda m:m[0])

The bisect documentation suggests pre-computing the key list, but it seems messy and error-prone to keep a redundant data structure in sync with its source.  I could also rewrite my "mapping" data structure to be two parallel lists instead of one list of 2-ples, but this data structure is more readable and extensible and handles empty lists more naturally.

----------
nosy: +bls

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Wed Apr 14 22:15:10 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Apr 2010 20:15:10 +0000
Subject: [issue8389] Incomprehensible import error
In-Reply-To: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>
Message-ID: <1271276110.4.0.205142254333.issue8389@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

First off, the 'as' clause is not influencing anything; simply try to assign ``t = a.b.t`` and you still get the error.

Second, you are trying to reference a.b in a.b.c through your a.b.t import before a.b has finished importing. This is causing the import system to not have a chance to bind the b module to a.b before you try to reference it.

The reason ``from a.b import t`` works is the 'from' clause is handled after all imports resolve as a separate step, so everything settles, gets imported, and then Python tries to get a.b.t long after a.b if finished.

In other words it's a funky import cycle which you break with ``from a.b import t``. Nothing we can do to change it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8389>
_______________________________________

From report at bugs.python.org  Wed Apr 14 22:40:43 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Apr 2010 20:40:43 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271277643.81.0.00965120193472.issue4356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll take another look at this one.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:04:45 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 14 Apr 2010 21:04:45 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1271279085.35.0.30672724248.issue7301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

py3k should be taken care of as of r80066+r80075

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:20:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 14 Apr 2010 21:20:48 +0000
Subject: [issue8392] unit tests rather light on testing __import__(..., level)
In-Reply-To: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>
Message-ID: <1271280048.21.0.211030399259.issue8392@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding Brett and Nick to nosy, per Misc/maintainers.rst

(Disclaimer: I?m new to issue triaging, tell me if I do something wrong.)

Regards

----------
keywords: +needs review
nosy: +brett.cannon, merwok, ncoghlan
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8392>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:21:28 2010
From: report at bugs.python.org (Jakub Turski)
Date: Wed, 14 Apr 2010 21:21:28 +0000
Subject: [issue3854] Document sqlite3 vs. threads
In-Reply-To: <1221259791.8.0.815426917686.issue3854@psf.upfronthosting.co.za>
Message-ID: <1271280088.26.0.664595814273.issue3854@psf.upfronthosting.co.za>


Changes by Jakub Turski <yacoob at gmail.com>:


----------
nosy: +Jakub.Turski

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3854>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:26:35 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Wed, 14 Apr 2010 21:26:35 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1271280395.2.0.921746245505.issue7316@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

While you are at it, you might want to submit the patch from http://bugs.python.org/issue850728 as well.

It adds timeouts for semaphores. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:35:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Apr 2010 21:35:02 +0000
Subject: [issue5250] Document __instancecheck__ and __subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1271280902.65.0.494999851408.issue5250@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed a similar patch in r80081.  Thanks very much!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:37:23 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Apr 2010 21:37:23 +0000
Subject: [issue8392] unit tests rather light on testing __import__(..., level)
In-Reply-To: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>
Message-ID: <1271281043.71.0.582907735558.issue8392@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, this is the right sort of thing to kick in our direction.

There's a reasonable amount of implicit testing of import's level argument through the relative import tests in test_import and test_runpy, but some explicit tests of direct invocation can't hurt.

As Skip says, the test suite can serve as useful example code, although I couldn't recommend that it *all* be treated that way - we do some pretty weird stuff at times in an effort to stress the code under test or to isolate test cases from each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8392>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:37:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Apr 2010 21:37:41 +0000
Subject: [issue8370] change module "builtins" to "__builtin__" in __import__
	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1271281061.01.0.283395920466.issue8370@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r80082.  The builtins rename happened in 3.0; there are no "version added" or "version changed" marks for 3.0 in the docs, since we regard it as a "clean start".

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8370>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:43:09 2010
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 14 Apr 2010 21:43:09 +0000
Subject: [issue5250] Document __instancecheck__ and __subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1271281389.33.0.690820918456.issue5250@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

This might need to be reopened.

There's a verb missing from he following sentence of the patch:
"This is consistent with the lookup of special methods that called on instances, only that in this case the instance is itself a class."

Secondly, and more importantly, the issubclass() and isinstance() docs don't mention the new special methods in question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________

From report at bugs.python.org  Wed Apr 14 23:48:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Apr 2010 21:48:19 +0000
Subject: [issue5250] Document __instancecheck__ and __subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1271281699.57.0.168612075647.issue5250@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed the missing verb in r80084.  I don't think the new special methods need to be mention in isinstance() or issubclass() docs; they are very rarely needed, and other builtins don't mention their special methods either (e.g. abs(), complex(), or getattr().)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________

From report at bugs.python.org  Thu Apr 15 00:00:07 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 14 Apr 2010 22:00:07 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271282407.78.0.43702838104.issue7946@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Some more remarks:
- COND_TIMED_WAIT macro modifies timeout_result when pthread_cond_timewait expires. But timeout_result is not an int pointer, just an int. So it is never updated, and as a result, bfs_check_depleted is never set after a thread has waited for the current running thread to schedule it in vain (in _bfs_timed_wait).
- the scheduling function bfs_find_task returns the first task that has an expired deadline. since an expired deadline probably means that the scheduler hasn't run for a while, it might be worth it to look for the thread with the oldest deadline and serve it first, instead of stopping at the first one
- calls to COND_WAIT/COND_TIMED_WAIT should be run in loops checking for the predicate, since it might be false even after these call return (spurious wakeups, etc):
"In general, whenever a condition wait returns, the thread has to re-evaluate the predicate associated with the condition wait to determine whether it can safely proceed, should wait again, or should declare a timeout. A return from the wait does not imply that the associated predicate is either true or false. 

It is thus recommended that a condition wait be enclosed in the equivalent of a "while loop" that checks the predicate."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Apr 15 00:01:08 2010
From: report at bugs.python.org (Brian Scearce)
Date: Wed, 14 Apr 2010 22:01:08 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271282468.62.0.616723478816.issue4356@psf.upfronthosting.co.za>


Brian Scearce <bls at pathetique.com> added the comment:

For what it's worth, after I posted my comment, I realized I could use tuple comparison semantics:

   loc = bisect.bisect(mapping, (line,))

since my key happens to be at index 0.  "key=" would still be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Apr 15 00:21:04 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 14 Apr 2010 22:21:04 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1271283664.51.0.270897057016.issue8326@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

this was caused by r76567, introduction of the sem_open configure checks. The build machines building the binary packages for lucid use kernels from the last stable LTS release:

./a.out; echo $?
sem_open: Function not implemented
1
$ uname -r
2.6.24-25-server

I can work around this, but others may be affected as well. can't the required kernel version be checked at runtime?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 15 01:35:58 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Apr 2010 23:35:58 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1271288158.0.0.376867043401.issue8362@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I'm the one who recently added FTPS support to ftplib.py and wrote tests for both FTP and FTPS. I'm not the "maintaner" of the module but I'd like to be notified in case of issues about it, so would it make sense for me to appear in the list?

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Thu Apr 15 02:30:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Apr 2010 00:30:23 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271291423.2.0.552881960464.issue4356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

What would you guys think about adding a class that uses bisect internally so that the keyfunc() never gets called more than once per key?  This could be added to the docs as a cut-and-pastable recipe or it could be added to the module directly:

sd = SortedCollection(iterable, key=keyfunc)
s[i]                  --> getitem at position i
len(s)                --> length
sd.insert_left(item)  --> None
sd.insert_right(item) --> None
sd.find_left(key)     --> item
sd.find_right(key)    --> item
sd.keyfunc            --> the key function 
list(sd)              --> sorted list of items
list(reversed(sd))    --> reverse sorted list of items
s.clear()


The implementation would follow this pattern:

 def insert_left(self, item):
   key = self._keyfunc(item)
   i = bisect_left(self._keys, key)
   self._keys.insert(i, key)
   self._items.insert(i, item)

 def find_left(self, key):
   i = bisect_left(self._keys, key)
   return self._items[i]

 def __iter__(self):
   return iter(self._items)

 def __getitem__(self, i):
   return self._items[i]

----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Apr 15 02:36:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 00:36:05 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1271291765.47.0.691985570159.issue8326@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 15 02:39:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Apr 2010 00:39:00 +0000
Subject: [issue8344] test_tag_configure fails on FreeBSD
In-Reply-To: <1270719913.05.0.699032461994.issue8344@psf.upfronthosting.co.za>
Message-ID: <1271291940.67.0.510519704377.issue8344@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The buildbot seems happy starting from build 486 [1], can this be closed?

[1]: http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%207.2%20trunk/builds/486

----------
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8344>
_______________________________________

From report at bugs.python.org  Thu Apr 15 02:51:27 2010
From: report at bugs.python.org (george hu)
Date: Thu, 15 Apr 2010 00:51:27 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>


New submission from george hu <geohuz at gmail.com>:

Have this problem in python 2.5.4 under windows. 
I'm trying to return a list of files in a directory by using glob. It keeps returning a empty list until I tested/adjusted folder name by removing "[" character from it. Not sure if this is a bug.

glob.glob("c:\abc\afolderwith[test]\*") returns empty list
glob.glob("c:\abc\afolderwithtest]\*") returns files

----------
messages: 103160
nosy: george.hu
severity: normal
status: open
title: glob returns empty list with "[" character in the folder name
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:00:03 2010
From: report at bugs.python.org (ivank)
Date: Thu, 15 Apr 2010 01:00:03 +0000
Subject: [issue8403] dis.dis gives different results if Ctrl-C is pressed
In-Reply-To: <1271293203.08.0.221458450606.issue8403@psf.upfronthosting.co.za>
Message-ID: <1271293203.08.0.221458450606.issue8403@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

If you run
>>> dis.dis(lambda: 99**1000003)
and press Ctrl-C immediately, you'll see the numbers without constant folding:
  1           0 LOAD_CONST               1 (99)
              3 LOAD_CONST               2 (1000003)
              6 BINARY_POWER        
              7 RETURN_VALUE        

If you wait long enough instead (don't press Ctrl-C), you'll see a very big number.

It seems strange to do two different things. Perhaps the KeyboardInterrupt should be rethrown instead?

----------
components: Library (Lib)
messages: 103161
nosy: ivank
severity: normal
status: open
title: dis.dis gives different results if Ctrl-C is pressed
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8403>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:03:24 2010
From: report at bugs.python.org (Timothy Fitz)
Date: Thu, 15 Apr 2010 01:03:24 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271293404.83.0.830443137503.issue8379@psf.upfronthosting.co.za>


Timothy Fitz <timothyfitz at gmail.com> added the comment:

Does that mean you agree that the behavior is a bug?

If we're agreed that the behavior is a bug, then it's just a matter of solving the implementation details. One suggestion is to compile in a __debug__ check at the top of every .pyo file, effectively prepending every file with "if __debug__ == True: raise AssertionError()". Another could be to add a header to the bytecode (clearly waiting for the next major release of Python).

We'll gladly contribute patches once a suitable implementation has been chosen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:06:45 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 15 Apr 2010 01:06:45 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271293605.12.0.272263662327.issue8402@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

When you do :
glob.glob("c:\abc\afolderwith[test]\*") returns empty list
It looks for all files in three directories:
c:\abc\afolderwitht\*
c:\abc\afolderwithe\*
c:\abc\afolderwiths\*

Ofcourse they do not exist so it returns empty list

06:35:05 l0nwlf-MBP:Desktop $ ls -R test
1 2 3
06:35:15 l0nwlf-MBP:Desktop $ ls -R test1
alpha beta  gamma

>>> glob.glob('/Users/l0nwlf/Desktop/test[123]/*')
['/Users/l0nwlf/Desktop/test1/alpha', '/Users/l0nwlf/Desktop/test1/beta', '/Users/l0nwlf/Desktop/test1/gamma']

As you can see, by giving the argument test[123] it looked for test1, test2, test3. Since test1 existed, it gave all the files present within it.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:09:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 15 Apr 2010 01:09:31 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271293771.29.0.443300059571.issue8402@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

See the explanation at http://docs.python.org/library/fnmatch.html#module-fnmatch , which uses the same rules.

----------
nosy: +eric.smith
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:16:55 2010
From: report at bugs.python.org (george hu)
Date: Thu, 15 Apr 2010 01:16:55 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271294215.62.0.589157903815.issue8402@psf.upfronthosting.co.za>


george hu <geohuz at gmail.com> added the comment:

Ok, what if the name of the directory contains "[]" characters? What is the escape string for that?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:23:48 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 15 Apr 2010 01:23:48 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The examples of set operations in http://docs.python.org/dev/library/stdtypes#dictionary-view-objects don't work in the current 2.7 trunk:

-> ./python.exe
Python 2.7b1+ (trunk:80084:80085M, Apr 14 2010, 21:17:06) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> dishes = {'eggs': 2, 'sausage': 1, 'bacon': 1, 'spam': 500}
>>> keys = dishes.viewkeys()
>>> keys & {'eggs', 'bacon', 'salad'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for &: 'dict_keys' and 'set'
>>> keys | {'eggs'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'dict_keys' and 'set'

Is this a documentation bug, and set operations are only supported in 3.x?  Or does the code need to be fixed?

(Assigned to Alexandre, since he committed the backport patch; please feel free to reassign.  Marking as release blocker; if it's a documentation bug, we can lower the priority.)

----------
assignee: alexandre.vassalotti
messages: 103166
nosy: akuchling, alexandre.vassalotti
priority: release blocker
severity: normal
status: open
title: Set operations don't work for dictionary views
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:24:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Apr 2010 01:24:48 +0000
Subject: [issue8403] dis.dis gives different results if Ctrl-C is pressed
In-Reply-To: <1271293203.08.0.221458450606.issue8403@psf.upfronthosting.co.za>
Message-ID: <1271294688.74.0.947100473191.issue8403@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Probably due to the fact that the peepholer avoids constant folding when any exception happens.

----------
nosy: +benjamin.peterson
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8403>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:25:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Apr 2010 01:25:15 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271294715.35.0.828431562369.issue8404@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:27:57 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 15 Apr 2010 01:27:57 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271294877.89.0.441702278292.issue8402@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The documentation for fnmatch.translate, which is what ultimately gets called, says:
   There is no way to quote meta-characters.
Sorry.

If you want to see this changed, you could open a feature request. If you have a patch, that would help!

You probably want to research what the Unix shells use for escaping globs.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:29:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Apr 2010 01:29:58 +0000
Subject: [issue8403] dis.dis gives different results if Ctrl-C is pressed
In-Reply-To: <1271293203.08.0.221458450606.issue8403@psf.upfronthosting.co.za>
Message-ID: <1271294998.61.0.389635971531.issue8403@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Probably due to the fact that the peepholer 
> avoids constant folding when any exception happens.

Yes.  And that is a feature, not a bug.

It would better though if the keyboard interrupt was not swallowed.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8403>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:32:50 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 15 Apr 2010 01:32:50 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271295170.17.0.360478280171.issue8404@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:33:01 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Apr 2010 01:33:01 +0000
Subject: [issue8403] dis.dis gives different results if Ctrl-C is pressed
In-Reply-To: <1271294998.61.0.389635971531.issue8403@psf.upfronthosting.co.za>
Message-ID: <o2k1afaf6161004141832naa0fd9eev14fba6eb719c8c89@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/4/14 Raymond Hettinger <report at bugs.python.org>:
>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
>> Probably due to the fact that the peepholer
>> avoids constant folding when any exception happens.
>
> Yes. ?And that is a feature, not a bug.
>
> It would better though if the keyboard interrupt was not swallowed.

Agreed on both points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8403>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:34:36 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 15 Apr 2010 01:34:36 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271295276.54.0.998986003184.issue8402@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

glob module does not provide what you want.
As a workaround you can try:

os.listdir("c:\abc\afolderwith[test]")

07:02:52 l0nwlf-MBP:Desktop $ ls -R test\[123\]/
1 2 3
>>> os.listdir('/Users/l0nwlf/Desktop/test[123]')
['1', '2', '3']

Changing type to 'Feature Request'

----------
status: pending -> open
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:35:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 01:35:32 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271295332.04.0.965008338764.issue8379@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, Brett said he thought it was not a bug.  If Raymond disagrees, he'll say so.  If I may attempt to channel Brett, I suspect his logic for closing it "won't fix" went more or less like this: "it might be theoretically possible to change this behavior, but it is not something we wish to do."

Unless Raymond disagrees, of course.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:40:21 2010
From: report at bugs.python.org (george hu)
Date: Thu, 15 Apr 2010 01:40:21 +0000
Subject: [issue8402] glob returns empty list with "
In-Reply-To: <1271295276.54.0.998986003184.issue8402@psf.upfronthosting.co.za>
Message-ID: <s2i3c0ab30d1004141840w882783d5x8794c5a9261fd436@mail.gmail.com>


george hu <geohuz at gmail.com> added the comment:

Well, the listdir doesn't support "wildcard", for example,
listdir("*.app"). I know the glob is kind of unix shell style expanding, but
my program is running under windows, it's my tiny script to walk through a
huge directory in my NAS. And there are many directories named with "[]" and
"()" characters amid. May the only way is to program a filter on the
listdir.

On Wed, Apr 14, 2010 at 6:34 PM, Shashwat Anand <report at bugs.python.org>wrote:

>
> Shashwat Anand <anand.shashwat at gmail.com> added the comment:
>
> glob module does not provide what you want.
> As a workaround you can try:
>
> os.listdir("c:\abc\afolderwith[test]")
>
> 07:02:52 l0nwlf-MBP:Desktop $ ls -R test\[123\]/
> 1 2 3
> >>> os.listdir('/Users/l0nwlf/Desktop/test[123]')
> ['1', '2', '3']
>
> Changing type to 'Feature Request'
>
> ----------
> status: pending -> open
> type: behavior -> feature request
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8402>
> _______________________________________
>

----------
title: glob returns empty list with "[" character in the folder name -> glob returns empty list with "
Added file: http://bugs.python.org/file16925/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________
-------------- next part --------------
Well, the listdir doesn&#39;t support &quot;wildcard&quot;, for example, listdir(&quot;*.app&quot;).??I know the glob is kind of unix shell style expanding, but my program is running under windows, it&#39;s my tiny script to walk through a huge directory in my NAS. And there are many directories named with &quot;[]&quot; and &quot;()&quot; characters amid. May the only way is to program a filter on the listdir.<br>
<br><div class="gmail_quote">On Wed, Apr 14, 2010 at 6:34 PM, Shashwat Anand <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Shashwat Anand &lt;<a href="mailto:anand.shashwat at gmail.com">anand.shashwat at gmail.com</a>&gt; added the comment:<br>
<br>
glob module does not provide what you want.<br>
As a workaround you can try:<br>
<br>
os.listdir(&quot;c:\abc\afolderwith[test]&quot;)<br>
<br>
07:02:52 l0nwlf-MBP:Desktop $ ls -R test\[123\]/<br>
1 2 3<br>
&gt;&gt;&gt; os.listdir(&#39;/Users/l0nwlf/Desktop/test[123]&#39;)<br>
[&#39;1&#39;, &#39;2&#39;, &#39;3&#39;]<br>
<br>
Changing type to &#39;Feature Request&#39;<br>
<br>
----------<br>
status: pending -&gt; open<br>
type: behavior -&gt; feature request<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue8402" target="_blank">http://bugs.python.org/issue8402</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Thu Apr 15 03:43:18 2010
From: report at bugs.python.org (george hu)
Date: Thu, 15 Apr 2010 01:43:18 +0000
Subject: [issue8402] glob returns empty list with "
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271295798.34.0.845304653802.issue8402@psf.upfronthosting.co.za>


george hu <geohuz at gmail.com> added the comment:

Well, the listdir doesn't support "wildcard", for example, listdir("*.app"). I know the glob is kind of unix shell style expanding, but my program is running under windows, it's my tiny script to walk through a huge directory in my NAS. And there are many directories named with "[]" and "()" characters amid. May be the only way is to write a filter on the listdir.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:46:56 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 15 Apr 2010 01:46:56 +0000
Subject: [issue8402] glob returns empty list with "
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271296016.61.0.999512307073.issue8402@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

You repeated the same comment twice and added an 'unnamed' file. I assume you did it by mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 03:51:14 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 15 Apr 2010 01:51:14 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271296274.05.0.478944482984.issue8402@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
title: glob returns empty list with " -> glob returns empty list with "[" character in the folder name

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 04:15:14 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 15 Apr 2010 02:15:14 +0000
Subject: [issue8379] if __debug__: has nonobvious behaviour when evaluating
	.pyo without -O
In-Reply-To: <1271295332.04.0.965008338764.issue8379@psf.upfronthosting.co.za>
Message-ID: <v2tbbaeab101004141914r30cf3c50sddceb6cdd1fd73cd@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Apr 14, 2010 at 18:35, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> No, Brett said he thought it was not a bug.  If Raymond disagrees, he'll
> say so.  If I may attempt to channel Brett, I suspect his logic for closing
> it "won't fix" went more or less like this: "it might be theoretically
> possible to change this behavior, but it is not something we wish to do."
>

Yep, that's what I meant.

----------
Added file: http://bugs.python.org/file16926/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8379>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Wed, Apr 14, 2010 at 18:35, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
No, Brett said he thought it was not a bug. ??If Raymond disagrees, he&#39;ll say so. ??If I may attempt to channel Brett, I suspect his logic for closing it &quot;won&#39;t fix&quot; went more or less like this: &quot;it might be theoretically possible to change this behavior, but it is not something we wish to do.&quot;<br>

</blockquote><div><br></div><div>Yep, that&#39;s what I meant.</div></div>

From report at bugs.python.org  Thu Apr 15 04:15:37 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 15 Apr 2010 02:15:37 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271297737.21.0.0649026732198.issue8404@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

It is a bug.

First, the dictviews_as_number is broken; the field for classic division was removed in 3.x, so everything is shifted by one. I included a patch to fix this.

Unfortunately, this isn't enough to fix the issue. There seems to be some overly restrictive type checking going on in the method wrappers. However, I don't have the time to investigate this further today. I should be able to check this next weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu Apr 15 04:16:00 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 15 Apr 2010 02:16:00 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271297760.0.0.820910980849.issue8404@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16927/fix_dictviews_as_number.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu Apr 15 04:21:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 02:21:42 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271298102.59.0.292190302026.issue8402@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file16925/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Thu Apr 15 04:22:47 2010
From: report at bugs.python.org (Jim Shaw)
Date: Thu, 15 Apr 2010 02:22:47 +0000
Subject: [issue6257] Idle terminates on source save while debugging
In-Reply-To: <1244652442.36.0.452724625348.issue6257@psf.upfronthosting.co.za>
Message-ID: <1271298167.13.0.124200729072.issue6257@psf.upfronthosting.co.za>


Jim Shaw <jim at focusbiology.com> added the comment:

I am having the same problem with Windows Vista and Windows 7.

----------
components: +IDLE
nosy: +JimShaw
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6257>
_______________________________________

From report at bugs.python.org  Thu Apr 15 04:42:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 15 Apr 2010 02:42:02 +0000
Subject: [issue8405] Improve test_os._kill (failing on slow machines)
In-Reply-To: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>
Message-ID: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

test_os._kill is used by test_kill_sigterm and test_kill_int and is failing on a slow Windows buildbot due to timing issues between the process starting and the signal being sent. I've checked in a few small time.sleep hacks in the meantime to see if that would help the bot, but I'd like to get a solid fix in there.

The attached patch adds a loop to the test function to see that even if the subprocess doesn't respond right away, it will have a few chances to respond and run the test. If the expected message isn't piped from the subprocess after 5 retries, the test fails.

----------
assignee: brian.curtin
components: Library (Lib), Windows
files: fix_test_os.diff
keywords: patch
messages: 103179
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Improve test_os._kill (failing on slow machines)
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16928/fix_test_os.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8405>
_______________________________________

From report at bugs.python.org  Thu Apr 15 05:09:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Apr 2010 03:09:26 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271300966.38.0.287853461202.issue4356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching a draft of a sorted collection class.

Any comments?

----------
Added file: http://bugs.python.org/file16929/SortedCollection.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Thu Apr 15 05:12:32 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 15 Apr 2010 03:12:32 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

The topic of the vileness of Fink or MacPorts came up in python-dev when
discussing building a Mac installer.  I remembered that a couple /sw and
/opt/local directories are searched unconditionally, making it a bit
more challenging for someone to create a framework build which didn't
rely on one or the other.

The attached makes the addition of /sw/... or /opt/local/... directory
searches conditional on the presence of /sw/bin or /opt/local/bin in
PATH.  I don't have more time to expand upon the concept more, but it
might also be useful to exclude other platform-dependent optional
directories from searching (such as /opt/sfw for Solaris).

----------
components: Build
messages: 103181
nosy: skip.montanaro
severity: normal
status: open
title: Make some setup.py paths exclude-able
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 06:00:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Apr 2010 04:00:15 +0000
Subject: [issue8344] test_tag_configure fails on FreeBSD
In-Reply-To: <1270719913.05.0.699032461994.issue8344@psf.upfronthosting.co.za>
Message-ID: <1271304015.42.0.970427570512.issue8344@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8344>
_______________________________________

From report at bugs.python.org  Thu Apr 15 07:00:39 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 15 Apr 2010 05:00:39 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at twistedmatrix.com>:

Linux offers the signalfd syscall since 2.6.22 (with minor changes afterwards).  This call allows signals to be handled as bytes read out of a file descriptor, rather than as interruptions to the flow of a program.  Quite usefully, this file descriptor can be select()'d on (or poll()'d, epoll()'d, etc) alongside other "normal" file descriptors.

In order to effectively use signalfd(), the signals in question must be blocked, though.  So it makes sense to expose sigprocmask(2) at the same time, in order to allow this blocking to be set up.

----------
assignee: exarkun
components: Extension Modules, Library (Lib)
messages: 103182
nosy: exarkun
priority: normal
severity: normal
status: open
title: expose signalfd(2) and sigprocmask(2) in the signal module
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Apr 15 07:07:56 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 15 Apr 2010 05:07:56 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271308076.29.0.928358107558.issue8407@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

I've started on an implementation of this in /branches/signalfd-issue8407.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Apr 15 07:16:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Apr 2010 05:16:54 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271308614.59.0.078822726362.issue8407@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Notice that 2.7 has seen its first beta release, so no new features are allowed for it. I think it's better to target this feature for 3.2.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Apr 15 07:28:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Apr 2010 05:28:55 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1271309335.88.0.465513736081.issue8279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Dave, file 16727 fails to apply, but apparently still contains necessary pieces. Can you please provide an updated version of the patch against the trunk?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8279>
_______________________________________

From report at bugs.python.org  Thu Apr 15 08:34:02 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Thu, 15 Apr 2010 06:34:02 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271313242.67.0.656514871998.issue8407@psf.upfronthosting.co.za>


Changes by Marcin Bachry <hegel666 at gmail.com>:


----------
nosy: +marcin.bachry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Apr 15 09:27:36 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 15 Apr 2010 07:27:36 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271316456.65.0.497250431358.issue7946@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Please disregard my remark on COND_TIMED_WAIT not updating timeout_result, it's wrong (it's really a macro, not a function...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Apr 15 10:01:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 15 Apr 2010 08:01:48 +0000
Subject: [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Many many Python tools have duplicating code related to getting console properties like width and height to provide pagination and cute progress bars. While the issue seems minor, making such features work crossplatform way requires many tuits. That's why it is highly desirable to have console module inside Python stdlib.

----------
components: Library (Lib)
messages: 103187
nosy: techtonik
severity: normal
status: open
title: need console/pager module
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8408>
_______________________________________

From report at bugs.python.org  Thu Apr 15 11:01:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Apr 2010 09:01:41 +0000
Subject: [issue8326] Cannot import name SemLock on Ubuntu lucid
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1271322101.45.0.262271818544.issue8326@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

As an aside, I don't really understand why the sem_open check is failing on the build machine.  'man sem_overview' says:

"On a system with Linux 2.6 and a glibc that provides the NPTL threading implementation, a complete implementation of POSIX semaphores is provided."

Is some part of this not true for the Ubuntu build machines?

> can't the required kernel version be checked at runtime?

What exact check would that be, and where would you put it?  It seems to me that the check may be more complicated than just looking for a kernel version (e.g., might depend on libc version, on whether POSIX semaphore support is actually compiled into the kernel or not).  Whatever runtime check is used would also need to work for *BSD and other systems.

We could try just doing a sem_open test call somewhere at run time (e.g. when importing the relevant piece of multiprocessing?);  we'd have to find some way to catch the SIGSYS signal that generates on FreeBSD (and on Linux?) though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8326>
_______________________________________

From report at bugs.python.org  Thu Apr 15 11:15:11 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Apr 2010 09:15:11 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271322911.59.0.935273176064.issue8406@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I think this is essentially a duplicate of Issue7713.
(Also there doesn't seem to be an "attached".)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 11:53:31 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Apr 2010 09:53:31 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tcl
	configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1271325211.59.0.959781316115.issue5651@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5651>
_______________________________________

From report at bugs.python.org  Thu Apr 15 11:57:03 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Apr 2010 09:57:03 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tk
	configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1271325423.19.0.799353246199.issue5651@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
title: OS X Installer: add checks to ensure proper Tcl configuration during build -> OS X Installer: add checks to ensure proper Tk configuration during build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5651>
_______________________________________

From report at bugs.python.org  Thu Apr 15 12:45:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 15 Apr 2010 10:45:51 +0000
Subject: [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271328351.3.0.440443305832.issue8408@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

How to get console width:

http://stackoverflow.com/questions/566746/how-to-get-console-window-width-in-python
http://code.activestate.com/recipes/440694-determine-size-of-console-window-on-windows/

PDCurses may contain some public domain code:
http://pdcurses.sourceforge.net/
BSD like licensed Console module from Fredrik Lundh:
http://effbot.org/zone/console-handbook.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8408>
_______________________________________

From report at bugs.python.org  Thu Apr 15 12:53:37 2010
From: report at bugs.python.org (Julian Scheid)
Date: Thu, 15 Apr 2010 10:53:37 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271328817.57.0.0361384339544.issue7490@psf.upfronthosting.co.za>


Julian Scheid <julians37 at googlemail.com> added the comment:

Having this in 2.6/2.7 would be great.

I don't think the ELLIPSIS workaround suggested by Barry works, have you actually tried it?

Below is an example where ELLIPSIS doesn't seem to help (run in 2.6.5).  I have also tried "...Error:" and "...:", and tried replacing ". . ." by "...", to no avail.

I'm assuming this has to do with issue #1192554, or am I making a silly mistake?

Otherwise, are there any other workarounds you can suggest?

Without ellipsis the following example works in 2.6 but of course fails in 3.x.

Failed example:
    Redacted.from_str('1-7@') #doctest: +ELLIPSIS
Expected:
    Traceback (most recent call last):
      . . .
    ...ParserError: <message redacted>:
    1-7@
        ^
    expected digit
Got:
    Traceback (most recent call last):
      <SNIP>
    ParserError: <message redacted>:
    1-7@
        ^
    expected digit

----------
nosy: +Julian.Scheid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 12:54:25 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 15 Apr 2010 10:54:25 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271328865.24.0.576215593461.issue8406@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Let's try this again.

----------
keywords: +patch
Added file: http://bugs.python.org/file16930/setup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 12:59:23 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 15 Apr 2010 10:59:23 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271329163.09.0.942182081291.issue8406@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

The patches referenced in issue7713 just unconditionally delete certain
directories from the search path(s).  This patch (now attached) allows
the user to control that.  I presume, for instance, if the MacPorts
folks don't want /usr/X11/... in search paths that they don't have
/usr/X11/bin in PATH when they build Python.  This concept can be
extended to other such directories.  I was mostly concerned about the
Fink and MacPorts directories since they came up in the thread on
python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 13:00:30 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Thu, 15 Apr 2010 11:00:30 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271329230.72.0.924652336924.issue7490@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

The ellipsis doesn't work, because when you have an ellipsis at the beginning of the message, doctest will not understand that it's supposed to be an Exception, so it doesn't even try to match exceptions, and it will therefore always fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 13:00:57 2010
From: report at bugs.python.org (Julian Scheid)
Date: Thu, 15 Apr 2010 11:00:57 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271329257.98.0.673753790935.issue7490@psf.upfronthosting.co.za>


Julian Scheid <julians37 at googlemail.com> added the comment:

Here's a better example that you can cut and paste.

import optparse

def foo():
    """
    >>> foo() #doctest: +ELLIPSIS
    Traceback (most recent call last):
          . . .
    ...OptionError: option bar: foo
    """
    raise optparse.OptionError('foo', 'bar')

if __name__ == "__main__":
    import doctest
    doctest.testmod()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 13:01:55 2010
From: report at bugs.python.org (Julian Scheid)
Date: Thu, 15 Apr 2010 11:01:55 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271329315.54.0.347845022883.issue7490@psf.upfronthosting.co.za>


Julian Scheid <julians37 at googlemail.com> added the comment:

Ah, right... so there is no easy workaround at present?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 13:06:51 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Thu, 15 Apr 2010 11:06:51 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271329611.39.0.684241448462.issue7490@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

Sure: Catch the exception in the test, and fail if it isn't catched.

>>> try:
...     do_something_that_raises_exception()
...     raise Assertionerror("Exception Blah was not raised")
... except Blah:
...     pass

Ugly, yes, but easy. To make it less ugly you can make a "assertRaises()" like the one that exists on standard unit tests and call that. Not so ugly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 13:26:06 2010
From: report at bugs.python.org (Julian Scheid)
Date: Thu, 15 Apr 2010 11:26:06 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271330766.1.0.768696563927.issue7490@psf.upfronthosting.co.za>


Julian Scheid <julians37 at googlemail.com> added the comment:

Thank you for the suggestion but in my mind that's not a viable workaround, and not just because of uglyness:  I'm using doctest to validate code examples, which are included in the documentation and are meant to be educational.  If I'd change my examples to match the pattern you suggest they might still serve their purpose as a test but they'd become useless as an example.

So it appears there is no real workaround for this issue.  Any chance we can get the patch into 2.7?

By the way, I said earlier that Barry suggested the ELLIPSIS workaround but it was actually ncoghlan who did so - apologies for the confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 13:35:55 2010
From: report at bugs.python.org (Julian Scheid)
Date: Thu, 15 Apr 2010 11:35:55 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271331355.77.0.750799668205.issue7490@psf.upfronthosting.co.za>


Julian Scheid <julians37 at googlemail.com> added the comment:

Hmm, wait.  Here's a variation of your suggestion that works OK-ish even as an example:

>>> try:
...    # ... code that fails ...
... except mypkg.MyException, e:
...    print(str(e))
Expected error message.

This works because it omits the exception type in the output.

It's still far from ideal, because as an example it's more complicated than it would need to be, but I guess it works as a stop-gap solution.

Still, +1 for including the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 13:52:44 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Apr 2010 11:52:44 +0000
Subject: [issue850728] Semaphore.acquire() timeout parameter
Message-ID: <1271332364.06.0.551135484585.issue850728@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850728>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:17:47 2010
From: report at bugs.python.org (Daniel Haertle)
Date: Thu, 15 Apr 2010 12:17:47 +0000
Subject: [issue5419] urllib.request.open(someURL).read() returns a bytes
	object so writing it requires binary mode
In-Reply-To: <1236216086.62.0.687528545638.issue5419@psf.upfronthosting.co.za>
Message-ID: <1271333867.02.0.872606724516.issue5419@psf.upfronthosting.co.za>


Daniel Haertle <haertle at uni-bonn.de> added the comment:

I got struck by the same feature. In addition, currently the docs are wrong in the examples (at http://docs.python.org/dev/py3k/library/urllib.request.html#examples the output of f.read() is a string instead of bytes). There I propose the change from 

>>> import urllib.request
>>> f = urllib.request.urlopen('http://www.python.org/')
>>> print(f.read(100))
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<?xml-stylesheet href="./css/ht2html

to

>>> import urllib.request
>>> f = urllib.request.urlopen('http://www.python.org/')
>>> print(f.read(100).decode('utf-8'))
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtm

The other examples need to be corrected in a similar way.
Even more importantly, the "HOWTO Fetch Internet Resources Using The urllib Package" needs to be corrected too.

In the documentation of urllib.request.urlopen I propose to add a sentence (after the paragraph "This function returns a file-like object...") explaining that reading the object returns bytes that need to be decoded to a string:
"Note that the method read() returns bytes that need to be decoded to a string using decode()."

----------
nosy: +Danh
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5419>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:26:52 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Apr 2010 12:26:52 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271334412.82.0.469616408679.issue8354@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:32:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 12:32:42 +0000
Subject: [issue4079] new urllib2.Request 'timeout' attribute needs to have a
	default
In-Reply-To: <1223490599.12.0.198174561396.issue4079@psf.upfronthosting.co.za>
Message-ID: <1271334762.03.0.0858816745697.issue4079@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Senthil, Facundo, is there a reason this bug shouldn't be fixed, or are we just waiting for someone to come up with a patch?  I'm assuming the latter and setting it to languishing, but maybe this will wake somebody up who is interested in fixing it.

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> unit test needed
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4079>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:34:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 15 Apr 2010 12:34:01 +0000
Subject: [issue5419] urllib.request.open(someURL).read() returns a bytes
	object so writing it requires binary mode
In-Reply-To: <1236216086.62.0.687528545638.issue5419@psf.upfronthosting.co.za>
Message-ID: <1271334841.76.0.0662581968478.issue5419@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee: georg.brandl -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5419>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:37:23 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 15 Apr 2010 12:37:23 +0000
Subject: [issue5419] urllib.request.open(someURL).read() returns a bytes
	object so writing it requires binary mode
In-Reply-To: <1236216086.62.0.687528545638.issue5419@psf.upfronthosting.co.za>
Message-ID: <1271335043.07.0.683253793547.issue5419@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yeah, there a example in the tutorial that was changed recently along similar lines suggested. (http://docs.python.org/dev/py3k/tutorial/stdlib.html#internet-access)
The other examples got to be changed too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5419>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:41:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Apr 2010 12:41:56 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271335316.38.0.947528458312.issue8406@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Without testing it, I'd guess the patch wouldn't hurt but it also wouldn't affect the OS X installer build as the installer script builds a local copy of Sleepycat db4 (since none is included in OS X) and supplies it as an additional local library/include file which is always found first by the setup.py code, so it never gets to searching the additional paths affected by the patch.  If you are building manually and don't supply a local lib, then the build of the dbm extension will either fail or it will try to use a MacPorts or Fink version if available.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:42:20 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Thu, 15 Apr 2010 12:42:20 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271335340.0.0.713037748133.issue8354@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Your patches look good to me.

(They don't fix platforms without sigaction, but as you say they probably don't have siginterrupt, and even if they do they will still have an unfixable race.)

What's the next step?  I can't see an button to add this issue to the "Show Needing Review" queue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:54:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 12:54:19 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271336059.53.0.215375150253.issue8354@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Will the modified test fail on platforms that don't define HAVE_SIGACTION?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 14:57:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 15 Apr 2010 12:57:48 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271336268.94.0.616203377095.issue8406@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: the patch does have a (positive) effect when building the OSX installer: the build-installer script creates private builds of a number of libraries, but setup.py can detect other libraries (such as libintl) as well and we don't guard against that at the moment.

Skip: I'm +0 on including this functionality, but haven't looked at the patch yet.

To be honest I'd must rather remove /opt/local and /sw entirely from setup.py and add new configure flags to specify the location of a number of libraries (e.g. 'configure --with-sleepycat-db=/opt/local').  Explicit configure flags is what other OSS packages seem to use to specify that you like to use a library that is not in /usr or /usr/local.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 15:36:32 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 15 Apr 2010 13:36:32 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271338592.76.0.0631709010968.issue8354@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Will the modified test fail on platforms that don't define HAVE_SIGACTION?

Well, in theory, if the system has siginterrupt but not sigaction, it will fail. But as said, I don't think it's possible, see man siginterrupt:
"      This library routine uses an extension of the sigaction(2) system call
     that is not available in 4.2BSD, hence it should not be used if backward
     compatibility is needed."

and the test right now has this at the beginning:
if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':
    raise unittest.SkipTest("Can't test signal on %s" % \
                                   sys.platform)

So it pretty much assumes that any Unix system has siginterrupt, hence sigaction, so it should be safe.
So I'd say in theory, it will, but I don't think that siginterrupt can be available without sigaction anyway.
So feel free to modify the test, or not ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 15:38:55 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Thu, 15 Apr 2010 13:38:55 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271338735.69.0.0592540237151.issue8354@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Are there any platforms that define HAVE_SIGINTERRUPT but that do not define HAVE_SIGACTION?  If there are, then yes I expect they would fail that test.

It would be a shame to delay this fix just because it doesn't fix all platforms... is it possible to mark that test as a known failure on a platform with siginterrupt but without sigaction?

My initial comment outlined a change that would work for all platforms, but would be more complex.  (I think the signal_noreinstall.diff change would be good to make even with the more complex approach, though.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 15:46:03 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Thu, 15 Apr 2010 13:46:03 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271339163.96.0.291023153.issue8354@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

FWIW, comparing the "change history" sections of <http://www.opengroup.org/onlinepubs/000095399/functions/siginterrupt.html> and <http://www.opengroup.org/onlinepubs/000095399/functions/sigaction.html> suggests that sigaction predates siginterrupt, but it's a wild and varied world out there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 15:50:12 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Thu, 15 Apr 2010 13:50:12 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271339412.39.0.751413835998.issue8407@psf.upfronthosting.co.za>


Changes by Andrew Bennetts <spiv at users.sourceforge.net>:


----------
nosy: +spiv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Apr 15 15:52:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 13:52:52 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271339572.03.0.533462398416.issue8407@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm with Martin, better to target 3.2 IMO.
Does signalfd really bring something compared to set_wakeup_fd()?
The one big difference I can see is that set_wakeup_fd() doesn't transmit the signal number, but this could be fixed if desired (instead of sending '\0', send a byte containing the signal number).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu Apr 15 15:59:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Apr 2010 13:59:10 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271339950.34.0.279698624047.issue7490@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The corner case I was talking about was the one where you actually *want* the old, more restrictive behaviour (i.e. you specifically want to receive 'x.y.Exception' and receiving 'a.b.Exception' instead should fail), but still want to ignore the details of the exception string representation.

With this change in place, that corner case could be handled fairly easily by using the ELLIPSIS option instead of IGNORE_EXCEPTION_DETAIL (or else mandating the exception details as well the type).

This change trips my "feature" meter, so it's probably too late for 2.7 (adding Benjamin to confirm), but definitely a good candidate for 3.2 later in the year.

----------
nosy: +benjamin.peterson
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:01:02 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 15 Apr 2010 14:01:02 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271340062.72.0.33796783667.issue8354@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Well, I just think that the probability of having siginterrupt without sigaction is far less than having a Unix system without siginterrupt (which the current test_signal assumes). Or just drop the patch for the test, it honestly doesn't bother me ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:01:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 14:01:19 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271340079.15.0.0478009354151.issue8354@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, my question was directed at finding out if there were any platforms on which we'd have to add an additional skip (which would mean refactoring that test into two tests).  But if the buildbots are all happy after it is applied we can probably choose to not worry about it until/if we get a bug report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:06:29 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 15 Apr 2010 14:06:29 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271340389.49.0.446081502056.issue8354@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> Will the modified test fail on platforms that don't define HAVE_SIGACTION?

Only if they also have siginterrupt, which seems unlikely (as neologix explained).  The implemented behavior on such platforms is unmodified from current trunk, while the test requires new behavior.

I think it's probably worth testing this new behavior separately from the test for the existing behavior anyway, for the sake of clarity.  If it turns out there's a platform with siginterrupt but not sigaction, then that'll also let the test be skipped there, which is nice (though this case seems unlikely to come up).

I'm not exactly sure how we will know if it is expected to fail, though.  I don't think `HAVE_SIGACTION` is exposed nicely to Python right now.  Perhaps the signal module should make this information available (it's somewhat important now, as it will mean the difference between a nicely working signal.siginterrupt and a not-so-nicely working one).

This quirk probably also bears a mention in the siginterrupt documentation.

A few other thoughts on the code nearby:

  * There seems to be no good reason to special case SIGCHLD in signal_handler.  The comment about infinite recursion has no obvious interpretation to me.  Fortunately, this is irrelevant on platforms with sigaction, because the handler remains installed anyway!

  * The distance between the new #ifndef HAVE_SIGACTION check and the corresponding #ifdef HAVE_SIGACTION in pythonrun.c is somewhat unfortunate.  Someone could very easily change the logic in PyOS_setsig and disturb this relationship.  I'm not sure how this could best be fixed.  A general idea which presents itself is that both of these pieces of code could use a new identifier to make this choice, and that identifier could be named/documented such that it is obvious that it is used in two different places which must be kept synchronized.  Or, some more comments in both places might help.  It seems likely that the remaining SIGCHLD check in handle_signal is only there because whoever updated PyOS_setsig to use sigaction didn't know about it/remember it.

Aside from those points, the fix seems correct and good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:09:22 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 14:09:22 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271340562.22.0.32269834744.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is yet another point:
if _POSIX_SEMAPHORES is defined, thread_pthread.h is designed to use the (fair) semaphore.  If it is not present, or HAVE_BROKEN_POSIX_SEMAPHORES defined, the semaphore is supposed to be emulated using a condition variable.
Now, I don't have access to a mac or linux machine, but does a modern python build perhaps actually have USE_SEMAPHORES defined?  if so, then this entire rant about a broken lock on pthreads is nonsense.

Please note that the "emulated" semaphore is unfair, as I've pointed out, whereas a posix_sem object strives to be fair.  So this "emulation" is not working..

Martin, you are right that some mutexes are indeed fair.  There has been a move towards using unfair mutexes, particularly on multicore machines.  This is because they reduce the "lock convoying" problem.
A fair mutex hands off the lock to a waiting thread.  That thread is then made runnable.  But on a busy system, it may take a while for that thread to actually start running and use the locked resource.  The reesult is that the locked resource is unavailable for a longer time.  An unfair mutex will wake up a waiting thread, yet have that thread compete for the mutex with any interloper that might arrive and claim it.  See e.g. http://www.bluebytesoftware.com/blog/PermaLink,guid,e40c2675-43a3-410f-8f85-616ef7b031aa.aspx and http://developer.amd.com/documentation/articles/Pages/282007123.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:09:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 14:09:41 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271340581.62.0.621563895995.issue7490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think this one is worth making an exception for, since it would mean that a project could have 3.x doctests that also work with 2.7, whereas if we leave it out of 2.7 the doctests have to stay in 2.x format even if the project has (at some future point) dropped support for all earlier versions of 2.x.  (Unless 3to2 can reformat Exceptions in doctest output?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:20:10 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Thu, 15 Apr 2010 14:20:10 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271341210.71.0.098293664363.issue7490@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

It's not possible for 2to3 to reformat exceptions, as the formatting would need to go from TheException to themodule.TheException, and there is no way to figure out the module name...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:21:51 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Apr 2010 14:21:51 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271341311.08.0.955755118847.issue7490@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

With a little more thought, I'm actually keen on including it as well (although the docs still need a bit more tweaking). The 2.x/3.x compatibility point is a good one.

If Benjamin OKs it, I'll include this in the list of things I want to get to for beta2 (said list seems to be getting longer rather than shorter, but...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:28:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 14:28:04 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271340562.22.0.32269834744.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271341808.3425.3.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> if _POSIX_SEMAPHORES is defined, thread_pthread.h is designed to use
> the (fair) semaphore.  If it is not present, or
> HAVE_BROKEN_POSIX_SEMAPHORES defined, the semaphore is supposed to be
> emulated using a condition variable.
> Now, I don't have access to a mac or linux machine, but does a modern
> python build perhaps actually have USE_SEMAPHORES defined?

Yes, it does.
Actually, I find it unlikely that any modern Unix would fall back on the
non-semaphore version. All this code is (mostly) very old.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:28:14 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 15 Apr 2010 14:28:14 +0000
Subject: [issue8409] gettext should honor $LOCPATH environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

LOCPATH is an environment variable recognized by locale(1)

http://man.he.net/?topic=locale&section=all

gettext.find() should probably consult $LOCPATH and use that for localedir if the argument is not given.

----------
assignee: barry
components: Library (Lib)
keywords: easy
messages: 103220
nosy: barry
priority: normal
severity: normal
status: open
title: gettext should honor $LOCPATH environment variable
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8409>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:28:35 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 15 Apr 2010 14:28:35 +0000
Subject: [issue8409] gettext should honor $LOCPATH environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1271341715.6.0.890478185232.issue8409@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8409>
_______________________________________

From report at bugs.python.org  Thu Apr 15 16:28:44 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 15 Apr 2010 14:28:44 +0000
Subject: [issue8409] gettext should honor $LOCPATH environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1271341724.9.0.2341771489.issue8409@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8409>
_______________________________________

From report at bugs.python.org  Thu Apr 15 17:16:06 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 15 Apr 2010 15:16:06 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271336268.94.0.616203377095.issue8406@psf.upfronthosting.co.za>
Message-ID: <19399.11697.725516.880110@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Ronald> To be honest I'd must rather remove /opt/local and /sw entirely
    Ronald> from setup.py and add new configure flags to specify the
    Ronald> location of a number of libraries (e.g. 'configure
    Ronald> --with-sleepycat-db=/opt/local').  Explicit configure flags is
    Ronald> what other OSS packages seem to use to specify that you like to
    Ronald> use a library that is not in /usr or /usr/local.

Right, but then you still have the problem with /usr/local (note the package
patches mentioned in the other issue), and you'd have to go through that
dance for every bit of functionality which might be found in an external
library.

Someone else (David Cornapeau?) mentioned he just uses a chroot jail to
build numpy and scipy installers.  That might ultimately be the best way to
do things.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 17:18:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 15:18:31 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271344711.61.0.886712512756.issue7490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@Lennart: no, in that direction (2.7 to 3.x) there's less of a problem.  You leave the module name off in the doctest, and have 2to3 add the IGNORE_EXCEPTION_DETAIL to the doctest during translation.

I was looking at the farther future case, where a project has moved to 3.x, but is still supporting 2.7 by using *3to2*.  3to2 could theoretically peel off the IGNORE_EXCEPTION_DETAIL and the module name, but I know that 2to3 doesn't touch the *output* of doctests, so I'm thinking that 3to2 probably doesn't either.  (Maybe it could, for the limited case of Exceptions, but that seems like a big enough project to motivate including this patch in 2.7.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 17:24:09 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Thu, 15 Apr 2010 15:24:09 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271345049.24.0.040447657591.issue7490@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

Sure, but +IGNORE_EXCEPTION_DETAIL will only work on Python 3.2+, so 2to3 can't solve the issue. It can only help once 3.2 does the actual solving. ;)

3to2 could simply remove the module name from exceptions in the output. You don't need to touch IGNORE_EXCEPTION_DETAIL for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 17:39:53 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 15:39:53 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271345993.52.0.689698262359.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Oh dear.  I was assuming that the mutex+condition variable were the actual implementation mostly in use on pthreads.  This is because of David's GIL open talk at pycon, where we were looking at the source and bickering about the placement of "pthread_cond_signal()" being after the "pthread_mutex_unlock()" call.  

In which case, more than half of this thread is invalid.  I could, perhaps, start a new defect: "semaphore emulation using condition variable is broken".

However, I just asked a colleague with a os X to compile python 2.7 and _POSIX_SEMAPHORES isn't defined, and so, it is running using the emulation.  Why, I wonder?  Isn't it defined in unistd.h?

Martin, I don't know if you were suggesting that a "fair" mutex would make the emulated semaphore fair too.  You probably weren't, but just in case, the fairness of the mutex is immaterial because it is only held for a short time to guard the internal state of the "semaphore".  You won't see threads queing up on it, but they will queue on the Contition variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 17:42:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 15:42:38 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271345993.52.0.689698262359.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271346282.3425.16.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, I just asked a colleague with a os X to compile python 2.7
> and _POSIX_SEMAPHORES isn't defined, and so, it is running using the
> emulation.  Why, I wonder?  Isn't it defined in unistd.h?

Perhaps a bad combination of defines. Has he checked that the semaphore
path isn't used at all? (just put a #error in the other path) If so,
opening an issue would be good.

I would hope we can drop the emulation path one day.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 17:58:31 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 15 Apr 2010 15:58:31 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271347111.9.0.215636784376.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Final patch with inclusion of detecting invalid urls at netloc and hostname level, tests and NEWS entry.

----------
Added file: http://bugs.python.org/file16931/issue2987-final.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Thu Apr 15 18:05:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 16:05:09 +0000
Subject: [issue850728] Semaphore.acquire() timeout parameter
Message-ID: <1271347509.75.0.515691825237.issue850728@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

2.7 is in (mostly) feature freeze mode, so I'm retargetting this to 3.2.
(yes, this issue is very old; sorry)
I will try to include it (or a variant thereof; the non-blocking + timeout combination doesn't make much sense, so I plan to forbid it) to the py3k branch soon.

----------
assignee:  -> pitrou
stage: unit test needed -> patch review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850728>
_______________________________________

From report at bugs.python.org  Thu Apr 15 18:34:44 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 16:34:44 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271349284.96.0.5465077793.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, we put #error in both places (defining and undefining USE_SEMAPHORES).  The colleague in question is Christian Tismer, he is unlikely to have gotten it wrong.  I am also curious why David Beazley kept talking about the "binary semaphore" when it is apparent that that is supposed to be a "hack" to use on platforms that don't have posix semaphores.

This gets curiouser and curiouser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 18:44:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 16:44:50 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271349890.64.0.182492434471.issue7490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By that logic, 2to3 can't solve anything.  I don't think there's any question that this patch should be applied to 3.2.  3.1 might be an issue as it is a new feature, but maybe we can claim it is a bug fix :)

As for 3to2, like I said I don't think 3to2 touches doctest *output*, so removing the module name would be require the addition of a whole new feature (IIUC).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 18:48:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 16:48:39 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271349284.96.0.5465077793.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271350242.3425.21.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, we put #error in both places (defining and undefining
> USE_SEMAPHORES).  The colleague in question is Christian Tismer, he is
> unlikely to have gotten it wrong.

Ok, so can you or Christian open an issue about it? We should try to fix
it.

> I am also curious why David Beazley kept talking about the "binary
> semaphore" when it is apparent that that is supposed to be a "hack" to
> use on platforms that don't have posix semaphores.

I think David often uses technical terms (such as "semaphore" or
"signal") in more generic meanings than what you might expect :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 18:51:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Apr 2010 16:51:15 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271350275.01.0.473622145203.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm looking at this again, after installing FreeBSD 8.0/amd64 in a VM.

I've reduced Lib/test/test_curses.py to the following 9 lines:

import rlcompleter
import curses
f = open('mytempfile', 'w+b')
stdscr = curses.initscr()
stdscr.putwin(f)
f.seek(0)
curses.getwin(f)
f.close()
curses.endwin()

I then get:

$ ./python Lib/test/regrtest.py test_curses
test_curses
Bus error (core dumped)

>From looking at the core dump, and tracing through with gdb, the core dump  occurs when delwin is called (from PyCursesWindow_Dealloc) on the result of curses.getwin(f), as a result of garbage collection.

The 'import rlcompleter' line appears to be necessary to cause this;  I've no idea why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Thu Apr 15 18:54:51 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 16:54:51 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271350491.31.0.508287695818.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

You do realize, that if we enable the USE_SEMAPHORE, we get the GIL behaviour as seen on windows and with my ROUNDROBIN_GIL implementation, right?

Also, at the GIL open space talk on PyCon, David did show us the "emulation" source code as if it were _the_ gil.  Well, maybe he can explain it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 19:01:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 17:01:13 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271350491.31.0.508287695818.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271350998.3425.31.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> You do realize, that if we enable the USE_SEMAPHORE, we get the GIL
> behaviour as seen on windows and with my ROUNDROBIN_GIL
> implementation, right?

I haven't studied this argument, but I don't see how that contradicts
anything. The main issue witnessed with the 2.x GIL -- and the point of
Dave Beazley's original talk -- is CPU inefficiency (due to far too many
lock operations).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 19:04:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 17:04:05 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271351045.6.0.673336636898.issue8299@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My understanding is that David noticed the problem originally on MacOS.  If the emulation is indeed being used on that platform (and a little googling indicates the MacOS posix semaphore implementation is considered at least slightly broken, and FreeBSD didn't support it until 7.2), then perhaps that is why he was looking at that code.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 19:05:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 17:05:18 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271351118.65.0.996949011008.issue8299@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Also note that his results were much worse on MacOS than anyone was seeing on Linux, which may support this theory :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 19:09:58 2010
From: report at bugs.python.org (David Beazley)
Date: Thu, 15 Apr 2010 17:09:58 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271351398.54.0.516494416296.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I hope everyone realizes that all of this bike-shedding about emulated semaphores versus "real" semaphores is mostly a non-issue.  For one thing,  go look at how a "real" semaphore is implemented by reading the source code to pthreads or some other thread library.  You'll find that semaphores are implemented using the exact same mechanisms that underly condition variables and in some cases, are actually implemented using a mutex lock and a condition variable exactly as Python is doing.

Second, the performance of using "real" semaphores still sucks.   So, all of the arguing about "fairness" and whatnot seems to be a total waste of time in my opinion because it doesn't address the underlying problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 19:23:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 15 Apr 2010 17:23:06 +0000
Subject: [issue5419] urllib.request.open(someURL).read() returns a bytes
	object so writing it requires binary mode
In-Reply-To: <1236216086.62.0.687528545638.issue5419@psf.upfronthosting.co.za>
Message-ID: <1271352186.91.0.847186296643.issue5419@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 80092 and merged into release31-maint in revision 80093. I am marking this as fixed and closed. If there are any similar issues at other places, we will address them as separate bugs.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5419>
_______________________________________

From report at bugs.python.org  Thu Apr 15 19:23:16 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 17:23:16 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271352196.07.0.0794961864334.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

David, I urge you to reconsider:
The "emulated" semaphore is broken because it is unfair.  It is clearly a programming error, born out of naivete about how to implement such primitives.  Proper semaphores therefore cannot be implemented using the "exact same mechanism" because proper semaphores are fair, this one isn't.  You do understand why exactly it is unfair, don't you?

Second, with a fair GIL you still get poor performance on multicore with low values of "tickinterval" but at least you get predictable scheduling.  The emulated semaphore is bad in two ways:  Unpredictable scheduling with thread starvation _and_ poor multicore performance.  I don't understand why you prefer having two problems to one.

I also think it is worth investigating when exactly the "emulaton" semaphore became the "standard".  Did something break in the config script at some point?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 19:32:40 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 17:32:40 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271352760.07.0.527683030846.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Googling a bit gave me this:
http://lists.apple.com/archives/darwin-kernel/2005/Dec/msg00022.html
It would appear that mac os X was at least lacking full posix semaphore support in 2005.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:02:45 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 15 Apr 2010 18:02:45 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1271354565.76.0.535810932445.issue8279@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

New version of patch attached

All tests continue to pass for me.

I believe this will fix the "py-list", "py-locals", "py-print" commands and their respective tests on Ubuntu; I expect py-up/py-down to still fail due to missing gdb.Frame.select method.

----------
Added file: http://bugs.python.org/file16932/fix-PyListTests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8279>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:15:25 2010
From: report at bugs.python.org (Aaron Thomas)
Date: Thu, 15 Apr 2010 18:15:25 +0000
Subject: [issue4453] MSI installer shows error message if "Compile .py files
	to bytecode" option is selected
In-Reply-To: <1227885798.23.0.30127507321.issue4453@psf.upfronthosting.co.za>
Message-ID: <1271355325.63.0.0917535267977.issue4453@psf.upfronthosting.co.za>


Aaron Thomas <aaron.thomas at gmail.com> added the comment:

I can verify this will all versions of Windows 7, and the versions of python 32 and 64 bit. I install this at my work to many machines, and every one of them crashes when trying to 'compile py scripts to bytecode' during install.  I have to left click the setup file after installation (installation fails), and choose 'install' in the windows context menu, then choose 'repair python' for the installation to complete 'successfully'.

----------
nosy: +Aaron.Thomas
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4453>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:16:29 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Apr 2010 18:16:29 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1271355389.5.0.6035935212.issue3823@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Any update about this issue?
This should be marked as high priority, imho.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:25:31 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 15 Apr 2010 18:25:31 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271355931.17.0.489097824214.issue8354@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> * There seems to be no good reason to special case SIGCHLD in signal_handler.  The comment about infinite recursion has no obvious interpretation to me.  Fortunately, this is irrelevant on platforms with sigaction, because the handler remains installed anyway!

I think that it's possible, on certain systems, that setting a signal handler for SIGCHLD while there is un unwaited child (zombie) process triggers a new sending of SIGCHLD.
See http://standards.ieee.org/reading/ieee/interp/1003-1-90_int/pasc-1003.1-132.html:
"The SIGCHLD or SIGCLD were used for implementing job control.
Since I had implemented job control for both BSD and System V,
I pointed out to the standards group that except for SIG_DFL,
these signals had different semantics.

If a signal handler was set for SIGCLD, then a signal would
be generated if there were any unreaped child processes.
When the signal handler was caught in System V, it was reset
by default to SIG_DFL.  However, if a process did not
reap a child and instead reestablished the signal handler,
it would go into an infinite loop since the signal would
be generated again.  The SIGCLD SIG_IGN behavior was that
the system reaped the child when it completed so
that the application didn't have to deal with it.
However, I believe that a process blocked in wait() would
be awakened, but I am not certain of this.

The SIGCHLD signal on the other hand was generated when
a child completed if a signal handler was set at that time.
No signal would be generated if a signal handler was
established while there was waiting children.
The SIGCHLD signal was also generated when a child process stopped.
I believe that BSD treated SIGCHLD SIG_IGN the same way
that it treated SIGCHLD SIG_DFL."

So, there might exist out there a couple systems that merrily mix SIGCLD and SIGCHLD, and re-raise a SIGCHLD when setting a new handler for it when unwaited children exist (which is the case in signal_handle, since child processes can't be waited for before the main thread gets to execute the handler it set up).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:30:30 2010
From: report at bugs.python.org (George Sakkis)
Date: Thu, 15 Apr 2010 18:30:30 +0000
Subject: [issue2090] __import__ with fromlist=[''] causes double
	initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271356230.96.0.541053900654.issue2090@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Just bitten by this (through a 3rd party library that uses this pattern) and I'm wondering why it was closed as invalid. Passing a non-empty fromlist string also imports the tail module but without the side effect of double import, so it's not generally harmful. More surprisingly, a colleague discovered accidentally that the same behavior happens if you pass one or more slashes: __import__('pkg', fromlist=['', '/', '//']) imports 'pkg', 'pkg.', 'pkg./' and 'pkg.//' !

I'm not arguing that using fromlist to import the tail module is not a hack, but the behavior for empty strings and slashes (and whatever else causes multiple imports) is clearly a bug. Unless someone is actually relying on this double import behavior (very unlikely), I think it should be fixed.

----------
nosy: +gsakkis
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:37:12 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 15 Apr 2010 18:37:12 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271356632.5.0.0205588426932.issue8406@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:41:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Apr 2010 18:41:02 +0000
Subject: [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1271356862.84.0.176422943512.issue6916@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6916>
_______________________________________

From report at bugs.python.org  Thu Apr 15 20:44:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Apr 2010 18:44:11 +0000
Subject: [issue8405] Improve test_os._kill (failing on slow machines)
In-Reply-To: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>
Message-ID: <1271357051.46.0.0915935428302.issue8405@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I like this version of the patch better.  Is there any reason not to drop the initial sleep(0.5) and loop 10 times instead?  Any place we can cut down the sleeps so the test suite runs faster on fast machines is good.

As someone else said, it *ought* to be possible to do this without ctypes.  I'll see if I can find some time to play a few subprocess games on my windows KVM instance.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8405>
_______________________________________

From report at bugs.python.org  Thu Apr 15 21:08:23 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 15 Apr 2010 19:08:23 +0000
Subject: [issue5091] Segfault in PyObject_Malloc(), address out of bounds
In-Reply-To: <1233152467.68.0.872773053534.issue5091@psf.upfronthosting.co.za>
Message-ID: <1271358503.83.0.760532378701.issue5091@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It was a long time ago, but:
- I think the interpreter will never be able to catch all memory allocation errors, since because of overcommitting (which Linux does), you can very well get a segmentation fault even if the memory allocation routine (be it malloc or mmap) is successful (i.e. doesn't return NULL): so basically, we don't have any way to avoid that, since we will segfault only when we first touch the allocated page
- since your application was "overflowing internal cache", this might very well be what happened (or it could have been a memory corruption issue :-)

Peers ?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5091>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:00:46 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 20:00:46 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

On pthreads plaforms, if the posix_sem functions aren't available (when _POSIX_SEMAPHORES isn't defined), the python lock is implemented with a mutex and a condition variable.  This appears to be the case on Mac OS X, for example.
The problem is that this lock does not provide fairness to threads trying to acquire it.  This makes it a very poor candidate to implement the GIL, which is a lock that is held all the time, and all the threads are in constant competition to claim.
Other implementations of the python lock, such as the posix_sem based ones (linux) and Event based (MS Windows) provide fairness through that underlying synchronization primitive.

This patch fixes the "emulated semaphore" by making all competing threads wait their turn in the condition variable, thus enjoying whatever fairness that primitive provides.

I've not tested this patch for compilation since I don't have access to a mac to do that.  But the mechanism has been tested successfully on windows.

See also issue 8299, where this has been discussed at length.

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
files: pthread_lock.patch
keywords: needs review, patch, patch
messages: 103247
nosy: krisvale, ronaldoussoren
severity: normal
status: open
title: Fix emulated lock to be 'fair'
versions: Python 2.7
Added file: http://bugs.python.org/file16933/pthread_lock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:31:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Apr 2010 20:31:44 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271363504.28.0.635667842377.issue8406@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Ronald, as far as I can see, the patch as it stands only addresses dbm so more work is needed to address all the other cases, the ones that actually matter. Issue7713 describes a more serious, general problem because a number of other builders / distributers have the same problem, and not only on OS X.  Everyone currently needs to maintain their own set of patches on top of every release to modify setup.py's search behavior.  That's where the effort should go, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:33:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Apr 2010 20:33:00 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <4BC777F9.50205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> On pthreads plaforms, if the posix_sem functions aren't available
> (when _POSIX_SEMAPHORES isn't defined), the python lock is
> implemented with a mutex and a condition variable.  This appears to
> be the case on Mac OS X, for example. The problem is that this lock
> does not provide fairness to threads trying to acquire it. 

Why do you think condition variables don't provide fairness?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:35:30 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Apr 2010 20:35:30 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271363730.39.0.348908560382.issue8406@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Skip, I saw David's chroot remark but I'm having a hard time envisioning how one could use that as a practical matter to build an OS X framework without some *serious* changes to the current configure(s), Makefile(s), and installer script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:35:44 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 20:35:44 +0000
Subject: [issue8411] Improve condition variable emulation on NT
In-Reply-To: <1271363743.96.0.308083925586.issue8411@psf.upfronthosting.co.za>
Message-ID: <1271363743.96.0.308083925586.issue8411@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

As per Antoine's suggestion, here is a patch to improve condition variable emulation on windows.

By using the windows Semaphore (which hasn't always been available) all of the problems in emulating condition variables using Events disappear.  in particular, the "lost wakeup" bug can be elimintated, and the same object easily supports bot the "signal" and "broadcast" mode of waking up threads.  We can also use the CRICITAL_SECTION objects as the associated mutex which is much lighter weight than using a kernel object.

I do think I?ve caught all the corner cases.  It is also simpler to prove because this construct is simpler than the previous one.  If, however, i have missed a spot, I'd be interested to know about it.  Not completely impossible since race conditions are devious beasts.  Ive tested this extensively on Windows.

See also issue 8299 where this implementation was presented.

----------
components: Interpreter Core
files: nt_cond.patch
keywords: needs review, patch, patch
messages: 103251
nosy: krisvale, pitrou
severity: normal
status: open
title: Improve condition variable emulation on NT
versions: Python 3.2
Added file: http://bugs.python.org/file16934/nt_cond.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8411>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:36:55 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Apr 2010 20:36:55 +0000
Subject: [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271363815.66.0.65341679947.issue8408@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please propose on python-ideas before making a bug.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8408>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:49:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Apr 2010 20:49:36 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1271341311.08.0.955755118847.issue7490@psf.upfronthosting.co.za>
Message-ID: <o2g1afaf6161004151349ua85785a3h2988615143d266f2@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/4/15 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> With a little more thought, I'm actually keen on including it as well (although the docs still need a bit more tweaking). The 2.x/3.x compatibility point is a good one.
>
> If Benjamin OKs it, I'll include this in the list of things I want to get to for beta2 (said list seems to be getting longer rather than shorter, but...)

I'm ok with it if you or someone else takes care of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:53:43 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Apr 2010 20:53:43 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271364823.87.0.258294437341.issue8406@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Sorry, Ronald, of course that's what you were suggesting with the proposed configure --with options.  +1 on that.  I'd just want to ensure that any solution addresses any needs in Issue7713, too.  Something like that should.  There are probably other open issues in a similar vein.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Apr 15 22:59:24 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Apr 2010 20:59:24 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271365164.55.0.836449548658.issue2987@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is ok with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:03:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Apr 2010 21:03:10 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271365390.98.0.757309199281.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the top of the backtrace.  (Thanks asmodai for helping me out with working out how to build a FreeBSD system ncurses with debugging information.)

#0  0x0000000801460714 in cannot_delete (win=0x80116b1d0)
    at /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base/lib_delwin.c:54
        p = (struct _win_list *) 0xdbdbdbdbdbdbdbdb
        result = false
#1  0x0000000801460773 in delwin (win=0x80116b1d0)
    at /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base/lib_delwin.c:71
        result = -1
#2  0x000000080170d140 in PyCursesWindow_Dealloc (wo=0x800eb74c0)
    at /usr/home/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:357
No locals.
#3  0x000000000046325f in _Py_Dealloc (op=0x800eb74c0) at Objects/object.c:2211
        dealloc = 0x80170d110 <PyCursesWindow_Dealloc>
#4  0x00000000004578d8 in PyDict_DelItem (op=0x800f121b0, key=0x8011062e0)
    at Objects/dictobject.c:829
        mp = (PyDictObject *) 0x800f121b0
        hash = -3668919459648339544
        ep = (PyDictEntry *) 0x8010cb5a8
        old_value = (PyObject *) 0x800eb74c0
        old_key = (PyObject *) 0x8011062e0
        __func__ = "PyDict_DelItem"
#5  0x0000000000458a48 in dict_ass_sub (mp=0x800f121b0, v=0x8011062e0, w=0x0)
---Type <return> to continue, or q <return> to quit---
    at Objects/dictobject.c:1184
No locals.
#6  0x000000000041aadd in PyObject_DelItem (o=0x800f121b0, key=0x8011062e0)
    at Objects/abstract.c:205
        m = (PyMappingMethods *) 0x6c2960

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:05:47 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 15 Apr 2010 21:05:47 +0000
Subject: [issue8409] gettext should honor $LOCPATH environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1271365547.94.0.224428166119.issue8409@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

LOCPATH is not used by GNU gettext.
/usr/share/locale/XX/... - message translation files (GNU gettext)
/usr/lib/locale/xx_XX*/ - locale (GNU libc)

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8409>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:10:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 21:10:00 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271352760.07.0.527683030846.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271365915.3475.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Googling a bit gave me this:
> http://lists.apple.com/archives/darwin-kernel/2005/Dec/msg00022.html
> It would appear that mac os X was at least lacking full posix semaphore support in 2005.

Hmm.  OS X really sucks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:24:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Apr 2010 21:24:17 +0000
Subject: [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271366657.78.0.240931049544.issue8408@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8408>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:31:34 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 15 Apr 2010 21:31:34 +0000
Subject: [issue2090] __import__ with fromlist=[''] causes double
	initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271367094.11.0.458547552272.issue2090@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If you want a justification, think of it as undefined behavior. When you use an empty string in fromlist you are essentially simulating ``from pkg import`` which makes absolutely no sense, so no one has cared enough to try to fix this. It's such a hack that I don't think people need to worry about fixing it, especially with a more sanctioned way to do it and with importlib being available in PyPI and running in Python 2.3 and later.

Now if someone bothers to submit a patch to fix the issue that is reasonable then it can be considered for fixing, but I view this as such a nonsensical call signature that I personally don't see the need to have someone burn some time on this unless they really care. As a compromise I have made this a "wont fix" bug, but I still don't see the need to open the bug again.

----------
priority: normal -> low
resolution: invalid -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:47:06 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Apr 2010 21:47:06 +0000
Subject: [issue2090] __import__ with fromlist=[''] causes double
	initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271368026.47.0.445291360389.issue2090@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with Brett.  For the most part, we don't care about implementation artifacts and undefined behaviors (as long as it doesn't segfault).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:49:54 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 15 Apr 2010 21:49:54 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271368194.13.0.109717646953.issue7384@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Could I get a login on the buildbot to make a fix?

I bet the problem is with the stdscr object.  PyCurses_InitScr()
does 'return (PyObject *)PyCursesWindow_New(stdscr);'.

PyCursesWindow_Dealloc() does:
  if (wo->win != stdscr) delwin(wo->win);

I bet FreeBSD is clearing contents of the stdscr global variable.  The condition in PyCursesWindow_Dealloc() is then true, and it tries to delwin() the old value, which is in wo->win.

One fix might be to keep a reference to that PyCursesWindow object holding stdscr, and change dealloc to 'if (wo != saved_stdscr_object)'.  Or maybe, since multiple calls to initscr() will create multiple window objects holding the value of stdscr, window objects should have a 'do_not_delwin' flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:54:28 2010
From: report at bugs.python.org (Garen)
Date: Thu, 15 Apr 2010 21:54:28 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1271368468.5.0.00498129890718.issue4111@psf.upfronthosting.co.za>


Changes by Garen <garen.parham at gmail.com>:


----------
nosy: +Garen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:56:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Apr 2010 21:56:42 +0000
Subject: [issue2090] __import__ with fromlist=[''] causes double
	initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271368602.81.0.968694019858.issue2090@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Since ``from pkg import`` makes no sense, would it be okay if __import__ with an empty fromlist or slashes raised an error?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:57:49 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 15 Apr 2010 21:57:49 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271368669.12.0.988238964103.issue7384@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Here's a possible patch; it at least doesn't seem to break the module on MacOS, though MacOS doesn't crash with the current code either.

----------
keywords: +patch
Added file: http://bugs.python.org/file16935/freebsd-curses.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Thu Apr 15 23:58:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Apr 2010 21:58:20 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271368700.09.0.508508990655.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Could I get a login on the buildbot to make a fix?

I think David Bolen (db3l) is the maintainer.  David?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 16 00:00:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Apr 2010 22:00:24 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271368824.31.0.490443599568.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Here's a possible patch

Thanks.  I'll give it a try on my FreeBSD VM and report back.
BTW, did you mean to include the threading change in that patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 16 00:10:32 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 15 Apr 2010 22:10:32 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1271368602.81.0.968694019858.issue2090@psf.upfronthosting.co.za>
Message-ID: <w2gbbaeab101004151510w67c346a5w8084402582572fd5@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Apr 15, 2010 at 14:56, ??ric Araujo <report at bugs.python.org> wrote:

That's fine with me if someone wrote a patch that did that.

----------
title: __import__ with fromlist=[''] causes double initialization of modules -> __import__ with fromlist=
Added file: http://bugs.python.org/file16936/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Thu, Apr 15, 2010 at 14:56, ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Since ``from pkg import`` makes no sense, would it be okay if __import__ with an empty fromlist or slashes raised an error?<br>
<br></blockquote><div><br></div><div>That&#39;s fine with me if someone wrote a patch that did that.</div></div>

From report at bugs.python.org  Fri Apr 16 00:11:53 2010
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Thu, 15 Apr 2010 22:11:53 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271369513.65.0.140053540094.issue7384@psf.upfronthosting.co.za>


Changes by Jeroen Ruigrok van der Werven <asmodai at in-nomine.org>:


----------
nosy: +asmodai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 16 00:20:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Apr 2010 22:20:10 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271370010.46.0.896341346348.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

With that patch, I'm still getting the core dump (with the traceback looking pretty much as it did before).

When I traced through this with gdb, I didn't see stdscr getting set to 0 at any point.  Unless I missed any, the only curses library calls made (in sequence) were:

1. initscr() -> new window win  (=stdscr, presumably)
2. putwin(file, win)
3. getwin(file) -> new window win2, with win2 != win
4. freewin(win2) -> segfault
---
and presumably without the segfault, there would have been calls
to freewin(win) and endwin() too.


And I'm at a complete loss to explain why importing rlcompleter makes a difference.  (importing readline also causes the segfault).  I don't think it's just to do with random memory changes, since if I replace the readline or rlcompleter import by any other randomly chosen python module then there's no segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 16 00:20:32 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 15 Apr 2010 22:20:32 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271370032.99.0.757886313765.issue2090@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Although now that I think about it, there is a slightly sticky situation of someone using '' or some name with a slash for a key in __dict__. The usage in fromlist would then be "reasonable", but the semantics would be somewhat odd as fromlist is really only needed to trigger other imports.

It's probably safe to still make it an error, although it shouldn't be special-cased just for slashes and spaces but specifically the logic triggering the double import.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Fri Apr 16 00:33:50 2010
From: report at bugs.python.org (George Sakkis)
Date: Thu, 15 Apr 2010 22:33:50 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271370830.25.0.963174091487.issue2090@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

> When you use an empty string in fromlist you are essentially simulating 
> ``from pkg import`` which makes absolutely no sense, so no one has
> cared enough to try to fix this.

``from pkg import __bogus__, 123, @$%`` doesn't make sense either and yet the equivalent __import__ call doesn't cause multiple imports neither binds __name__ to bogus strings, it just imports and returns pkg.

> Since ``from pkg import`` makes no sense, would it be okay if
> __import__ with an empty fromlist or slashes raised an error?

No, this would break lots of working code and would be inconsistent anyway with other invalid fromlist inputs. The backwards compatible solution would be to treat the empty string (and slashes) like every other input, i.e. prevent multiple imports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Fri Apr 16 00:34:48 2010
From: report at bugs.python.org (Garen)
Date: Thu, 15 Apr 2010 22:34:48 +0000
Subject: [issue5671] Speed up pickling of lists in cPickle
In-Reply-To: <1238700497.01.0.638889592432.issue5671@psf.upfronthosting.co.za>
Message-ID: <1271370888.84.0.513677021697.issue5671@psf.upfronthosting.co.za>


Changes by Garen <garen.parham at gmail.com>:


----------
nosy: +Garen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5671>
_______________________________________

From report at bugs.python.org  Fri Apr 16 00:51:33 2010
From: report at bugs.python.org (George Sakkis)
Date: Thu, 15 Apr 2010 22:51:33 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271371893.99.0.733883319131.issue2090@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

More fun findings: dots are special-cased too, but only if they don't appear consecutively (!);

~$ cat pkg/__init__.py
print  __name__

~$ python -c "__import__('pkg', fromlist=['.'])"
pkg
pkg..
~$ python -c "__import__('pkg', fromlist=['..'])"
pkg
~$ python -c "__import__('pkg', fromlist=['...'])"
pkg
~$ python -c "__import__('pkg', fromlist=['././//.'])"
pkg
pkg.././//.
~$ python -c "__import__('pkg', fromlist=['././../'])"
pkg

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:09:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Apr 2010 23:09:31 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271372971.02.0.235738300022.issue8410@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't understand why you claim your patched version is fair. As far as I can tell, if you have three threads A, B and C all routinely trying to take this lock, your implementation can perfectly well bounce between A and B without ever giving the lock to C.

----------
nosy: +pitrou
priority:  -> normal
type:  -> behavior
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:10:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2010 23:10:45 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271373045.74.0.817817363602.issue8394@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

amaury> Your patch should handle the case when name2 is a bytearray.

Ok, fixed. I also tested None: Python does segfault :-) New patch rejects None value.

----------
Added file: http://bugs.python.org/file16937/ctypes_dlopen_surrogates-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:10:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2010 23:10:55 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271373055.6.0.504192225862.issue8394@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16921/ctypes_dlopen_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:11:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2010 23:11:21 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271373081.44.0.740525776687.issue8394@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16937/ctypes_dlopen_surrogates-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:11:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2010 23:11:50 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271373110.59.0.757158325704.issue8394@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(oops, my patch included unrelated changes about trailing spaces)

----------
Added file: http://bugs.python.org/file16938/ctypes_dlopen_surrogates-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:17:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2010 23:17:23 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271373443.63.0.699192967615.issue8393@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch supporting bytearray type (remove the buggy assertion).

----------
Added file: http://bugs.python.org/file16939/posixsubprocess_cwd-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:17:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2010 23:17:28 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271373448.33.0.801476337981.issue8393@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16920/posixsubprocess_cwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:20:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Apr 2010 23:20:26 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1271373626.69.0.127947858045.issue7606@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What do you think about my solution (convert the traceback to ASCII to avoid the encoding issue)? If you would like to support non-ASCII characters in HTTP headers, you should open a new issue. For the compatibility, I prefer to use pure ASCII headers because I fear that third party programs doesn't support non-ASCII headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Fri Apr 16 01:29:14 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Thu, 15 Apr 2010 23:29:14 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1271374154.94.0.555018365572.issue8354@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

> I'm not exactly sure how we will know if it is expected to fail,
> though.  I don't think `HAVE_SIGACTION` is exposed nicely to Python
> right now.

It might be useful to have the contents of pyconfig.h exposed as a dict somehow.  Maybe call it sys._pyconfig_h?

A less ambitious change would be to expose just HAVE_SIGACTION as e.g. signal._have_sigaction.

I agree with r.david.murray that we probably don't need to bother unless a buildbot or someone reports that this test fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Fri Apr 16 02:07:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 00:07:25 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271376445.96.0.721976920269.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch doesn't work for types bytes and bytearray.

I noticed that py3k uses surrogateescape to encode environment variable values ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Fri Apr 16 02:10:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 00:10:28 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271376628.61.0.443322783431.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Other notes: Environment variable *names* use also surrogateescape "encoding". os.spawnve() and os.spawnvpe() should also be patched (the code should also be factorized).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:00:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 01:00:31 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271379631.41.0.549637890602.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch:
 - factorize code between execve(), spawnve() and spawnvpe()
 - support also surrogates in environment variable names
 - support bytes and bytearray (bytearray cannot be used as a dictionary key, but my patch supports it)
 - remove unrelated fix (my first patch contains a fix for os.system(), also about surrogates)

Because of the factorization, the error messages doesn't contain the function name anymore. spawnve() and spawnvpe() omit BEGINLIBPATH and ENDLIBPATH, as execve(): "that Would Confuse Programs if Passed On". I suppose that if execve() ignore them, spawn*e() should also ignore them.

I don't have an OS/2, so I'm unable to test my patch on this OS :-/

Note: The patch fixes also subprocess to support bytes and bytearray in the environment dictionary.

----------
Added file: http://bugs.python.org/file16940/os_execvpe_surrogates-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:10:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 01:10:22 +0000
Subject: [issue8412] os.system() doesn't support surrogates nor bytes
In-Reply-To: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>
Message-ID: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

os.system() doesn't support bytes, bytearray not str containing surrogates.

Attached patch uses PyUnicode_FSConverter, bytes2str and release_bytes in (the non-Windows version of) os.system() to support all of this. It locks the buffer because os.system() releases the GIL when calling system().

----------
components: Library (Lib), Unicode
files: os_system_surrogates.patch
keywords: patch
messages: 103280
nosy: haypo
severity: normal
status: open
title: os.system() doesn't support surrogates nor bytes
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16941/os_system_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8412>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:10:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 01:10:46 +0000
Subject: [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: <1271380246.57.0.890958258964.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +os.system() doesn't support surrogates nor bytes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:12:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 01:12:20 +0000
Subject: [issue8412] os.system() doesn't support surrogates nor bytes
In-Reply-To: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>
Message-ID: <1271380340.84.0.836319105255.issue8412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8391 (os.execvpe env) and #8393 (subprocess cwd).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8412>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:14:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 01:14:54 +0000
Subject: [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: <1271380494.56.0.504271553988.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +pickle is unable to encode unicode surrogates

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:16:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 01:16:56 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271380616.56.0.455377884903.issue8391@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16918/os_execvpe_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:28:10 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 16 Apr 2010 01:28:10 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

String interpolation doesn't work with sys.version_info in Python versions in which sys.version_info is a named tuple. It's a regression in Python 2.7 and 3.1. This problem doesn't concern named tuples created using collections.namedtuple().

This problem might also concern sys.getwindowsversion(), but I don't have access to Windows system, so I can't check it.

$ python2.6 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
2.6.5-final-0
$ python2.7 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: not enough arguments for format string
$ python3.0 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
3.0.1-final-0
$ python3.1 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: not enough arguments for format string

----------
components: Library (Lib)
messages: 103282
nosy: Arfrever
severity: normal
status: open
title: String interpolation doesn't work with sys.version_info
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:33:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 01:33:33 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271381613.85.0.794909012886.issue8413@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:36:58 2010
From: report at bugs.python.org (Jon Buller)
Date: Fri, 16 Apr 2010 01:36:58 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <4B9987D4.6030809@bullers.net>
Message-ID: <4BC7BF2E.1060108@bullers.net>


Jon Buller <jon at bullers.net> added the comment:

I found that python 2.4.5 will compile and install on this machine,
though I don't know if that helps anyone or not, or how to track this
down further.  (At least I can run mercurial on that machine again.)

On 03/11/10 18:16, Jon Buller wrote:
>
> Jon Buller<jon at bullers.net>  added the comment:
>
> This is bad.  The problem went away and the test completed without the
> segfault.  If you think the output would help track anything down, let
> me know and I'll
> save and upload it somewhere.  (Or I could hand out an SSH account via
> IPv6 to the machine...  With some effort, I could probably reconfigure
> my network to get it
> on one of my 2 IPv4 addresses.)
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue7424>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7424>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:49:15 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Fri, 16 Apr 2010 01:49:15 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

I'm adding some assert tests to test_grammar.py to verify that the assert statement raises (or doesn't raise) an AssertionError properly.

NOTE: I'm currently helping Dino port IronPython tests into CPython. This is part of that series.

----------
components: Tests
files: test_grammar.v2.patch
keywords: patch
messages: 103284
nosy: gnofi
severity: normal
status: open
title: Add test cases for assert
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16942/test_grammar.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8414>
_______________________________________

From report at bugs.python.org  Fri Apr 16 03:49:28 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Fri, 16 Apr 2010 01:49:28 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1271382568.95.0.934200638824.issue8414@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file16943/test_grammar.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8414>
_______________________________________

From report at bugs.python.org  Fri Apr 16 04:47:33 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 16 Apr 2010 02:47:33 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271386053.47.0.446940900092.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Committed into trunk in revision 80101

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Fri Apr 16 04:54:30 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 02:54:30 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1271386470.79.0.828631011759.issue8414@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I propose you move all the assert test cases into there own test method and decorate it with @unittest.skipUnless(__debug__).

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8414>
_______________________________________

From report at bugs.python.org  Fri Apr 16 04:57:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 02:57:05 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1271386625.83.0.434981979027.issue8414@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Wouldn't it be better to test e.args instead or in addition to str(e)?
Skipping the whole test if __debug__ is False is also a good idea.

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8414>
_______________________________________

From report at bugs.python.org  Fri Apr 16 05:08:00 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 16 Apr 2010 03:08:00 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271387280.65.0.0884229738706.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged into py3k in revision 80102 and release31-maint in revision 80103.

Thanks for the patches, Tony and Hans. I have acknowledged it in NEWS file too.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Fri Apr 16 05:39:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 03:39:26 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271389166.78.0.287396769439.issue4356@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file16929/SortedCollection.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Fri Apr 16 05:39:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 03:39:54 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271389194.88.0.87646605979.issue4356@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file16944/SortedCollection.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Fri Apr 16 06:28:24 2010
From: report at bugs.python.org (H Krishnan)
Date: Fri, 16 Apr 2010 04:28:24 +0000
Subject: [issue8415] namedtuple vs tuple
In-Reply-To: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>
Message-ID: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>


New submission from H Krishnan <hetchkay at gmail.com>:

Named tuples and tuples have different creation behavior. Changing a tuple to a namedtuple will involve changing the usage as well. For example:

>>> ntuple = collections.namedtuple("ntuple", "a,b")
>>> ntuple(1,2)
ntuple(a=1, b=2)
>>> tuple(1,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: tuple() takes at most 1 argument (2 given)
>>> tuple([1,2])
(1, 2)
>>> ntuple([1,2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __new__() takes exactly 3 arguments (2 given)
>>>

Because of this, to create a tuple object given a 'tuple class', we need to do something like:
def makeTuple(tupleCls, *args):
   if hasattr(tupleCls, "_fields"):
      return tupleCls(*args)
   else:
      return tupleCls(args)

My suggestion: A namedtuple should also accept a single iterable as argument, in which case, the iterable will be broken up and assigned to individual fields.
This will break an existing behaviour of namedtuple: if only one field is present in the namedtuple and an iterable is passed to the namedtuple, that field is currently assigned the iterable. However, namedtuples are seldom used for single fields and so this may not be that important.

----------
components: None
messages: 103289
nosy: hkrishnan
severity: normal
status: open
title: namedtuple vs tuple
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8415>
_______________________________________

From report at bugs.python.org  Fri Apr 16 06:49:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 04:49:35 +0000
Subject: [issue8415] namedtuple vs tuple
In-Reply-To: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>
Message-ID: <1271393375.27.0.601848805176.issue8415@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

You should propose this on the python-ideas mailing list first.
Anyway it's already too late to do this on Python 2.x, and since it's not backward compatible for the 1-element case, it won't probably be accepted for 3.x either, so I suggest closing this as reject.
Adding Raymond to the nosy so he can take a decision.

----------
components: +Library (Lib) -None
nosy: +ezio.melotti, rhettinger
priority:  -> low
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8415>
_______________________________________

From report at bugs.python.org  Fri Apr 16 07:40:31 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 05:40:31 +0000
Subject: [issue8415] namedtuple vs tuple
In-Reply-To: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>
Message-ID: <1271396431.48.0.0334960258922.issue8415@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, this was by design.  There were two possible constructors, one using positional arguments or keywords and one from an iterable.  Either one could have been the main constructor.  A number of use cases favored the one that we choose.  It was a good decision, but not a perfect one.

To construct a namedtuple directly from an existing tuple, either use:
  ntuple(*t)
or
  ntuple._make(t)

The class is functioning as designed, documented, and tested.  There is no way to change it without breaking most existing uses.  Closing as rejected.

----------
assignee:  -> rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8415>
_______________________________________

From report at bugs.python.org  Fri Apr 16 07:56:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 05:56:57 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271397417.0.0.339646551837.issue8401@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This happens because bytearray_ass_subscript() (Objects/bytearrayobject.c:588) calls PyByteArray_FromObject() (:641) that in turn calls bytearray_init() (:746), so the results are similar to the ones returned by calling bytearray(...) directly.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Fri Apr 16 08:03:54 2010
From: report at bugs.python.org (Santiago Gala)
Date: Fri, 16 Apr 2010 06:03:54 +0000
Subject: [issue8416] python 2.6.5 documentation can't search
In-Reply-To: <1271397834.22.0.547082855086.issue8416@psf.upfronthosting.co.za>
Message-ID: <1271397834.22.0.547082855086.issue8416@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

http://docs.python.org/release/2.6.5/search.html?q=regular+expression

fails. It fails because

http://docs.python.org/release/2.6.5/searchindex.js

returns 404 NOT FOUND

There are really two bugs here:
* that the file is not there, and
* that the page gives no clue that there is something broken inside

IMO the second one is more important: the page stays forever with the Searching and the dots moving...

I reported against build and Documentation as I'm not sure if the web site belongs here and where is the issue originating.

----------
assignee: georg.brandl
components: Documentation
messages: 103293
nosy: georg.brandl, sgala
severity: normal
status: open
title: python 2.6.5 documentation can't search
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8416>
_______________________________________

From report at bugs.python.org  Fri Apr 16 08:05:07 2010
From: report at bugs.python.org (Alex)
Date: Fri, 16 Apr 2010 06:05:07 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1271397907.31.0.177162473421.issue4356@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Looks nice to me, however I wonder if there isn't some overlap with the requests to add a key= kwarg to heapq methods (and the discussion about adding a Heap class there).

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Fri Apr 16 08:09:52 2010
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 16 Apr 2010 06:09:52 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271398192.09.0.956659068133.issue7384@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

For the record, this happens on FreeBSD 8 as well.

It seems it is still the same bug as what I reported back in March 2009 on the Python-dev list.

If you run the test stand-alone with ./python Lib/test/regrtest.py -uall test_curses it passes and prints "1 test OK".

If you add something like test__all__ before it it will crash with a SIGSEGV: segmentation fault (core dumped).

Mark's condensed test case switches to a SIGBUS, which is a bit different.

Mark, did your initial backtrace look like this:

#0  0x282e115e in memcpy () from /lib/libc.so.7
#1  0x282de375 in fwrite () from /lib/libc.so.7
#2  0x282de132 in fwrite () from /lib/libc.so.7
#3  0x28b7a1ca in putwin (win=0x28409640, filep=0x282f39f8)
    at /newusr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base/lib_screen.c:132
#4  0x28d9b361 in PyCursesWindow_PutWin (self=0x28442ef0, args=0x2867f80c)
    at /home/asmodai/projects/python/Modules/_cursesmodule.c:1351
#5  0x080da60d in PyEval_EvalFrameEx (f=0x296d760c, throwflag=0)
    at Python/ceval.c:4013
#6  0x080db10e in PyEval_EvalFrameEx (f=0x296a948c, throwflag=0)
    at Python/ceval.c:4099
#7  0x080db10e in PyEval_EvalFrameEx (f=0x29692d8c, throwflag=0)
    at Python/ceval.c:4099
#8  0x080dc68b in PyEval_EvalCodeEx (co=0x297675c0, globals=0x2866bbdc,
    locals=0x2866bbdc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:3253
#9  0x080dc7d7 in PyEval_EvalCode (co=0x297675c0, globals=0x2866bbdc,
    locals=0x2866bbdc) at Python/ceval.c:666
#10 0x080ef70c in PyImport_ExecCodeModuleEx (
    name=0xbfbfd683 "test.test_curses", co=0x297675c0,
    pathname=0xbfbfd223 "/home/asmodai/projects/python/Lib/test/test_curses.py")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 16 08:45:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 06:45:07 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271400307.36.0.904341611442.issue8401@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a proof of concept that fixes the problem.

The doc of bytearray() says about its first arg:
 * If it is a string, you must also give the encoding [...].
 * If it is an integer, the array will have that size and will be initialized with null bytes.
 * If it is an object conforming to the buffer interface, a read-only buffer of the object will be used to initialize the bytes array.
 * If it is an iterable, it must be an iterable of integers in the range 0 <= x < 256, which are used as the initial contents of the array.

All these things except the string[1] and the integer seem OK to me while assigning to a slice, so in the patch I've special-cased ints to raise a TypeError (it fails already for unicode strings).

[1]: note that string here means unicode string (the doc should probably be more specific about it.). Byte strings work fine, but for unicode strings there's no way to specify the encoding while doing ba[:] = u'ustring'.

----------
keywords: +patch
stage: needs patch -> unit test needed
Added file: http://bugs.python.org/file16945/issue8401.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Fri Apr 16 08:52:47 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Apr 2010 06:52:47 +0000
Subject: [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271400767.52.0.0883875519611.issue8408@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is not a bug, but a "feature request".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8408>
_______________________________________

From report at bugs.python.org  Fri Apr 16 09:06:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 07:06:28 +0000
Subject: [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271401588.4.0.14213393411.issue8408@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8408>
_______________________________________

From report at bugs.python.org  Fri Apr 16 09:27:15 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 07:27:15 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271402835.02.0.20469095666.issue8401@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

Empty string is an iterable of integers in the range 0 <= x < 256, so it should be allowed.

>>> all(isinstance(x, int) and 0 <= x < 256 for x in "")
True
>>> bytearray()[:] = ""
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument without an encoding

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Fri Apr 16 09:35:37 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 07:35:37 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271403337.67.0.0641195193023.issue8401@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Not really, chars are not ints and anyway the empty string fall in the first case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Fri Apr 16 09:43:56 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 07:43:56 +0000
Subject: [issue8417] bytes and bytearray constructors raise TypeError for very
	large ints
In-Reply-To: <1271403836.14.0.808706592166.issue8417@psf.upfronthosting.co.za>
Message-ID: <1271403836.14.0.808706592166.issue8417@psf.upfronthosting.co.za>


New submission from Eugene Kapun <abacabadabacaba at gmail.com>:

>>> bytes(10)
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> bytes(10 ** 100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable

----------
components: Interpreter Core
messages: 103300
nosy: abacabadabacaba
severity: normal
status: open
title: bytes and bytearray constructors raise TypeError for very large ints
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8417>
_______________________________________

From report at bugs.python.org  Fri Apr 16 09:54:11 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 07:54:11 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1271404451.44.0.622405956429.issue1766304@psf.upfronthosting.co.za>


Changes by Eugene Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:00:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 08:00:14 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1271404814.89.0.687936602308.issue1766304@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I suggest closing this:  it's been implemented (for range) in Python 3.x, and I think it's too late for 2.x now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:00:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 08:00:37 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1271404837.78.0.232162327474.issue1766304@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:13:47 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 08:13:47 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271405627.24.0.553117181904.issue8401@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

> Not really, chars are not ints
Yes, however, empty string contains exactly zero chars.
> and anyway the empty string fall in the first case.
Strings aren't mentioned in documentation of bytearray slice assignment. However, I think that bytearray constructor should accept empty string too, without an encoding, for consistency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:16:59 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Apr 2010 08:16:59 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271405819.01.0.157259112373.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I am not convinced with -1 +1 argumentation. Can somebody properly summarize arguments behind the decision? Democracy is good, but it is a pity to see a technical proposal fail because of personal reasons.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:17:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 08:17:55 +0000
Subject: [issue8417] bytes and bytearray constructors raise TypeError for very
	large ints
In-Reply-To: <1271403836.14.0.808706592166.issue8417@psf.upfronthosting.co.za>
Message-ID: <1271405875.61.0.630740323787.issue8417@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> unit test needed
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8417>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:26:53 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Apr 2010 08:26:53 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271406413.42.0.209693996946.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I.e. if you put a -1 or +1 - put it with a short sentence that summarizes the key factor in your decision. There is no +0 or -0 that are used to give everybody else a hint about your feelings towards.


For example:
+1 - I use patch.py diff.py counterpart that accepts only unified diffs without any options, so it would be nice if diff.py generated unified diffs without any options as well

-1 - I don't use diff.py to generate my diffs, I do not care that it is not a part of standard library, I know that it's output format is incompatible with unix diff(1) format, and I still want diff.py to generate incompatible context diffs by default, even though I could always generate them with -c option

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:49:38 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 16 Apr 2010 08:49:38 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271407778.35.0.645298438109.issue8413@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This affects any type implemented as PyStructSequence. For example, sys.flags has the same behavior.

----------
components: +Interpreter Core -Library (Lib)
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:51:55 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 08:51:55 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271407915.62.0.885502444709.issue8401@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

__doc__ of bytearray says:
> bytearray(iterable_of_ints) -> bytearray
> bytearray(string, encoding[, errors]) -> bytearray
> bytearray(bytes_or_bytearray) -> mutable copy of bytes_or_bytearray
> bytearray(memory_view) -> bytearray
So, unless an encoding is given, empty string should be interpreted as an iterable of ints. BTW, documentation and docstring should be made consistent with each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Fri Apr 16 10:55:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 08:55:29 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271408129.96.0.094756643671.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Mark, did your initial backtrace look like this:

No;  the segfault was definitely happening in delwin rather than putwin.  But I did see something like your backtrace when I tried to use ncurses from ports (installed in /usr/local) rather than the system ncurses.  This was all on FreeBSD 8.0/amd64, by the way, running in a VM on Parallels.  I got the same results both when working directly within the VM terminal, and when ssh'ing to the VM from an OS X Terminal.

Maybe running this through Valgrind or something similar might show what's going on.  (Though it's not clear from a quick google whether Valgrind works on FreeBSD.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 16 11:38:02 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Apr 2010 09:38:02 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271410682.61.0.13854711056.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Valgrind can be installed by:

cd /usr/ports/devel/valgrind && make install


Then you can do (curses_test.py is your short test program):

1) valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python curses_test.py

2) valgrind --suppressions=Misc/valgrind-python.supp ./python curses_test.py


Valgrind finds invalid writes. The problem with 1) is that the
terminal is in an unusable state, so controlling gdb isn't possible.

The best thing is probably to use 2) and wade through the unformatted
output starting here:

 ==12043== Invalid write of size 8
 ==12043==    at 0x27A71B7: getwin (in/li /libncursesw.so.8)                                                                             ==12043==    by 0x2A3EAAB: PyCurses_GetWin (_cursesmodule.c:1902)
       ==12043==    by 0x4573FB: PyEval_EvalFrameEx (ceval.c:3833)
                                                                  ==12043==    by 0x457DF9: PyEval_EvalCodeEx (ceval.c:3282)


(I don't have time to do that right now, I might do it later.)

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 16 12:24:33 2010
From: report at bugs.python.org (Grant Bowman)
Date: Fri, 16 Apr 2010 10:24:33 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1271413473.56.0.652471838329.issue762963@psf.upfronthosting.co.za>


Grant Bowman <grantbow at gmail.com> added the comment:

Is there anything others like me can do to help get this fixed?

----------
nosy: +grantbow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Fri Apr 16 12:46:44 2010
From: report at bugs.python.org (David Beazley)
Date: Fri, 16 Apr 2010 10:46:44 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271414804.99.0.28366188812.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I'm sorry, but even in the presence of fair locking, I still don't like this patch.   The main problem is that it confuses fair locking with fair CPU use---something that this patch does not and can not achieve on any platform.

The main problem is that everything is still based on the execution of interpreter ticks.  However, interpreter ticks have wildly varying execution times dependent upon the code that's running.   Thus, executing 1000 ticks might take significantly longer in one thread than another.   Under a FIFO scheduler based on "fair" locking, the thread with the longer-running ticks is going to unfairly hog the GIL and the CPU.  For example, if thread 1 takes 95 usec to execute 1000 ticks and thread 2 takes 5 usec to execute 1000 ticks, then thread 1 is going to end up hogging about 95% of the CPU cycles, starving thread 2.   To me, that doesn't sound especially "fair." 

It would be much better to have fairness where threads are guaranteed to get an equal time slice of CPU cycles regardless of how many ticks they're executing.  In other words, it would be much better if the two threads above each got 50% of the CPU cycles.   The only way you're ever going to be able to do that is to base thread scheduling on timing.   The new GIL in Python 3 makes an effort to do this even though some issues are still being worked out with it.

On a slightly unrelated note, I just tried some experiments on Linux with the GIL implemented as condition variables and with semaphores.   I honestly didn't see any noticeable performance difference between the two versions.  I also didn't see any kind of purported "fair" scheduling of threads using the semaphore version.  Both versions exhibit the same performance problems as described in my GIL talk (albeit not to the same extreme as on OS-X).  Based on my own reading of the pthreads source code (yes, I have looked), I can't really draw any conclusion about the fairness of semaphores.   Under the covers, it's all based on futex locks (the "f" in futex referring to "fast", not "fair" by the way). I know that the original paper on futexes has some experiments with fair lock scheduling, but I honestly don't know if that is being used in the Linux kernel or by pthreads.   My understanding is that by default, futexes do not guarantee fairness.  To know for certain with semaphores, much more low-level investigation would be required.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Fri Apr 16 12:57:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Apr 2010 10:57:27 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271415447.26.0.634101515833.issue8413@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Fri Apr 16 13:21:28 2010
From: report at bugs.python.org (David Beazley)
Date: Fri, 16 Apr 2010 11:21:28 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271416888.97.0.561783906683.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I've attached a test "fair.py" that gives an example of the fair CPU scheduling issue.  In this test, there are two threads, one of which has fast-running ticks, one of which has slow-running ticks.  

Here is their sequential performance (OS-X, Python 2.6):

slow: 5.71
fast: 0.32

Here is their threaded performance (OS-X, Python 2.6.4):

slow : 5.99
fast : 6.04    (Notice : Huge jump in execution, unfair CPU)

Here is their threaded performance using the Py3K New GIL:

slow : 5.96
fast : 0.67    (Notice : Fair CPU use--time only doubled)

Using Linux with semaphores gives no benefit here.  The fast code is stalled in the same way.   For example: here are my Linux results (Ubuntu 8.10, Python-2.6.4, dual-core, using semaphores):

Sequential:
    slow : 6.24
    fast : 0.59
Threaded:
    slow : 6.40
    fast : 6.69    (even slower than the slow code!)

----------
Added file: http://bugs.python.org/file16946/fair.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Fri Apr 16 13:29:33 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 16 Apr 2010 11:29:33 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271417373.88.0.556386205644.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Reverted the check-in made to 3.1 maint (in r80104). Features should not go in there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Fri Apr 16 13:44:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 16 Apr 2010 11:44:06 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271418246.29.0.239680795374.issue8410@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Martin, it isn't the condition variable which is unfair, but how the constructed locking apparatus is unfair that is the problem.  This lock is written by a Tim, whom I assume to be Tim Peters.  I quote his comment:  
"In general, if the bit can be acquired instantly, it is, else the pair is used to block the thread until the bit is cleared.     9 May 1994 tim at ksr.com"

Herein lies the problem.  This is the behaviour of "greedy" or "unfair" mutexes, not that of "fair" semaphores.  The lock is made 'free' and the just signaled thread has to _race_ to acquire it.

Since the exact mechanics seem to be unclair to many, let me just step you through the series of events.
1) A has the lock, B is waiting for it.  the bit is "set".
2) A releases the lock:  Clears the bit, signals the condition variable.
3) A tries to immediately reacquire the lock.  Sees the bit cleared, sets it, and claims the lock.
4) B wakes up from the condition variable.  Sees the bit "set" and goes back to sleep.  It has lost the race to A.

If the lock were based on a semaphore, the events would be different:
1) A has the semaphore, B is waiting for it, sem.value == 0
2) A releases (signals) the semaphore.  B is made runnable. sem.value stays at 0
3) A tries to immediately reacquire the lock.  Finds the sem.value at 0 and blocks.
4) B wakes up and executes, now the owner of the lock. sem.value stays at 0.

This particular patch implements the latter behaviour by explicitly entering a "handoff" period.  If you want, I can submit a different patch which emulates a semaphore perfectly.  perhaps that is easier to understand, since semaphores are very familiar to people.

The key difference between Tim's lock is that the semaphore "hands off" ownership to a particular waiting thread.  The semaphore doesn't enter a state of "free" so that thread have to race to lock it.  It is this race which is unfair and which the just-releasing lock almost always wins.

If you are asking "why would we want an unfair lock, then?", see issue 8299 where I point out some links that discuss unfair locks and their role in combating lock convoys.


Antoine, if we have A, B, and C, all competing for the lock, at any one point, only one of the three has the lock.  Say, A.  The others are waiting on the condition variable.
Condition variables are generally implemented in a "fair" manner, so that all threads that "wait" on it are woken up in a roughly FIFO manner.  If not exactly, then at least in the long run.  All of the threads have to enter the condition variable's wait queue to acquire the lock.  Because of this, the lock is handed off to the threads in roughly the same order that they enter the condition variable?s wait state.

If, in your example, C is waiting on the condition variable, then A and B, whenever they give up the lock, they will hand it off a single thread which is woken up, typcally the one at the head of the condition variable's internal queue.  If the condition variable is implemented properly, there is no way that A and B can just flip-flop without C never being the thread to be woken up next.

As so often, the proof is in the pudding.  Try your ccprof.py script with the do_yield turned off.
You can also implement an explicitly FIFO condition variable, as I did in issue 8299, if you don't trust the condition variable's own internal mechanism to treat its waiting threads fairly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Fri Apr 16 13:45:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 11:45:40 +0000
Subject: [issue8412] os.system() doesn't support surrogates nor bytes
In-Reply-To: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>
Message-ID: <1271418340.44.0.641602012846.issue8412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to py3k as r80105. Let see if buildbots are happy or not :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8412>
_______________________________________

From report at bugs.python.org  Fri Apr 16 14:05:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 12:05:00 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271419500.33.0.485110604946.issue8413@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Fri Apr 16 14:12:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 12:12:19 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1271419939.19.0.817580651639.issue8314@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Committed as r79892.

Commited to py3k (r80106), but blocked in 3.1 (r80107) because Python 3.1 uses libffi 3.0.5.

----------
nosy: +haypo
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8314>
_______________________________________

From report at bugs.python.org  Fri Apr 16 14:26:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 12:26:32 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271420792.2.0.686868136323.issue4970@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited as r80108 to py3k: "Add CS_GNU_LIBC_VERSION and CS_GNU_LIBPTHREAD_VERSION constants for constr(), and disable test_execvpe_with_bad_program() of test_os if the libc uses linuxthreads to avoid the "unknown signal 32" bug (see issue #4970)."

Wait for the buildbot to port it to trunk (and maybe 2.6 and 3.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Fri Apr 16 14:44:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 12:44:21 +0000
Subject: [issue8405] Improve test_os._kill (failing on slow machines)
In-Reply-To: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>
Message-ID: <1271421861.7.0.171960842591.issue8405@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

With the patch, the test have 1.0 second to succeed. I would prefer 5.0 or 10.0 seconds: it should not waste the 10 seconds because it should succeed if a new milliseconds. But if the machine is "slow" (which is the topic of the issue), you can give some more seconds to the test. So max=100, sleep=0.1

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8405>
_______________________________________

From report at bugs.python.org  Fri Apr 16 14:48:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 12:48:25 +0000
Subject: [issue8412] os.system() doesn't support surrogates nor bytes
In-Reply-To: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>
Message-ID: <1271422105.39.0.0912888457802.issue8412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Commited to py3k as r80105

The buildbots look happy: backported to 3.1 as r80110.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8412>
_______________________________________

From report at bugs.python.org  Fri Apr 16 14:48:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 12:48:34 +0000
Subject: [issue8412] os.system() doesn't support surrogates nor bytes
In-Reply-To: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>
Message-ID: <1271422114.47.0.903534513361.issue8412@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8412>
_______________________________________

From report at bugs.python.org  Fri Apr 16 14:50:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 12:50:49 +0000
Subject: [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271422249.05.0.978275209661.issue8408@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin was using the term 'bug' as a synonym for 'issue in the tracker'.  The point is that a feature like this (a whole new module) is not an appropriate tracker item.  In most cases the procedure for getting a new module included in the stdlib is distinctly non-trivial and generally requires, among other things, that the module get proven by distribution via PyPI first.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8408>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:08:40 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 16 Apr 2010 13:08:40 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271423320.75.0.919190912083.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16830/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:10:19 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 16 Apr 2010 13:10:19 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271423419.76.0.68555579714.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I uploaded an update to bfs.patch which improves behavior in particular on non-Linux multi-core (4+) machines. 

Hi Charles-Francois, Thanks for taking the time to review this patch!

> - nothing guarantees that you'll get a msec resolution

Right, the code should behave well with low precision clocks as long as short (sub-tick) tasks are not synchronized with the slice interval. There is a related discussion of this problem in schedulers in the section on sub-tick accounting in: http://ck.kolivas.org/patches/bfs/sched-BFS.txt

On which target systems can we expect not to have high precision clock?

> - gettimeofday returns you wall clock time: if a process that modifies time is running, e.g. ntpd, you'll likely to run into trouble. the value returned is _not_ monotonic, but clock_gettime(CLOCK_MONOTONIC) is
> - inline functions are used, but it's not ANSI
> - static inline long double get_timestamp(void) {
>    struct timeval tv;
>    GETTIMEOFDAY(&tv);
>    return (long double) tv.tv_sec + tv.tv_usec * 0.000001;
> }

I added timestamp capping to the code. timestamp is used for waiting and therefore I think the source should be either CLOCK_REALTIME or gettimeofday().

> > `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, which based its speculative operation on the number of elapsed opcodes (and which also gave bad latency numbers on the regex workload).
>
> I find this suspicous too. I haven't looked at the patch in detail, but what does the number of elapsed opcodes offers you over the timesplice expiration approach ?

More accurate yielding. It is possible a better mechanism can be thought of and/or maybe it is indeed redundant.

> It is thus recommended that a condition wait be enclosed in the equivalent of a "while loop" that checks the predicate."

Done.

----------
Added file: http://bugs.python.org/file16947/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:12:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 13:12:16 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1271423536.93.0.332977002986.issue762963@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Review the code, test the patch, confirm that it fixes the problem and doesn't break anything else, and report your results here.  That doesn't guarantee that it will get applied, but it definitely helps.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:28:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Apr 2010 13:28:26 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1271424506.14.0.944560968938.issue7606@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What do you think about my solution (convert the traceback to ASCII to
> avoid the encoding issue)?

It's fine for me. Perhaps you should add a comment to explain why this is necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:28:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 13:28:38 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1271424518.3.0.086321140804.issue7606@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r80112 (py3k). Waiting for the buildbots before te backport to 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:45:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 13:45:59 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1271425559.19.0.961646294747.issue8362@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@?ric: even if you prepare the patches, I find I'm not interested in doing the checkins.  If someone else wants to take this on that's fine with me, but I'm not going to do it.

----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:47:22 2010
From: report at bugs.python.org (Alf P. Steinbach)
Date: Fri, 16 Apr 2010 13:47:22 +0000
Subject: [issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on
	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>


New submission from Alf P. Steinbach <alfps at start.no>:

Python 3.1.1 in Windows XP Prof, appears to be a Windows-only problem

Effect: on program exit the interpreter crashes with exception  0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER at address 0x78588389, which appears to be in [msvcr90.dll].

To reproduce: very difficult. I had this occur tree times when, after not running any Python program for a while, hitting Ctrl C at the first prompt of the enclosed program. On subsequent runs (not waiting) the bug does *not* manifest. Possibly a timing issue?

Possibly the same bug: ticket #85 for PyInstaller, <url: http://www.pyinstaller.org/ticket/85> has same exception code and same address and also occurring at program exit. Reported as not manifesting in Linux, only Windows. If same bug may be more reliable way to reproduce.

PS: I reported two or three bugs earlier; one was fixed in 3.1.2. But the "Your issues" link shows no issues for me. Trying to report that via "Report tracker problem" it doesn't recognize me as logged in, and maintains that my login attempt is invalid. So there's like a bug in the tracker's reporting scheme for reporting the bug in the tracker. :-)

----------
components: Interpreter Core
files: sum.v4.py
messages: 103325
nosy: alfps
severity: normal
status: open
title: Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file16948/sum.v4.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8418>
_______________________________________

From report at bugs.python.org  Fri Apr 16 15:52:32 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 16 Apr 2010 13:52:32 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271425952.67.0.264395071803.issue8407@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> The one big difference I can see is that set_wakeup_fd() doesn't transmit the signal number, but this could be fixed if desired (instead of sending '\0', send a byte containing the signal number).

There's a lot more information than the signal number available as well.  The signalfd_siginfo struct has 16 fields in it now and may have more in the future.

Another advantage is that this approach allows all asynchronous preemption to be disabled.  This side-steps the possibility of hitting any signal bugs in CPython itself.  Of course, any such bugs that are found should be fixed, but fixing them is often quite challenging and involves lots of complex domain-specific knowledge.  In comparison, the signalfd and sigprocmask extensions are quite straight-forward and self-contained.

It's also possible to have several signalfds, each with a different signal mask.  set_wakeup_fd is limited to a single fd per-process.

sigprocmask has other uses all by itself, of course, like delaying the delivery of signals while some sensitive code runs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri Apr 16 16:04:28 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 16 Apr 2010 14:04:28 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1271426668.81.0.909901602507.issue7490@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Fri Apr 16 16:22:21 2010
From: report at bugs.python.org (Alf P. Steinbach)
Date: Fri, 16 Apr 2010 14:22:21 +0000
Subject: [issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on
	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1271427741.51.0.773363204933.issue8418@psf.upfronthosting.co.za>


Alf P. Steinbach <alfps at start.no> added the comment:

It now seems almost certain that it's /necessary/ to not have run any Python programs for a while (say, 10 minutes?) in order for the bug to manifest when using Ctrl C in the enclosed program.

Also, I forgot to mention, the SEH exception occurs *while the program is printing the traceback*.

Except that the last line is not displayed until the tell-Bill-Gates-about-it box is clicked away, it consistently manages to print

<output>
C:\Documents and Settings\Alf> sum.v4.py
This program computes the sum of two numbers A and B.

Number A, please: Traceback (most recent call last):
  File "C:\Documents and Settings\Alf\sum.v4.py", line 13, in <module>
</output>

When it doesn't crash it displays four more lines of traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8418>
_______________________________________

From report at bugs.python.org  Fri Apr 16 16:45:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 14:45:57 +0000
Subject: [issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on
	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1271429157.8.0.609283942902.issue8418@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The meta-tracker (the tracker to report problems with the tracker) is a separate tracker and you have to create a new login there.  I agree that this is awkward, but nobody has stepped up to fix it yet.

'your issues' is issues assigned to you, and 'normal' users can never have issues assigned to them.  There's already an issue in the meta tracker about this.  You can use the 'search' interface to search for bugs created by you...sooner or later someone will submit a patch to the meta tracker to put such a search in the left hand menu.

I don't have any input on the windows bug, but I'll add Brian Curtin as nosy in case he has any thoughts.

----------
nosy: +brian.curtin, r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8418>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:00:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 15:00:13 +0000
Subject: [issue7605] test_cmd_line fails with non-ascii path
In-Reply-To: <1262209476.63.0.735770885688.issue7605@psf.upfronthosting.co.za>
Message-ID: <1271430013.19.0.893049474628.issue7605@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is that the print is failing because Python uses ASCII encoding for stdout. Attached patch encodes sys.path to ASCII using backslashreplace to avoid the encoding issue.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file16949/test_cmd_line.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7605>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:03:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 15:03:05 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In all versions of CPython right now, the following works.

>>> dict({1:2}, **{3:4})
{1: 2, 3: 4}

Other Python implementations raise TypeError for this;  CPython should probably do the same, beginning with deprecating this behaviour in Python 3.2 and removing it in 3.3.

>From a python-dev posting[1] by Alex Gaynor:

"""
I ran into the follow behavior while making sure Django works
correctly on PyPy.  The following behavior was observed in all tested
versions of CPython (2.5, 3.1):

>>> def f(**kwargs):
...     print(kwargs)
...
>>> kwargs = {1: 3}
>>>
>>> dict({}, **kwargs)
{1: 3}
>>> f(**kwargs)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: f() keywords must be strings
>>>

This behavior seems pretty strange to me, indeed PyPy gives the
TypeError for both attempts.  I just wanted to confirm that it was in
fact intentional.
"""

Raghuram Devarakonda says (in the same python-dev thread):

"I ran into same issue with Django on Jython yesterday [1] since Jython
too gives TypeError for 'dict({}, **kwargs)'."

Guido, on the suggestion that both the CPython and PyPy behaviour be left as is, and that the behaviour be regarded as implementation defined:

"That is just going to cause some programs to have a portability
surprise. I think one or the other should be fixed. I am fine with declaring dict({}, **{1:3}) illegal, since after all it is abuse of the ** mechanism. We should deprecate it in at least one version though."


[1] http://mail.python.org/pipermail/python-dev/2010-April/099427.html

----------
components: Interpreter Core
messages: 103330
nosy: mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: dict constructor allows invalid identifiers in **kwargs
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:10:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 15:10:25 +0000
Subject: [issue8417] bytes and bytearray constructors raise TypeError for very
	large ints
In-Reply-To: <1271403836.14.0.808706592166.issue8417@psf.upfronthosting.co.za>
Message-ID: <1271430625.06.0.521293568205.issue8417@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8417>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:15:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 15:15:57 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271430957.25.0.233592563986.issue8419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The issue applies to dict.update as well:

>>> d = {1:2}
>>> d.update({3:4}, **{5:6})
>>> d
{1: 2, 3: 4, 5: 6}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:26:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 15:26:11 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271431571.56.0.947201817744.issue8419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Update:  IronPython also produces a TypeError here (thanks Michael Foord and Dino Viehland).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:43:35 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 15:43:35 +0000
Subject: [issue8420] set_lookkey is unsafe
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>


New submission from Eugene Kapun <abacabadabacaba at gmail.com>:

I've noticed that set_lookkey (in Objects/setobject.c) does some unsafe things:
Objects/setobject.c:
> if (entry->hash == hash) {
> 	startkey = entry->key;
> 	Py_INCREF(startkey);
> 	cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
> 	Py_DECREF(startkey);
At this point, object pointed to by startkey could be deallocated, and then new object may be allocated at the same address.
> 	if (cmp < 0)
> 		return NULL;
> 	if (table == so->table && entry->key == startkey) {
At this point, the table may be reallocated at the same address but with different (possibly smaller) size, so entry->key may be in deallocated memory. Also, entry->key may be equal to startkey but still point to an object other than one key was compared with.
> 		if (cmp > 0)
> 			return entry;
> 	}
> 	else {
> 		/* The compare did major nasty stuff to the
> 		 * set:  start over.
> 		 */
> 		return set_lookkey(so, key, hash);
This can lead to infinite recursion.
> 	}

----------
components: Interpreter Core
messages: 103333
nosy: abacabadabacaba
severity: normal
status: open
title: set_lookkey is unsafe
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:45:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 15:45:00 +0000
Subject: [issue7605] test_cmd_line fails with non-ascii path
In-Reply-To: <1262209476.63.0.735770885688.issue7605@psf.upfronthosting.co.za>
Message-ID: <1271432700.62.0.9795001512.issue7605@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed: r80116 (py3k), r80117 (3.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7605>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:45:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 15:45:30 +0000
Subject: [issue7605] test_cmd_line fails with non-ascii path
In-Reply-To: <1262209476.63.0.735770885688.issue7605@psf.upfronthosting.co.za>
Message-ID: <1271432730.17.0.729554061059.issue7605@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7605>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:48:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 15:48:47 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1271432927.75.0.97469228101.issue7606@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Commited: r80112 (py3k)

Looks good: r80118 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Fri Apr 16 17:51:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 16 Apr 2010 15:51:02 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271433062.21.0.65503779638.issue8419@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:15:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 16:15:49 +0000
Subject: [issue8420] set_lookkey is unsafe
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271434549.03.0.854149907384.issue8420@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:17:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 16:17:45 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271434665.32.0.659468210192.issue8413@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:20:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 16:20:09 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1271434809.28.0.665452516319.issue1766304@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

As an implementation detail, it isn't too late to put this into 2.x if it is something we care about.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:26:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:26:46 +0000
Subject: [issue8421] tiger buildbot: unable to resolv hostname address
In-Reply-To: <1271435206.59.0.838389424852.issue8421@psf.upfronthosting.co.za>
Message-ID: <1271435206.59.0.838389424852.issue8421@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/6/steps/test/logs/stdio:
======================================================================
ERROR: testSockName (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_socket.py", line 504, in testSockName
    my_ip_addr = socket.gethostbyname(socket.gethostname())
socket.gaierror: [Errno 7] No address associated with nodename

----------
messages: 103337
nosy: haypo
severity: normal
status: open
title: tiger buildbot: unable to resolv hostname address
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8421>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:31:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:31:08 +0000
Subject: [issue8422] tiger buildbot: test_abspath_issue3426 failure
	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/6/steps/test/logs/stdio

test test_ntpath failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_genericpath.py", line 288, in test_abspath_issue3426
    with support.temp_cwd(b'\xe7w\xf0'):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/contextlib.py", line 17, in __enter__
    return next(self.gen)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 392, in temp_cwd
    os.mkdir(name)
OSError: [Errno 22] Invalid argument

As discussed on IRC: Mac OS X deny the creation of a directory with an invalid utf8 name. The test should be skipped on Mac OS X (sys.platform == 'darwin').

----------
messages: 103338
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8422>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:31:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:31:24 +0000
Subject: [issue8422] tiger buildbot: test_abspath_issue3426 failure
	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1271435484.38.0.396803813743.issue8422@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Library (Lib)
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8422>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:34:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 16:34:47 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1271435687.35.0.833254577855.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fix merged to release31-maint in r80119.  Thanks, Victor.

----------
components: +Tests
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:35:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:35:49 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/6/steps/test/logs/stdio

test test_pep277 failed -- multiple errors occurred; run in verbose mode for details
Re-running test test_pep277 in verbose mode
test_directory (test.test_pep277.UnicodeFileTests) ... ok
test_failures (test.test_pep277.UnicodeFileTests) ... ok
test_listdir (test.test_pep277.UnicodeFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeFileTests) ... ERROR
test_open (test.test_pep277.UnicodeFileTests) ... ok
test_rename (test.test_pep277.UnicodeFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFDFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFKCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFKDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKDFileTests) ... ok

======================================================================
ERROR: test_normalize (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
test test_pep277 crashed -- <class 'UnicodeEncodeError'>: 'ascii' codec can't encode characters in position 222-239: ordinal not in range(128)
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_pep277.py", line 195, in test_main
    UnicodeNFKDFileTests,
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1000, in run_unittest
    _run_suite(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 974, in _run_suite
    result = runner.run(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 158, in run
    result.printErrors()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 108, in printErrors
    self.printErrorList('ERROR', self.errors)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 116, in printErrorList
    self.stream.writeln("%s" % err)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 24, in writeln
    self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 222-239: ordinal not in range(128)

----------
messages: 103340
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_pep277 failures
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:36:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:36:38 +0000
Subject: [issue8424] tiger buildbot: test_itimer_virtual failures
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_itimer_virtual (test.test_signal.ItimerTest) ... FAIL

======================================================================
FAIL: test_itimer_prof (test.test_signal.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 391, in test_itimer_prof
    self.fail('timeout waiting for sig_prof signal')
AssertionError: timeout waiting for sig_prof signal

======================================================================
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 372, in test_itimer_virtual
    (signal.getitimer(self.itimer),))
AssertionError: timeout waiting for sig_vtalrm signal; signal.getitimer(self.itimer) gives: (0.29, 0.2)

----------------------------------------------------------------------
Ran 13 tests in 15.302s

----------
messages: 103341
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_itimer_virtual failures
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Fri Apr 16 18:42:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 16:42:21 +0000
Subject: [issue7811] [decimal] ValueError -> TypeError in from_tuple
In-Reply-To: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>
Message-ID: <1271436141.78.0.979142973761.issue7811@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's a bit ambiguous:  the object being supplied to the Decimal constructor does have the right type (tuple), but the wrong contents (i.e., value).  So you could argue either way on this, I guess.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7811>
_______________________________________

From report at bugs.python.org  Fri Apr 16 19:19:42 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 17:19:42 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>


New submission from Eugene Kapun <abacabadabacaba at gmail.com>:

>>> small_set = set(range(2000))
>>> large_set = set(range(20000000))
>>> large_set -= small_set # Fast
>>> small_set -= large_set # Slow, should be fast
>>> small_set = small_set - large_set # Fast

----------
components: Interpreter Core
messages: 103343
nosy: abacabadabacaba
severity: normal
status: open
title: a -= b should be fast if a is a small set and b is a large set
type: resource usage
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Fri Apr 16 19:49:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 17:49:01 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271440141.57.0.188108494514.issue8419@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I don't think this is worth the performance hit or worth the deprecate/remove exercise.  I agree with Guido that we just call this an undefined, implementation specific behavior.

This behavior has existed for a very long time with no ill-effects.  Marking as low priority.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 19:54:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Apr 2010 17:54:26 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271440466.64.0.341791484883.issue8401@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1 on assigning strings to slices of bytearrays. As Ezio mentions, this operation conceptually requires an encoding, and no encoding is readily available in the slice assignment.

-1 on special-casing empty strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:17:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 18:17:23 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271441843.03.0.802740174102.issue8419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I agree with Guido that we just call this an undefined, implementation specific behavior.

Actually I think that was exactly what Guido was *disagreeing* with.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:20:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 16 Apr 2010 18:20:24 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271442024.03.0.527360459662.issue8419@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with Mark. Guido's point was that if it's implementation defined, you'll have portability problems: http://mail.python.org/pipermail/python-dev/2010-April/099435.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:21:51 2010
From: report at bugs.python.org (Alex)
Date: Fri, 16 Apr 2010 18:21:51 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271442111.27.0.222013266461.issue8419@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Guido seems to be favoring disallowing it, not ignoring it[0].

http://mail.python.org/pipermail/python-dev/2010-April/099435.html

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:38:06 2010
From: report at bugs.python.org (Ian Davis)
Date: Fri, 16 Apr 2010 18:38:06 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>


New submission from Ian Davis <ian.w.davis at gmail.com>:

I'm trying to parallelize some scientific computing jobs using multiprocessing.Pool.  I've also tried rolling my own Pool equivalent using Queues.  In trying to return very large result objects from Pool.map()/imap() or via Queue.put(), I've noticed that multiprocessing seems to hang on the receiving end.  On Cygwin 1.7.1/Python 2.5.2 it hangs with no CPU activity.  On Centos 5.2/Python 2.6.2 it hangs with 100% CPU.  cPickle is perfectly capable of pickling these objects, although they may be 100's of MB, so I think it's the communication.  There's also some asymmetry in the error whether it's the parent or child putting the large object.  The put does appear to succeed;  it's the get() on the other end that hangs forever.

Example code:
-----
from multiprocessing import *

def child(task_q, result_q):
    while True:
        print "  Getting task..."
        task = task_q.get()
        print "  Got task", task[:10]
        task = task * 100000000
        print "  Putting result", task[:10]
        result_q.put(task)
        print "  Done putting result", task[:10]
        task_q.task_done()

def parent():
    task_q = JoinableQueue()
    result_q = JoinableQueue()
    worker = Process(target=child, args=(task_q,result_q))
    worker.daemon = True
    worker.start()
    #tasks = ["foo", "bar", "ABC" * 100000000, "baz"]
    tasks = ["foo", "bar", "ABC", "baz"]
    for task in tasks:
        print "Putting task", task[:10], "..."
        task_q.put(task)
        print "Done putting task", task[:10]
    task_q.join()
    for task in tasks:
        print "Getting result..."
        print "Got result", result_q.get()[:10]

if __name__ == '__main__':
    parent()
-----

If run as is, I get
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 242, in _feed
    send(obj)
MemoryError: out of memory
(*** hangs, I hit ^C ***)
Got result
Traceback (most recent call last):
Process Process-1:
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in <module>
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py", line 237, in _bootstrap
    parent()
  File "cygwin_multiprocessing_queue.py", line 29, in parent
    print "Got result", result_q.get()[:10]
    self.run()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py", line 93, in run
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 91, in get
    self._target(*self._args, **self._kwargs)
  File "cygwin_multiprocessing_queue.py", line 6, in child
    res = self._recv()
KeyboardInterrupt
    task = task_q.get()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 91, in get
    res = self._recv()
KeyboardInterrupt


If instead I comment out the multiplication in child() and uncomment the large task in parent(), then I get
  Getting task...
Putting task foo ...
Done putting task foo
Putting task bar ...
  Got task foo
  Putting result foo
Done putting task bar
Putting task ABCABCABCA ...
Done putting task ABCABCABCA
Putting task baz ...
  Done putting result foo
  Getting task...
  Got task bar
  Putting result bar
  Done putting result bar
  Getting task...
Done putting task baz
(*** hangs, I hit ^C ***)
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in <module>
    parent()
  File "cygwin_multiprocessing_queue.py", line 26, in parent
    task_q.join()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 303, in join
    self._cond.wait()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/synchronize.py", line 212, in wait
    self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt

----------
components: Library (Lib)
messages: 103349
nosy: Ian.Davis
severity: normal
status: open
title: multiprocessing.Queue fails to get() very large objects
type: crash
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:58:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Apr 2010 18:58:28 +0000
Subject: [issue8421] tiger buildbot: unable to resolv hostname address
In-Reply-To: <1271435206.59.0.838389424852.issue8421@psf.upfronthosting.co.za>
Message-ID: <1271444308.33.0.280999544045.issue8421@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

David, can you take a look?

----------
nosy: +db3l, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8421>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:59:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Apr 2010 18:59:38 +0000
Subject: [issue8422] tiger buildbot: test_abspath_issue3426 failure
	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1271444378.61.0.989743367219.issue8422@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8422>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:59:44 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 18:59:44 +0000
Subject: [issue7811] [decimal] ValueError -> TypeError in from_tuple
In-Reply-To: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>
Message-ID: <1271444384.86.0.90686471956.issue7811@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

A ValueError seems more appropriate to me.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7811>
_______________________________________

From report at bugs.python.org  Fri Apr 16 20:59:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Apr 2010 18:59:54 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1271444394.11.0.240571785599.issue8423@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Fri Apr 16 21:00:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Apr 2010 19:00:10 +0000
Subject: [issue8424] tiger buildbot: test_itimer_virtual failures
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271444410.05.0.140589035653.issue8424@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Fri Apr 16 21:07:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 19:07:45 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1271444865.09.0.779667945067.issue8425@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Fri Apr 16 21:10:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 19:10:17 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271445017.9.0.405984076307.issue8273@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm writing unittests for a program I'm writing, and would really love to be able to use captured_stdout/stderr.  Of course, I have to support Python 2.5, and can't really justify installing unittest2, so I'll have to roll my own anyway, but I'm definitely +1 for those functions to move into unittest.  A bunch of the others, too, but that's the one I just looked at, and the API looks good to me.  (I'd rename captured_output and leave it be an implementation detail.)

How about 'tools' for the submodule name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Fri Apr 16 21:26:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 19:26:23 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271445983.85.0.675138275383.issue8273@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1 on moving the module into the mainstream without significant reworking and rethinking.  This module is a junk collection (I know because I've contributed some it).

The unittest module is important.  It needs a super clean, well thought out API.  The test_support module doesn't qualify.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Fri Apr 16 21:27:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 19:27:55 +0000
Subject: [issue8273] move generally useful test_support functions into the
	unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271446075.27.0.530841700422.issue8273@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: move test_support into the unittest package -> move generally useful test_support functions into the unittest package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Fri Apr 16 21:32:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Apr 2010 19:32:06 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271446326.5.0.875614654684.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After thinking a bit about it, we're in quasi-feature freeze now for 2.x and it doesn't sound reasonable to add options to unwrap(); we would need to write tests to exercise these options and their behaviour. Also, they aren't strictly needed to fix the issues at hand, but provide a functional benefit.

So I've taken some of Darryl's ideas and fixes and incorporated them. Here is a new patch with them. I've checked compatibility with OpenSSL 1.0.0 and 0.9.8k. If nobody manifests him/herself I will commit it soon.

(note: I dropped the idea of checking for application data with SSL_peek(), since it seems to be a blocking call; at least one of the test_ssl test cases froze here)

----------
Added file: http://bugs.python.org/file16950/newssl6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Apr 16 21:57:28 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 16 Apr 2010 19:57:28 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271447848.37.0.224812118926.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

What your fair.py is doing is demonstrating the superior behaviour of a time-based GIL interrupt to a bytecode based one.  I have no quibbles with that and I agree that it is superior.  But I also think that your example is a very artificial one.  On average the duration of the bytecodes evens out between threads and so they should give a fair first approximation.

But this is not what I was talking about when considering fairness.  Your test only measures each thread end to end, and it demonstrates how a bytecode based gil yilelding system wil let the two threads work in lockstep, even though each loop in one thread is cheaper than the other.  Fair enough.  But fair scheduling between threads doesn't show up here.

To demonstrate fair / unfair, I've modified fair.py to add two more runs, where three threads of the "fast" variety are run for identical number of rounds.  This is when you will se a difference between the linux and the mac based GIL implementations.  For your info, on my windows dual core office box, with regular windows gil:

D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py
Sequential execution
slow: 3.384000 (0 left)
fast: 0.177000 (0 left)
Threaded execution
slow: 3.435000 (0 left)
fast: 3.568000 (0 left)
Treaded, balanced execution:
fast A: 0.973000 (0 left)
fast C: 0.992000 (0 left)
fast B: 1.013000 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 0.977000 (0 left)
fast C: 0.976000 (252 left)
fast B: 0.978000 (17601 left)

And now, same box, with the unfair GIL:

D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py
Sequential execution
slow: 3.338000 (0 left)
fast: 0.177000 (0 left)
Threaded execution
fast: 0.382000 (0 left)
slow: 3.539000 (0 left)
Treaded, balanced execution:
fast A: 0.362000 (0 left)
fast B: 0.464000 (0 left)
fast C: 0.549000 (0 left)
Treaded, balanced execution, with quickstop:
fast B: 0.389000 (0 left)
fast A: 0.447000 (240480 left)
fast C: 0.360000 (613098 left)

The two last cases are the interesting ones.  With unfair scheduling, one thread takes almost twice as long to complete its 1000000 inserts than another.  And if they are all stopped when the quickest one finishes, one thread has more than 600000 iterations to go.

This is what I mean by fair/unfair scheduling.

Cheers,

Kristj?n

p.s.  Yes, I agree that time based GIL yielding is better.  I intentionally didn't want to confuse the matter with that in 2.x.  I wanted to address the other issues that are wrong.

----------
Added file: http://bugs.python.org/file16951/fair.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Fri Apr 16 22:10:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 20:10:07 +0000
Subject: [issue7811] [decimal] ValueError -> TypeError in from_tuple
In-Reply-To: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>
Message-ID: <1271448607.74.0.195209809702.issue7811@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>From both practical and purity points of view I think I prefer TypeError for the cases Stefan gives: if you're passing a float for the sign, then you've somehow ended up with the wrong type for that sign, and that's a TypeError rather than a ValueError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7811>
_______________________________________

From report at bugs.python.org  Fri Apr 16 22:34:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Apr 2010 20:34:52 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1271450092.12.0.108872128763.issue8322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A set_ciphers() method turns out to be highly impractical, since the underlying SSL objects are created lazily when we actually connect the socket.
Therefore, I have instead opted for a new "ciphers" argument to the SSL constructor(s). Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file16952/ciphers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Fri Apr 16 22:39:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Apr 2010 20:39:51 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1271450391.29.0.0267848028545.issue8322@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16952/ciphers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Fri Apr 16 22:40:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Apr 2010 20:40:04 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1271450404.03.0.35559733315.issue8322@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file16953/ciphers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Fri Apr 16 22:50:07 2010
From: report at bugs.python.org (Andrei Paraschivescu)
Date: Fri, 16 Apr 2010 20:50:07 +0000
Subject: [issue8427] toplevel jumps to another location on the screen
In-Reply-To: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za>
Message-ID: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za>


New submission from Andrei Paraschivescu <andreip1 at comcast.net>:

The effect is the window just jumps to another location, matching left corners with another window in the same Python application. Its size doesn't change. 

The effect is somewhat erratic, the best I've been able to create is a situation where it happens 90% of the time. The application contains a number of widget.after calls, and I have not been able to replicate it with a small example.

I am running Mac OS X 10.4.11 and Python 2.6; running from my PC with Windows XP the effect doesn't happen, so it might be a OS X/Tk issue.

----------
components: Tkinter
messages: 103358
nosy: aparasch
severity: normal
status: open
title: toplevel jumps to another location on the screen
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8427>
_______________________________________

From report at bugs.python.org  Fri Apr 16 22:56:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 20:56:52 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Example: http://www.python.org/dev/buildbot/3.x/builders/x86 FreeBSD 7.2 3.x/builds/480/steps/test/logs/stdio

-----------
test_multiprocessing
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 737, in test_notify_all
    self.assertReturnsIfImplemented(6, get_value, woken)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 111, in assertReturnsIfImplemented
    return self.assertEqual(value, res)
AssertionError: 6 != 5

Re-running test test_multiprocessing in verbose mode
test_array (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'
test_getobj_getlock_obj (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'
test_rawarray (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'
test_notify (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_notify_all (test.test_multiprocessing.WithProcessesTestCondition) ... FAIL
test_timeout (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_connection (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_duplex_false (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_sendbytes (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_spawn_close (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_event (test.test_multiprocessing.WithProcessesTestEvent) ... ok
test_finalize (test.test_multiprocessing.WithProcessesTestFinalize) ... ok
test_heap (test.test_multiprocessing.WithProcessesTestHeap) ... ok
test_import (test.test_multiprocessing.WithProcessesTestImportStar) ... ok
test_listener_client (test.test_multiprocessing.WithProcessesTestListenerClient) ... ok
test_lock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_lock_context (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_rlock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_enable_logging (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_level (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart) ... ok
test_apply (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async_timeout (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap_unordered (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_make_pool (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map_chunksize (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_terminate (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_pool_worker_lifetime (test.test_multiprocessing.WithProcessesTestPoolWorkerLifetime) ... 
command timed out: 1800 seconds without output, killing pid 87365
process killed by signal 9
program finished with exit code -1
elapsedTime=6317.267055
-----------

----------
keywords: buildbot
messages: 103359
nosy: haypo
severity: normal
status: open
title: buildbot: test_multiprocessing timeout
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:00:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 21:00:58 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271451658.99.0.0316554761517.issue8419@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Does this mean that every time someone uses **kwds, that the entire dictionary will need to be scanned for invalid keys?  So every API that accepts and passes through **kwds will be slowed on every time it is called.  Is there any offsetting benefit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:03:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 21:03:02 +0000
Subject: [issue7811] [decimal] ValueError -> TypeError in from_tuple
In-Reply-To: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>
Message-ID: <1271451782.52.0.506999380846.issue7811@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I could see a TypeError for the outer tuple a tuple wasn't passed-in.  If the contents aren't what we expect, I believe that calling it a ValueError is the Python way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7811>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:09:26 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 21:09:26 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271452166.16.0.34403181656.issue8419@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

They are already checked for pure python functions.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:35:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Apr 2010 21:35:26 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1271453726.51.0.685445004481.issue8322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch updating docs.

----------
Added file: http://bugs.python.org/file16954/ciphers2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:39:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Apr 2010 21:39:44 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1271453984.72.0.66398922283.issue8322@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:41:49 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 21:41:49 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271454109.26.0.114748871855.issue8419@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here's a patch. It adds a new function, PyArg_ValidateKeywordArguments.

----------
keywords: +patch
Added file: http://bugs.python.org/file16955/no_dict_non_string_keyword_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:45:37 2010
From: report at bugs.python.org (David Bolen)
Date: Fri, 16 Apr 2010 21:45:37 +0000
Subject: [issue8421] tiger buildbot: unable to resolv hostname address
In-Reply-To: <1271435206.59.0.838389424852.issue8421@psf.upfronthosting.co.za>
Message-ID: <1271454337.93.0.440556928859.issue8421@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Looks like some initial configuration glitches - the buildbot needed a little convincing to go to the DNS server for gethostbyname().  Should be working now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8421>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:45:39 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 16 Apr 2010 21:45:39 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1271454339.27.0.731082971534.issue8425@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:48:44 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 21:48:44 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271454524.21.0.1285541209.issue8419@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

And here's a patch for the correct Python version...

----------
Added file: http://bugs.python.org/file16956/no_dict_non_string_kwarg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:53:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 21:53:16 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271454796.32.0.0025004802964.issue8428@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The error occurs on buildbots:
 - i386 Ubuntu 3.x (r80115)
 - x86 FreeBSD 7.2 3.x (r80116, r80075)
 - x86 XP-4 3.x (r80115, r80106)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:56:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 21:56:39 +0000
Subject: [issue8429] buildbot: test_subprocess timeout
In-Reply-To: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>
Message-ID: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_subprocess hungs for 30 min or more.

The bug occurs on buildbots:
 - ARMv7Thumb Ubuntu 3.1 (r80093)
 - ARMv4 Debian 3.x (r80102)
 - ARMv7Thumb Ubuntu 3.x (r80020)
 - alpha Debian 3.x (r80020)
 - x86 FreeBSD 7.2 3.x (r80102)
 - sparc Debian trunk (r80085)

----------
keywords: buildbot
messages: 103368
nosy: haypo
severity: normal
status: open
title: buildbot: test_subprocess timeout
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8429>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:57:14 2010
From: report at bugs.python.org (Paul Boddie)
Date: Fri, 16 Apr 2010 21:57:14 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1271455034.24.0.504038855898.issue762963@psf.upfronthosting.co.za>


Paul Boddie <paul at boddie.org.uk> added the comment:

Well, this still doesn't work for me. I'm running Kubuntu 8.04 (libc6 package version 2.7-10ubuntu5) and reside in the CEST time zone, yet attempting to display the time zone always seems to give "+0000". Here are the failing tests, too:

======================================================================
FAIL: test_tm_gmtoff1 (__main__.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 225, in test_tm_gmtoff1
    time.strftime("%z"), time.strftime("%z", time.localtime()))
AssertionError: '+0200' != '+0000'

======================================================================
FAIL: test_tm_gmtoff2 (__main__.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 238, in test_tm_gmtoff2
    time.strftime("%z", time.localtime()), "+0000")
AssertionError: '+0000' == '+0000'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Fri Apr 16 23:59:02 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 16 Apr 2010 21:59:02 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271455142.75.0.373735125193.issue7332@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It's definitely a stack overflow.
Most of the backtraces show an important number of frames.
The last frame is this:
#0  PyMarshal_ReadLastObjectFromFile (fp=0x13e8200)
    at ../Python/marshal.c:1026
	filesize = <value optimized out>

and a disassembly show us that the segfault is generated on a callq:
0x4bd4d6 <PyMarshal_ReadLastObjectFromFile+54>:	callq  0x4168e8 <fileno at plt>

And if you look at the code, it's obvious what's happening:
PyObject *
PyMarshal_ReadLastObjectFromFile(FILE *fp)
{
/* 75% of 2.1's .pyc files can exploit SMALL_FILE_LIMIT.
 * REASONABLE_FILE_LIMIT is by defn something big enough for Tkinter.pyc.
 */
#define SMALL_FILE_LIMIT (1L << 14)
#define REASONABLE_FILE_LIMIT (1L << 18)
#ifdef HAVE_FSTAT
	off_t filesize;
#endif
#ifdef HAVE_FSTAT
	filesize = getfilesize(fp);
	if (filesize > 0) {
		char buf[SMALL_FILE_LIMIT];
		char* pBuf = NULL;
		if (filesize <= SMALL_FILE_LIMIT)
			pBuf = buf;
		else if (filesize <= REASONABLE_FILE_LIMIT)
			pBuf = (char *)PyMem_MALLOC(filesize);
		if (pBuf != NULL) {
[...]
}

SMALL_FILE_LIMIT is 1 << 14 which is roughly 16K (not that reasonable :-).
So when we enter PyMarshal_ReadLastObjectFromFile and allocate buf, we push around 16K on the stack, which is a lot. That's why we segfault soon after when we call a function (callq), there's no space left on the stack.
So there are several solutions:
- make buf static, but it would increase Python size by almost 16K
- reduce SMALL_FILE_LIMIT, or remove it altogether. I guess SMALL_FILE_LIMIT is there to speedup loading of small files, but I'm not sure that malloc() would incur an important overhead
- reading the whole file to memory sounds weird, we sould probably be using mmap() here

Peers ?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:00:23 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 22:00:23 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271455223.73.0.358922948681.issue8355@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

-1 Even if diff.py is not exaclty a diff replacement, it still makes sense to emulate what's in people's minds. I really don't find having to type 3 more characters a very convincing argument.

----------
nosy: +benjamin.peterson
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:00:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 22:00:43 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271455243.3.0.466503461288.issue8428@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8429.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:00:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 22:00:52 +0000
Subject: [issue8429] buildbot: test_subprocess timeout
In-Reply-To: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>
Message-ID: <1271455252.13.0.523379436936.issue8429@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8428.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8429>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:09:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 22:09:19 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271455759.63.0.0205653261642.issue8428@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

All builds ends with "test_multiprocessing" and then the buildbot kills the proces. Only "x86 FreeBSD 7.2 3.x" last build (480, not the others) show us that test_pool_worker_lifetime (test.test_multiprocessing.WithProcessesTestPoolWorkerLifetime) hung.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:12:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 22:12:21 +0000
Subject: [issue8429] buildbot: test_subprocess timeout
In-Reply-To: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>
Message-ID: <1271455941.3.0.79586488611.issue8429@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

All builds ends with "test_subprocess" and then the process is killed. There is no usefull information :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8429>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:15:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 22:15:38 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271456138.95.0.0141187047224.issue8419@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Now with the suggested dictionary speed hack.

----------
Added file: http://bugs.python.org/file16957/with_speed_hack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:36:43 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Apr 2010 22:36:43 +0000
Subject: [issue8417] bytes and bytearray constructors raise TypeError for very
	large ints
In-Reply-To: <1271403836.14.0.808706592166.issue8417@psf.upfronthosting.co.za>
Message-ID: <1271457403.41.0.216973460304.issue8417@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80126. Thanks for the report!

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8417>
_______________________________________

From report at bugs.python.org  Sat Apr 17 00:41:36 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Apr 2010 22:41:36 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271457696.64.0.515485835455.issue8355@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with Benjamin.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Sat Apr 17 01:05:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Apr 2010 23:05:57 +0000
Subject: [issue8421] tiger buildbot: unable to resolv hostname address
In-Reply-To: <1271435206.59.0.838389424852.issue8421@psf.upfronthosting.co.za>
Message-ID: <1271459157.79.0.835893083043.issue8421@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, David.  test_socket passed on the latest trunk run on the tiger buildbot.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8421>
_______________________________________

From report at bugs.python.org  Sat Apr 17 01:57:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 23:57:16 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271462236.91.0.742437452621.issue8393@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited in py3k (r80135), blocked in 3.1 (r80136).

Python 3.1 has no _posixsubprocess module, it uses os.chdir() which accepts bytes, bytearray and str with surrogates.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Sat Apr 17 02:17:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 00:17:50 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1271463470.68.0.888972190476.issue8362@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I read the maintainers list. I don't like empty lines. If a module has no maintainer, it should not be listed in this file. Since Python3 module names are different, if we copy the list to Python2, maintaining this list between Python2 and Python3 will be more difficult. Yes, some modules have no dedicated maitainer, but it doesn't mean that the module is dead. And I see a list without maintainer as a dead module.

Interest Area: algorithms has no maintainer... why is algorithms listed in maintainer list? Does it mean that people not listed in this line are not interested by algorithms?

Even if it's more difficult to maintain two versions of this file (Python2 and Python3), I would like to see it in Python2 (so I'm +1 for this issue).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Sat Apr 17 02:35:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 00:35:55 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1271464555.03.0.413694319169.issue7606@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If anyone would like to work on non-ASCII HTTP header, please open a new issue with a pointer to this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Sat Apr 17 03:23:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 01:23:16 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1271467396.03.0.744610439795.issue8362@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Any module without a listed maintainer is maintained by the community as a whole (as it says in the introduction).  The fact that a module does not have a listed maintainer does not mean it is dead, and I don't think anyone(except you? :) thinks that.  All modules are listed for completeness, and so that it is obvious which modules it would be most helpful if someone with an interest put themselves down as expert for (as Giampaolo has just done for ftplib).

Algorithms was listed as an interested area as a result of a brainstorming session for interest areas.  I think we had Raymond in mind :).  If no one has chosen to be listed, that line should probably be deleted.

I think perhaps the name chosen for the file was unfortunate.  I view it more as the 'experts' file, rather than the maintainers file, though in some cases the expert is indeed the principle maintainer of the module (such as Vinay for logging).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Sat Apr 17 05:18:11 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 17 Apr 2010 03:18:11 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271474291.1.0.921601209556.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I'm not trying to be a pain here, but do you have any explanation as to why, with fair scheduling, the observed execution time of multiple CPU-bound threads is substantially worse than with unfair scheduling?

>From your own benchmarks, consider this result (Fair scheduling)

Treaded, balanced execution:
fast A: 0.973000 (0 left)
fast C: 0.992000 (0 left)
fast B: 1.013000 (0 left)

Versus this result with unfair scheduling:

Treaded, balanced execution:
fast A: 0.362000 (0 left)
fast B: 0.464000 (0 left)
fast C: 0.549000 (0 left)

If I'm reading this right, it takes the three threads with fair locking almost twice as long to complete (1.01s) as the three threads with unfair locking (0.55s) .  If so, why would I want fair locking?   Wouldn't I want the solution that offers the fastest overall execution time?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sat Apr 17 05:22:21 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 17 Apr 2010 03:22:21 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271474541.12.0.892212107471.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

One other comment.  Running the modified fair.py file on my Linux system using Python compiled with semaphores shows they they are *definitely* not fair.  Here's the relevant part of your test:

Treaded, balanced execution, with quickstop:
fast C: 1.580815 (0 left)
fast B: 1.636923 (158919 left)
fast A: 1.788634 (310323 left)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sat Apr 17 06:12:54 2010
From: report at bugs.python.org (Alf P. Steinbach)
Date: Sat, 17 Apr 2010 04:12:54 +0000
Subject: [issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on
	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1271477574.02.0.825689264234.issue8418@psf.upfronthosting.co.za>


Alf P. Steinbach <alfps at start.no> added the comment:

Thanks for explaining that.

However, the first bug I ever reported was #7681, "Use floor division in appropiate places in the wave module.", fixed in 3.1.2.

And the tracker search does not find this bug by id.

Nor does it find it by specifying "wave" as text to search for, or by specifying me as reporting.

The apparent disappearance of #7681 may be a bug in the tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8418>
_______________________________________

From report at bugs.python.org  Sat Apr 17 06:45:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Apr 2010 04:45:11 +0000
Subject: [issue8273] move generally useful test_support functions into the
	unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271479511.45.0.885484466452.issue8273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Not the module as it is, but just some of the APIs that it provides, possibly after a cleanup to remove things specific to our test suite and to make them more general and forward-compatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Sat Apr 17 06:52:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Apr 2010 04:52:01 +0000
Subject: [issue8273] move generally useful test_support functions into the
	unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271479921.1.0.702853394968.issue8273@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If anything gets moved, it needs to be part of a very well thought-out plan with the same high threshold for approval that it would have had if it weren't in test_support.

The unittest module already brims with complexity and would suffer quite a bit if a hodge-podge of functions were added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Sat Apr 17 07:27:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 05:27:22 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1271482042.76.0.218380687578.issue3864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The FreeBSD bot in question is now running 6.4, and test_signal is still failing.  I have access to a 6.3 box, which shows exactly the same failures as I see in the buildbot log.  On that box, doing

    t = threading.Thread(target=lambda: None)
    t.start()

with or without a t.join() afterward is enough to trigger the failures in test_signal.

Although it does not appear to have been fixed in 6.4, the 7.2 buildbot does not show the same problems.  (It has a somewhat different problem with *one* of the three failing tests in this case, but likely it is a different bug from this one, since the output is different.)  So I conclude that it is still most likely a platform problem, and I've added freebsd6 specific skips for those three tests in r80144.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Sat Apr 17 07:37:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 05:37:29 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1271482649.85.0.662349922762.issue8263@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can reliably reproduce the SIGINT problem on a FreeBSD 6.3 box, if (and so far only if) some test that uses threading is run first (see also issue 3864).  So I suspect this is a freebsd6 specific problem and just needs a skip added.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Sat Apr 17 07:50:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 05:50:40 +0000
Subject: [issue8424] tiger/FreeBSD7.2 buildbots: test_itimer_virtual failures
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271483440.16.0.424001439893.issue8424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The FreeBSD 7.2 buildbot also shows this failure.  See also issue 3864; although this failure appears to be slightly different, it might be due to a remnant of the same platform bug.  I'm making everyone from that bug nosy on this one.

----------
components: +Tests
nosy: +aimacintyre, eric.smith, gpolo, mark.dickinson, r.david.murray
priority:  -> normal
stage:  -> needs patch
title: tiger buildbot: test_itimer_virtual failures -> tiger/FreeBSD7.2 buildbots: test_itimer_virtual failures
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Sat Apr 17 08:01:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 06:01:29 +0000
Subject: [issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on
	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1271484089.12.0.00961185749826.issue8418@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That's because 7681 is closed.  (That said, I consider it a bug in the tracker that it defaults to searching only open issues...and I think I filed an issue in the metatracker for that, too.  Maybe I'll get around to fixing it if I can get agreement that fixing it is a good idea).  If you put the number in the 'show issue' box it will show up.  You'll also note that it is now a clickable link in your message in the tracker.

But we really should move this discussion to tracker-discuss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8418>
_______________________________________

From report at bugs.python.org  Sat Apr 17 10:45:10 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 17 Apr 2010 08:45:10 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271493910.29.0.180006199119.issue7332@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 11:37:24 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Apr 2010 09:37:24 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271497044.68.0.976644655751.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

One oddity: In Mark's test case, the error only shows if readline
is imported _before_ curses. The other way around it's fine.


On FreeBSD 8.0 amd64, with the _default_ libcurses, the Valgrind output
for py3k looks like this:

[...]
==31089== Invalid write of size 8
==31089==    at 0x284F1AE: getwin (in /lib/libncursesw.so.8)
==31089==    by 0x2AE8532: PyCurses_GetWin (_cursesmodule.c:1903)
==31089==    by 0x47FBC7: call_function (ceval.c:3833)
==31089==    by 0x47AAC0: PyEval_EvalFrameEx (ceval.c:2645)
==31089==    by 0x47DF41: PyEval_EvalCodeEx (ceval.c:3282)
==31089==    by 0x47189F: PyEval_EvalCode (ceval.c:721)
==31089==    by 0x4B31AA: run_mod (pythonrun.c:1692)
==31089==    by 0x4B2FC3: PyRun_FileExFlags (pythonrun.c:1649)
==31089==    by 0x4B1734: PyRun_SimpleFileExFlags (pythonrun.c:1177)
==31089==    by 0x4B0C75: PyRun_AnyFileExFlags (pythonrun.c:963)
==31089==    by 0x4CB029: Py_Main (main.c:650)
==31089==    by 0x4150E4: main (python.c:152)
==31089==  Address 0x25c71e0 is 0 bytes after a block of size 112 alloc'd
==31089==    at 0x25A8AE: calloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==31089==    by 0x29C518A: _nc_makenew (in /lib/libncurses.so.8)
==31089==    by 0x29C569F: newwin (in /lib/libncurses.so.8)
==31089==    by 0x284F2EE: getwin (in /lib/libncursesw.so.8)
==31089==    by 0x2AE8532: PyCurses_GetWin (_cursesmodule.c:1903)
==31089==    by 0x47FBC7: call_function (ceval.c:3833)
==31089==    by 0x47AAC0: PyEval_EvalFrameEx (ceval.c:2645)
==31089==    by 0x47DF41: PyEval_EvalCodeEx (ceval.c:3282)
==31089==    by 0x47189F: PyEval_EvalCode (ceval.c:721)
==31089==    by 0x4B31AA: run_mod (pythonrun.c:1692)
==31089==    by 0x4B2FC3: PyRun_FileExFlags (pythonrun.c:1649)
==31089==    by 0x4B1734: PyRun_SimpleFileExFlags (pythonrun.c:1177)
==31089==
[...]


Then I installed the curses from /usr/ports/devel/ncurses, and the
error didn't show up any more. I'm inclined to think that the bug is
in the system ncurses. Still, it would be nice to know why the import
order matters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 17 11:45:37 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Apr 2010 09:45:37 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271497537.45.0.841060009084.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I take that back. With the curses from /usr/ports/devel/ncurses,
Mark's test case is fine, but

  ./python Lib/test/regrtest.py -uall  test_curses

fails again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 17 12:31:10 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Apr 2010 10:31:10 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271500270.93.0.704662484069.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Alas, after installing curses from /usr/ports/devel/ncurses I did not
recompile Modules/_curses_panel.c.

So, after a proper build

  ./python Lib/test/regrtest.py -uall  test_curses

shows no errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 17 12:53:16 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 17 Apr 2010 10:53:16 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271501596.32.0.47591511012.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

>I'm not trying to be a pain here, but do you have any explanation as to >why, with fair scheduling, the observed execution time of multiple CPU->bound threads is substantially worse than with unfair scheduling?
Yes.  This is because the GIL yield now actually succeeds most of the time, every 100 opcodes (the default).  Profiling indicates that on multicore machines this causes significant instruction cache misses as the new thread is scheduled on the other core.   Try raising the sys.checkinterval to 1000 and watch the performance difference fall away.

>If so, why would I want fair locking?   Wouldn't I want the solution >that offers the fastest overall execution time?
Because of IO latency.  Your IO thread, waiting to wake up when somethin happen also has to compete unfairly with the CPU threads.

"a fair" lock allows you to balance the cost of switching (on multicore) vs thread latency using sys.checkinterval (if we are based on opcodes).  The unfair lock all but disables this control.

>One other comment.  Running the modified fair.py file on my Linux >system using Python compiled with semaphores shows they they are >*definitely* not fair.  Here's the relevant part of your test:
Interesting.  let me stress that I am using windows and making assumptions about how something like sem_wait() behaves.  And the posix standard does not require "fair" behaviour of the semaphore functions according to http://www.opengroup.org/onlinepubs/009695399/functions/sem_wait.html.

The kernel-based windows synchronization functions achieve an amount of "fairness" through WaitForSingleObject() and friends:
http://msdn.microsoft.com/en-us/magazine/cc163642.aspx#S2

Are you absolutely sure that USE_SEMAPHORES is defined?  There could be a latent config problem somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sat Apr 17 13:16:54 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 17 Apr 2010 11:16:54 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271503014.38.0.627371429888.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I'm definitely sure that semaphores were being used in my test---I stuck a print statement inside the code that creates locks just to make sure it was using the semaphore version :-).

Unfortunately, at this point I think most of this discussion is academic since no change is likely to be incorporated into Python 2.7.  I can definitely see where fairness might help I/O performance if there is only 1 CPU bound thread.  I just don't know for other situations.  For example, if you have a server where it's all I/O-bound threads, but it suddenly comes under extreme load (e.g., slashdot effect), does a fair GIL help or hurt with that?  I just don't know.

In the big picture, all of the issues raised here should be on the minds of people fixing the GIL in py3k though.   It's just one more aspect of why fixing the GIL is hard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sat Apr 17 13:58:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 11:58:49 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271505529.32.0.50393315963.issue8428@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Same issue on "sparc solaris10 gcc 3.x":
http://www.python.org/dev/buildbot/builders/sparc solaris10 gcc 3.x/builds/639/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Sat Apr 17 14:21:49 2010
From: report at bugs.python.org (David Beazley)
Date: Sat, 17 Apr 2010 12:21:49 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271506909.45.0.957146771354.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

As a followup, since I'm not sure anyone actually here actually tried a fair GIL on Linux, I incorporated your suggested fairness patch to the condition-variable version of the GIL (using this pseudocode you wrote as a guide):

with gil.cond:
  if gil.n_waiting or gil.locked:
    gil.n_waiting += 1
    while True:
      gil.cond.wait() #always wait at least once
      if not gil.locked:
        break
    gil.n_waiting -= 1
  gil.locked = True

I did some tests on this and it does appear to exhibit fairness. Here are the results of running the 'fair.py' test with a fair GIL on my Linux system:

[ Fair GIL Linux ]
Sequential execution
slow: 6.246764 (0 left)
fast: 0.465102 (0 left)
Threaded execution
slow: 7.534725 (0 left)
fast: 7.674448 (0 left)
Treaded, balanced execution:
fast A: 10.415756 (0 left)
fast B: 10.456502 (0 left)
fast C: 10.520457 (0 left)
Treaded, balanced execution, with quickstop:
fast B: 8.423304 (0 left)
fast A: 8.409794 (16016 left)
fast C: 8.381977 (9162 left)
beazley at ubuntu:~/Desktop/Python-2.6.4$ 

If I switch back to the unfair GIL, this is the result:

[ Unfair GIL, original implementation, Linux]
Sequential execution
slow: 6.164739 (0 left)
fast: 0.422626 (0 left)
Threaded execution
slow: 6.570084 (0 left)
fast: 6.690927 (0 left)
Treaded, balanced execution:
fast A: 1.994143 (0 left)
fast C: 2.014925 (0 left)
fast B: 2.073212 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 1.614533 (0 left)
fast C: 1.607324 (377323 left)
fast B: 1.625987 (111451 left)

Probably the main thing to notice is the huge increase in performance over the fair GIL.  For instance, the balance execution test runs about 5 times faster.

Here are the two tests repeated with checkinterval = 1000.

[ Fair GIL, checkinterval = 1000]
Sequential execution
slow: 6.175320 (0 left)
fast: 0.424410 (0 left)
Threaded execution
slow: 6.505094 (0 left)
fast: 6.746649 (0 left)
Treaded, balanced execution:
fast A: 2.243123 (0 left)
fast B: 2.416043 (0 left)
fast C: 2.442475 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 1.565914 (0 left)
fast C: 1.514024 (81254 left)
fast B: 1.531937 (63740 left)

[ Unfair GIL, checkinterval = 1000]

Sequential execution
slow: 6.258882 (0 left)
fast: 0.411590 (0 left)
Threaded execution
slow: 6.255027 (0 left)
fast: 0.409412 (0 left)
Treaded, balanced execution:
fast A: 1.291007 (0 left)
fast C: 1.135373 (0 left)
fast B: 1.437205 (0 left)
Treaded, balanced execution, with quickstop:
fast C: 1.331775 (0 left)
fast A: 1.418670 (54841 left)
fast B: 1.403853 (208732 left)

Here, the unfair GIL is still quite a bit faster on raw performance.  I tried kicking the check interval up to 10000 and the unfair GIL still won by a pretty significant margin on raw speed of completing the different tasks.

I've attached a copy of the thread_pthread.h file I modified for this test.  It's from Python-2.6.4.

----------
Added file: http://bugs.python.org/file16958/thread_pthread.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sat Apr 17 15:39:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 13:39:53 +0000
Subject: [issue8430] test_site failure with non-ASCII directory
In-Reply-To: <1271511593.69.0.166956245853.issue8430@psf.upfronthosting.co.za>
Message-ID: <1271511593.69.0.166956245853.issue8430@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

r80137 (PEP 3147) introduced a test in test_site. The test fails on non-ASCII directory because stdout uses ASCII whereas the directories contains non-ASCII characters.

http://www.python.org/dev/buildbot/builders/AMD64 Ubuntu wide 3.x/builds/848

Attached patch is a workaround to this issue. The path is encoded to ASCII using backslashreplace error handler. But the patch is not perfect, it should use the reverse operation to get the path as an unicode string. But I don't know how to implement the reverse operation of .encode("ascii", "backslashreplace").

----------
files: test_site.patch
keywords: buildbot, patch
messages: 103400
nosy: haypo
severity: normal
status: open
title: test_site failure with non-ASCII directory
versions: Python 3.2
Added file: http://bugs.python.org/file16959/test_site.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8430>
_______________________________________

From report at bugs.python.org  Sat Apr 17 15:51:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 13:51:04 +0000
Subject: [issue8431] buildbot: test_tokenize and test_io hung on ARMv4 Debian
	3.x
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_tokenize and test_io does sometimes hung on buildbot ARMv4 Debian 3.x. It looks to be related to #8429.

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 3.x/builds/52/steps/test/logs/stdio
---------
...
test_tokenize

command timed out: 1800 seconds without output, killing pid 10998
process killed by signal 9
program finished with exit code -1
elapsedTime=12155.584910
---------

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 3.x/builds/50/steps/test/logs/stdio
----------
...
test_io

command timed out: 1800 seconds without output, killing pid 18097
process killed by signal 9
program finished with exit code -1
elapsedTime=3859.149082
----------

----------
keywords: buildbot
messages: 103401
nosy: haypo
severity: normal
status: open
title: buildbot: test_tokenize and test_io hung on ARMv4 Debian 3.x
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sat Apr 17 16:15:44 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sat, 17 Apr 2010 14:15:44 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271513744.93.0.408930952335.issue8401@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

-1 on special-casing string without an encoding. Current code does (almost) this:
...
if argument_is_a_string:
	if not encoding_is_given: # Special case
		raise TypeError("string argument without an encoding")
	encode_argument()
	return
if encoding_is_given:
	raise TypeError("encoding or errors without a string argument")
...
IMO, it should do this instead:
...
if encoding_is_given:
	if not argument_is_a_string:
		raise TypeError("encoding or errors without a string argument")
	encode_argument()
	return
...
This way, bytearray("") would work without any special cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Sat Apr 17 16:25:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 14:25:50 +0000
Subject: [issue8429] buildbot: test_subprocess timeout
In-Reply-To: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>
Message-ID: <1271514350.87.0.511986943015.issue8429@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8429>
_______________________________________

From report at bugs.python.org  Sat Apr 17 16:26:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 14:26:31 +0000
Subject: [issue8431] buildbot: test_tokenize and test_io hung on ARMv4 Debian
	3.x
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271514391.97.0.392810280804.issue8431@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know about test_tokenize, but test_io is quite heavy and a couple of individual tests launch many threads. On a slow CPU with little RAM, the test could simply be still running (swapping?) after 1800s...

----------
nosy: +doko, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sat Apr 17 16:28:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 14:28:51 +0000
Subject: [issue8430] test_site failure with non-ASCII directory
In-Reply-To: <1271511593.69.0.166956245853.issue8430@psf.upfronthosting.co.za>
Message-ID: <1271514531.98.0.10024321081.issue8430@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8430>
_______________________________________

From report at bugs.python.org  Sat Apr 17 16:47:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 17 Apr 2010 14:47:59 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1271515679.4.0.164644292419.issue5650@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 80146 and merged into other branches
release26-maint: r80147
py3k: r80148
release31-maint: r80149

----------
assignee: georg.brandl -> orsenthil
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Sat Apr 17 16:50:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 14:50:24 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271515824.24.0.888143476081.issue7332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree that we can consider dropping the static buffer and always using PyMem_MALLOC().
It looks a bit strange for this bug to happen, though. Does Ubuntu use a small stack size?

----------
nosy: +pitrou, tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 17:25:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 15:25:46 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271517946.3.0.752447275653.issue7332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, and the record of the original patch conversation (when this optimization was added) can be found here:
http://mail.python.org/pipermail/patches/2001-January/003500.html

----------
priority: normal -> high
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 17:44:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 15:44:04 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271519044.25.0.512883819661.issue7332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A small benchmark shows no difference in startup time when disabling the stack buffer. (this is on Linux: of course, the problem might be that the glibc is heavily optimized)

The benchmark was a simple:
$ time ./python -E -c "import logging, pydoc, xmlrpclib, urllib, urllib2, unittest, doctest, profile, smtplib, httplib, fractions, decimal, codecs, difflib, argparse, distutils, email, imaplib, idlelib, json, _pyio, poplib, ftplib"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 17:57:54 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 17 Apr 2010 15:57:54 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271519874.28.0.49770726088.issue7332@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 18:35:30 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 17 Apr 2010 16:35:30 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271522130.61.0.0301094443447.issue7332@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> It looks a bit strange for this bug to happen, though. Does Ubuntu use a small stack size?

There are other possible reasons:
- the programs that crash (or the libraries they're using) use the stack a lot
- somehow, pthread_attr_setstacksize is called and set to a reduced thread stack size
- notice that this is reported on x86_64 architectures, and stack usage is increased on 64 bits

Since I don't have an Ubuntu box, it would be nice if one of the reporters could:
- return the result of "ulimit -s" on their box
- call "ulimit -s unlimited", and see if the bug goes away
- check that the attached patch marshal_stack.diff solves this
- return the result of "ltrace -e pthread_attr_setstacksize <command used to start program>"

> A small benchmark shows no difference in startup time when disabling the stack buffer. (this is on Linux: of course, the problem might be that the glibc is heavily optimized)

Yeap, there as some crappy systems out there (no name :-), that's why it would be nice to have some feedback and small benchmarks on various platforms. Anyway, even if compiled files are small most of the time, I'm not sure that this "let's copy the file to the stack/heap" approcah is optimal, and maybe mmap would be worth considering if we find that the overhead is not negligible (I haven't looked at the code in detail, so maybe it's not possible to use in this case).

----------
keywords: +patch
Added file: http://bugs.python.org/file16960/marshal_stack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 18:36:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 16:36:35 +0000
Subject: [issue8432] build: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86 FreeBSD 3.x/builds/211/steps/test/logs/stdio

Example:
======================================================================
FAIL: test_send_signal (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_subprocess.py", line 770, in test_send_signal
    self.assertIn(b'KeyboardInterrupt', stderr)
AssertionError: b'KeyboardInterrupt' not found in b''

----------------------------------------------------------------------

----------
keywords: buildbot
messages: 103409
nosy: haypo
severity: normal
status: open
title: build: test_send_signal of test_subprocess failure
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8432>
_______________________________________

From report at bugs.python.org  Sat Apr 17 18:47:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 16:47:47 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271522867.45.0.815826060029.issue2987@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I posted this to the checkins list, but for reference, the following invalid URL should be added to the test cases:

    http://[::1/foo/bar]/bad

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sat Apr 17 19:26:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 17:26:24 +0000
Subject: [issue8433] buildbot: test_curses failure
In-Reply-To: <1271525184.22.0.100709248737.issue8433@psf.upfronthosting.co.za>
Message-ID: <1271525184.22.0.100709248737.issue8433@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/sparc Debian 3.x/builds/62/steps/test/logs/stdio

test_curses
[?1049h(B[?7h[?5h[?5l[?12l[?25habc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- <class '_curses.error'>: getmouse() returned ERR

Re-running test test_curses in verbose mode
[?1049h[?12l[?25h(B[?7h[?1000h[?5h[?5labc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- <class '_curses.error'>: getmouse() returned ERR
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 291, in test_main
    main(stdscr)
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 275, in main
    module_funcs(stdscr)
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 228, in module_funcs
    m = curses.getmouse()
_curses.error: getmouse() returned ERR

----------
keywords: buildbot
messages: 103411
nosy: haypo
severity: normal
status: open
title: buildbot: test_curses failure
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8433>
_______________________________________

From report at bugs.python.org  Sat Apr 17 19:27:53 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 17 Apr 2010 17:27:53 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271525273.22.0.714797259526.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

If everyone agrees on "error: [Errno 0] Error" being a legitimate alias for a "connection closed event" condition then I'd say the test server looks good, even if I think that expecting a ssl.SSLError derived exception would have made more sense, but I understand this is a OpenSSL inherited behavior.

Anyway, I'd like to improve the SSL test server in future as I'm sure it hides some other problems but I can do that once pyftpdlib's SSL server code is more mature and after 2.7 is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sat Apr 17 19:27:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 17:27:57 +0000
Subject: [issue8433] buildbot: test_curses failure, getmouse() returned ERR
In-Reply-To: <1271525184.22.0.100709248737.issue8433@psf.upfronthosting.co.za>
Message-ID: <1271525277.84.0.74126722596.issue8433@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: buildbot: test_curses failure -> buildbot: test_curses failure, getmouse() returned ERR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8433>
_______________________________________

From report at bugs.python.org  Sat Apr 17 19:41:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 17:41:15 +0000
Subject: [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1271526075.95.0.180086446218.issue8322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r80151 (trunk), r80154 (py3k).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8322>
_______________________________________

From report at bugs.python.org  Sat Apr 17 19:47:51 2010
From: report at bugs.python.org (Nir Aides)
Date: Sat, 17 Apr 2010 17:47:51 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271526471.2.0.982888737553.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> the scheduling function bfs_find_task returns the first task that 
> has an expired deadline. since an expired deadline probably means 
> that the scheduler hasn't run for a while, it might be worth it to 
> look for the thread with the oldest deadline and serve it first, 
> instead of stopping at the first one

This is by design of BFS as I understand it. Next thread to run is either first expired or oldest deadline:

http://ck.kolivas.org/patches/bfs/sched-BFS.txt
"Once a task is descheduled, it is put back on the queue, and an
O(n) lookup of all queued-but-not-running tasks is done to determine which has
the earliest deadline and that task is chosen to receive CPU next. The one
caveat to this is that if a deadline has already passed (jiffies is greater
than the deadline), the tasks are chosen in FIFO (first in first out) order as
the deadlines are old and their absolute value becomes decreasingly relevant
apart from being a flag that they have been asleep and deserve CPU time ahead
of all later deadlines."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sat Apr 17 19:50:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 17:50:40 +0000
Subject: [issue8433] buildbot: test_curses failure, getmouse() returned ERR
In-Reply-To: <1271525184.22.0.100709248737.issue8433@psf.upfronthosting.co.za>
Message-ID: <1271526640.56.0.741409555855.issue8433@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Other example: http://www.python.org/dev/buildbot/builders/alpha Debian 3.x/builds/63/steps/test/logs/stdio

test_curses
[?1049h(B[?7h[?5h[?5l[?12l[?25habc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- <class '_curses.error'>: getmouse() returned ERR
Re-running test test_curses in verbose mode
[?1049h[?12l[?25h(B[?7h[?1000h[?5h[?5labc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- <class '_curses.error'>: getmouse() returned ERR
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 291, in test_main
    main(stdscr)
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 275, in main
    module_funcs(stdscr)
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 228, in module_funcs
    m = curses.getmouse()
_curses.error: getmouse() returned ERR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8433>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:08:03 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 17 Apr 2010 18:08:03 +0000
Subject: [issue8371] Add a command to download distributions
In-Reply-To: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za>
Message-ID: <1271527683.2.0.929728416555.issue8371@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

There is a ready-to-use public domain code with a progress bar if you'll need it.
http://pypi.python.org/pypi/wget/

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8371>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:11:25 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 17 Apr 2010 18:11:25 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271527885.36.0.938870938396.issue7332@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Ok, I've done too some trivial benchmarking on my Linux box, and I get this:
right now:
$ time ./python /tmp/test_import.py
real    0m1.258s
user    0m1.111s
sys     0m0.101s

with mmap:
$ time ./python /tmp/test_import.py
real    0m1.262s
user    0m1.170s
sys     0m0.090s

with malloc only:
$ time ./python /tmp/test_import.py
real    0m1.213s
user    0m1.111s
sys     0m0.099s

The test script just imports every module available.
So I'd agree with Antoine, and think we should just use malloc. The attached patch marshal_stack.diff just does that.

----------
Added file: http://bugs.python.org/file16961/marshal_stack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:11:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 18:11:28 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271527888.73.0.806568088456.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If everyone agrees on "error: [Errno 0] Error" being a legitimate alias 
> for a "connection closed event" condition then I'd say the test server 
> looks good, even if I think that expecting a ssl.SSLError derived
> exception would have made more sense, but I understand this is a
> OpenSSL inherited behavior.

Well, it's quite an unfortunate error display, so perhaps we could detect it and turn into something more meaningful instead.
However, I think it should remain a socket error or an OS error, because it's really the underlying socket which is closed, not the SSL wrapper.

> Anyway, I'd like to improve the SSL test server in future as I'm sure > it hides some other problems but I can do that once pyftpdlib's SSL
> server code is more mature and after 2.7 is released.

Shouldn't it become part of asyncore at some point? It's both useful (well, for people using asyncore anyway :-)) and non-trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:11:37 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 17 Apr 2010 18:11:37 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271527897.33.0.474867194979.issue7332@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file16960/marshal_stack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:14:04 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 17 Apr 2010 18:14:04 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271528044.56.0.534898419244.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Moving the Bad URL check to a higher level can be detect the bad urls much better. Once I the netloc is parsed and obtained, invalid URL can be checked. I am attaching an update with the new test included.
If you have any comments, please let me know.

----------
Added file: http://bugs.python.org/file16962/issue2987-bad_url_checks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:20:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 18:20:45 +0000
Subject: [issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk
In-Reply-To: <1271528445.34.0.175485251427.issue8434@psf.upfronthosting.co.za>
Message-ID: <1271528445.34.0.175485251427.issue8434@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/sparc Ubuntu trunk/builds/76/steps/test/logs/stdio

test_gdb
test test_gdb failed -- multiple errors occurred; run in verbose mode for details
Re-running test 'test_gdb' in verbose mode
test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled ... ok
test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully ... ok
test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully ... ok
test_builtin_function (test.test_gdb.PrettyPrintTests) ... ok
test_builtin_method (test.test_gdb.PrettyPrintTests) ... ok
test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled ... ok
test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances ... ok
test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... ok
test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled ... ok
test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled ... ok
test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries ... ok
test_exceptions (test.test_gdb.PrettyPrintTests) ... ok
test_frames (test.test_gdb.PrettyPrintTests) ... ok
test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets ... ok
test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... ok
test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values ... ok
test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists ... ok
test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values ... ok
test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances ... ok
test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval ... ok
test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval ... ok
test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... ok
test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... ok
test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets ... ok
test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None ... ok
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings ... ok
test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass ... ok
test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass ... ok
test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated ... ok
test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples ... ok
test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values ... ok
test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works ... FAIL
test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument ... FAIL
test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments ... FAIL
test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack ... FAIL
test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works ... FAIL
test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack ... FAIL
test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down" ... FAIL
test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works ... FAIL
test_basic_command (test.test_gdb.PyPrintTests)
Verify that the "py-print" command works ... FAIL
test_print_after_up (test.test_gdb.PyPrintTests) ... FAIL
test_printing_builtin (test.test_gdb.PyPrintTests) ... FAIL
test_printing_global (test.test_gdb.PyPrintTests) ... FAIL
test_basic_command (test.test_gdb.PyLocalsTests) ... FAIL
test_locals_after_up (test.test_gdb.PyLocalsTests) ... FAIL

======================================================================
FAIL: test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 535, in test_basic_command
    cmds_after_breakpoint=['py-list'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 552, in test_one_abs_arg
    cmds_after_breakpoint=['py-list 9'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 565, in test_two_abs_args
    cmds_after_breakpoint=['py-list 1,3'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 588, in test_down_at_bottom
    cmds_after_breakpoint=['py-down'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 578, in test_pyup_command
    cmds_after_breakpoint=['py-up'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 595, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down"
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 602, in test_up_then_down
    cmds_after_breakpoint=['py-up', 'py-down'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 615, in test_basic_command
    cmds_after_breakpoint=['py-bt'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_basic_command (test.test_gdb.PyPrintTests)
Verify that the "py-print" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 630, in test_basic_command
    cmds_after_breakpoint=['py-print args'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_print_after_up (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 636, in test_print_after_up
    cmds_after_breakpoint=['py-up', 'py-print c', 'py-print b', 'py-print a'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_printing_builtin (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 648, in test_printing_builtin
    cmds_after_breakpoint=['py-print len'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_printing_global (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 642, in test_printing_global
    cmds_after_breakpoint=['py-print __name__'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_basic_command (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 655, in test_basic_command
    cmds_after_breakpoint=['py-locals'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_locals_after_up (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 661, in test_locals_after_up
    cmds_after_breakpoint=['py-up', 'py-locals'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

----------------------------------------------------------------------
Ran 45 tests in 72.756s

FAILED (failures=14)
test test_gdb failed -- multiple errors occurred

----------
keywords: buildbot
messages: 103420
nosy: haypo
severity: normal
status: open
title: buildbot: test_gdb failure on sparc Ubuntu trunk
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8434>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:21:50 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 17 Apr 2010 18:21:50 +0000
Subject: [issue8384] Distutils C extension build with MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271528510.19.0.651468946689.issue8384@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

To me a better option would be an ability to specify a path to compiler from command line.

--compiler-path=./mingw/bin/gcc.exe

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:23:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 18:23:04 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271528584.42.0.00851993997775.issue8431@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There are other hung on trunk (output of bbreport):

ARMv4 Debian trunk         80129, 80120, 80101, 80098, 80085,      
 80129: # hung for 30 min: test_ast                                
 80120: # hung for 30 min: test_descr                              
 80101: # hung for 30 min: test_parser                             
 80098: # hung for 30 min: test_decorators                         
 80085: # hung for 30 min: test_lib2to3                            

ARMv7Thumb Ubuntu trunk    80120, 80098, 80084, 80084,  *** , 80030
 80120: # hung for 30 min: test_descr                              
 80098: # hung for 30 min: test_ast                                
 80084: # hung for 30 min: test_decorators                         
 ...
 80030: # hung for 30 min: test_opcodes

----------
title: buildbot: test_tokenize and test_io hung on ARMv4 Debian 3.x -> buildbot: hung on ARM Debian
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:51:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 18:51:42 +0000
Subject: [issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk
In-Reply-To: <1271528445.34.0.175485251427.issue8434@psf.upfronthosting.co.za>
Message-ID: <1271530302.4.0.431125711572.issue8434@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Related issue: #8281 (For gdb7, a python-gdb.py file is added to the build, allowing to use advanced gdb features when debugging Python.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8434>
_______________________________________

From report at bugs.python.org  Sat Apr 17 20:52:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 18:52:25 +0000
Subject: [issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk
In-Reply-To: <1271528445.34.0.175485251427.issue8434@psf.upfronthosting.co.za>
Message-ID: <1271530345.02.0.576475911654.issue8434@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8434>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:05:38 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sat, 17 Apr 2010 19:05:38 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271531138.23.0.461760123126.issue8420@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

I've found more unsafe code in Objects/setobject.c.
This code makes Python 3.1.2 segfault by using a bug in function set_merge:

class bad:
	def __eq__(self, other):
		if be_bad:
			set2.clear()
			raise Exception
		return self is other
	def __hash__(self):
		return 0
be_bad = False
set1 = {bad()}
set2 = {bad() for i in range(2000)}
be_bad = True
set1.update(set2)

Function set_symmetric_difference_update has a similar bug.

Another bug in set_symmetric_difference_update:

class bad:
	def __init__(self):
		print("Creating", id(self))
	def __del__(self):
		print("Deleting", id(self))
	def __eq__(self, other):
		print("Comparing", id(self), "and", id(other))
		if be_bad:
			dict2.clear()
		return self is other
	def __hash__(self):
		return 0
be_bad = False
set1 = {bad()}
dict2 = {bad(): None}
be_bad = True
set1.symmetric_difference_update(dict2)

----------
title: set_lookkey is unsafe -> Objects/setobject.c contains unsafe code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:11:47 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 17 Apr 2010 19:11:47 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1271531507.68.0.0887512518988.issue4814@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee:  -> giampaolo.rodola
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:17:49 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 17 Apr 2010 19:17:49 +0000
Subject: [issue6789] ftplib storelines does not honor strings returned in
	fp.readline
In-Reply-To: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>
Message-ID: <1271531869.89.0.798378380372.issue6789@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Closed as a duplicate of 6822 which provides a patch.

----------
nosy: +giampaolo.rodola
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6789>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:26:19 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sat, 17 Apr 2010 19:26:19 +0000
Subject: [issue8435] It is possible to observe a mutating frozenset
In-Reply-To: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>
Message-ID: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>


New submission from Eugene Kapun <abacabadabacaba at gmail.com>:

This code shows that frozensets aren't really immutable. The same frozenset is printed twice, with different content. Buggy functions are set_contains, set_remove and set_discard, all in Objects/setobject.c

class bad:
	def __eq__(self, other):
		global f2
		f2 = other
		print_f2()
		s1.add("querty")
		return self is other
	def __hash__(self):
		return hash(f1)
def print_f2():
	print(id(f2), repr(f2))
f1 = frozenset((1, 2, 3))
s1 = set(f1)
s1 in {bad()}
print_f2()

----------
components: Interpreter Core
messages: 103426
nosy: abacabadabacaba
severity: normal
status: open
title: It is possible to observe a mutating frozenset
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8435>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:34:49 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sat, 17 Apr 2010 19:34:49 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271532889.1.0.859561563493.issue8420@psf.upfronthosting.co.za>


Changes by Eugene Kapun <abacabadabacaba at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:37:21 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sat, 17 Apr 2010 19:37:21 +0000
Subject: [issue8436] set.__init__ accepts keyword args
In-Reply-To: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>
Message-ID: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>


New submission from Eugene Kapun <abacabadabacaba at gmail.com>:

>>> list().__init__(a=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'a' is an invalid keyword argument for this function
>>> set().__init__(a=0)

----------
components: Interpreter Core
messages: 103427
nosy: abacabadabacaba
severity: normal
status: open
title: set.__init__ accepts keyword args
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8436>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:39:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Apr 2010 19:39:02 +0000
Subject: [issue8435] It is possible to observe a mutating frozenset
In-Reply-To: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>
Message-ID: <1271533142.28.0.560586344551.issue8435@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8435>
_______________________________________

From report at bugs.python.org  Sat Apr 17 21:40:00 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Apr 2010 19:40:00 +0000
Subject: [issue8436] set.__init__ accepts keyword args
In-Reply-To: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>
Message-ID: <1271533200.24.0.594548772705.issue8436@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8436>
_______________________________________

From report at bugs.python.org  Sat Apr 17 22:07:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Apr 2010 20:07:55 +0000
Subject: [issue7811] [decimal] ValueError -> TypeError in from_tuple
In-Reply-To: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>
Message-ID: <1271534875.69.0.900576932663.issue7811@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Given the lack of agreement here, I propose that we just leave the current code as it is;  it doesn't seem like a big issue to me, and we should resist messing with code that isn't clearly broken.

----------
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7811>
_______________________________________

From report at bugs.python.org  Sat Apr 17 22:19:38 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Apr 2010 20:19:38 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271535578.57.0.762096563935.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It seems that FreeBSD has problems with the fact that readline.so is
linked with -lreadline and -lncursesw (why?).

With issue7384.patch I get no more errors using either Mark's test case
or test_curses.py.

----------
Added file: http://bugs.python.org/file16963/issue7384.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 17 22:44:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 20:44:53 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271537093.15.0.408520449645.issue2987@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't know how deep you want to get into detecting invalid URIs, but with the new patch this one causes a parsing error that is probably worth dealing with:

  http://abc[xyz]jkl

Maybe a reasonable set of checks would be (in hostname) that if the part of the netloc after the @ contains a ']' or a '[', then it must start with a [ and either end with a ] or contain a ']:'.

I can also mess up your new checks with something like this:

  http://foo[bar at baz]

or even:

  http://foo[bar at baz:33]

although those don't fail, they just faithfully produce the nonsensical results implicit in the invalid urls.  I think the above check logic in hostname would catch them, but it wouldn't catch this one:

  http://foo[bar@[bar]:33]

That may be OK, though, since as you noted earlier we aren't doing full URI validation.

Oh, and I notice that your test only covers the 'fast' path code, it doesn't exercise the general URI logic.

(Sorry I didn't review this issue earlier.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Sat Apr 17 22:51:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 20:51:25 +0000
Subject: [issue2302] Uses of SocketServer.BaseServer.shutdown have a race
In-Reply-To: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za>
Message-ID: <1271537485.28.0.209064251188.issue2302@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After a bit of investigation, this issue seems to be exactly why test_httpservers sometimes hangs.
The patch looks complicated to me, though; I don't think we really have to support the multiple shutdowns case.

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2302>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:12:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Apr 2010 21:12:50 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271538770.51.0.874536863049.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That patch works for me, too.  Nice!

> It seems that FreeBSD has problems with the fact that readline.so is
> linked with -lreadline and -lncursesw (why?).

Good question...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:13:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 21:13:53 +0000
Subject: [issue6789] ftplib storelines does not honor strings returned in
	fp.readline
In-Reply-To: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>
Message-ID: <1271538833.01.0.121806928096.issue6789@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
stage:  -> committed/rejected
superseder:  -> Error calling .storlines from ftplib
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6789>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:39:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 21:39:05 +0000
Subject: [issue2302] Uses of SocketServer.BaseServer.shutdown have a race
In-Reply-To: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za>
Message-ID: <1271540345.9.0.518445859111.issue2302@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a simpler patch. It also fixes the wrong use of a lock instead of an event in test_httpservers. With this patch, test_httpservers runs forever without freezing.

----------
Added file: http://bugs.python.org/file16964/shutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2302>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:39:59 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Apr 2010 21:39:59 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1271540399.01.0.648095948186.issue5099@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a patch I wrote entirely independently of this issue (Mercurial's test suite trigger it for me). I go further in terms of caching items than the original patch as I still got failures even when I stored just a reference to os (might be an OS X thing with the os module).

I just need someone to verify my patch works under Windows. If someone can do that I will commit it and Gabriel's test (with Antoine's suggested fixes).

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:40:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 21:40:14 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1271540414.35.0.96841363618.issue8281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_gdb.py refers to test_gdb_sample.py instead of gdb_sample.py. Attached patch fixes that.

But then I get new errors:
---------------
...
Verify the pretty-printing of unicode values ... ok                        
test_basic_command (__main__.PyListTests)                                  
Verify that the "py-list" command works ... FAIL                           
test_one_abs_arg (__main__.PyListTests)                                    
Verify the "py-list" command with one absolute argument ... FAIL           
test_two_abs_args (__main__.PyListTests)                                   
Verify the "py-list" command with two absolute arguments ... FAIL          
test_down_at_bottom (__main__.StackNavigationTests)                        
Verify handling of "py-down" at the bottom of the stack ... FAIL           
test_pyup_command (__main__.StackNavigationTests)                          
Verify that the "py-up" command works ... FAIL                             
test_up_at_top (__main__.StackNavigationTests)                             
Verify handling of "py-up" at the top of the stack ... FAIL                
test_up_then_down (__main__.StackNavigationTests)                          
Verify "py-up" followed by "py-down" ... FAIL                              
test_basic_command (__main__.PyBtTests)                                    
Verify that the "py-bt" command works ... FAIL                             
test_basic_command (__main__.PyPrintTests)                                 
Verify that the "py-print" command works ... FAIL                          
test_print_after_up (__main__.PyPrintTests) ... FAIL                       
test_printing_builtin (__main__.PyPrintTests) ... FAIL                     
test_printing_global (__main__.PyPrintTests) ... FAIL                      
test_basic_command (__main__.PyLocalsTests) ... FAIL                       
test_locals_after_up (__main__.PyLocalsTests) ... FAIL                     

======================================================================
FAIL: test_basic_command (__main__.PyListTests)                       
Verify that the "py-list" command works                               
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 535, in test_basic_command        
    cmds_after_breakpoint=['py-list'])                                
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_one_abs_arg (__main__.PyListTests)                         
Verify the "py-list" command with one absolute argument               
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 552, in test_one_abs_arg          
    cmds_after_breakpoint=['py-list 9'])                              
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_two_abs_args (__main__.PyListTests)                        
Verify the "py-list" command with two absolute arguments              
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 565, in test_two_abs_args         
    cmds_after_breakpoint=['py-list 1,3'])                            
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_down_at_bottom (__main__.StackNavigationTests)             
Verify handling of "py-down" at the bottom of the stack               
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 588, in test_down_at_bottom       
    cmds_after_breakpoint=['py-down'])                                
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_pyup_command (__main__.StackNavigationTests)               
Verify that the "py-up" command works                                 
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 578, in test_pyup_command         
    cmds_after_breakpoint=['py-up'])                                  
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_up_at_top (__main__.StackNavigationTests)                  
Verify handling of "py-up" at the top of the stack                    
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 595, in test_up_at_top            
    cmds_after_breakpoint=['py-up'] * 4)                              
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''                                                                                

======================================================================
FAIL: test_up_then_down (__main__.StackNavigationTests)               
Verify "py-up" followed by "py-down"                                  
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 602, in test_up_then_down         
    cmds_after_breakpoint=['py-up', 'py-down'])                       
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''                                                                                                    

======================================================================
FAIL: test_basic_command (__main__.PyBtTests)                         
Verify that the "py-bt" command works                                 
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 615, in test_basic_command        
    cmds_after_breakpoint=['py-bt'])                                  
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_basic_command (__main__.PyPrintTests)                      
Verify that the "py-print" command works                              
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 630, in test_basic_command        
    cmds_after_breakpoint=['py-print args'])                          
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_print_after_up (__main__.PyPrintTests)                     
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 636, in test_print_after_up       
    cmds_after_breakpoint=['py-up', 'py-print c', 'py-print b', 'py-print a'])
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace                   
    self.assertEquals(err, '')                                                
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''                                                                                

======================================================================
FAIL: test_printing_builtin (__main__.PyPrintTests)                   
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 648, in test_printing_builtin     
    cmds_after_breakpoint=['py-print len'])                           
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_printing_global (__main__.PyPrintTests)                    
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 642, in test_printing_global      
    cmds_after_breakpoint=['py-print __name__'])                      
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_basic_command (__main__.PyLocalsTests)                     
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 655, in test_basic_command        
    cmds_after_breakpoint=['py-locals'])                              
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

======================================================================
FAIL: test_locals_after_up (__main__.PyLocalsTests)                   
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "Lib/test/test_gdb.py", line 661, in test_locals_after_up      
    cmds_after_breakpoint=['py-up', 'py-locals'])                     
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace           
    self.assertEquals(err, '')                                        
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''                                                                                                    
---------------

I tried with pydebug and without pydebug.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file16965/test_gdb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8281>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:48:35 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 17 Apr 2010 21:48:35 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271540915.38.0.648994957857.issue8404@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I found the issue. The view types didn't have Py_TPFLAGS_CHECKTYPES set, so the types were using the old-style binary operators.

Here's a patch that fixes the issue. Please review.

----------
Added file: http://bugs.python.org/file16966/fix_dictviews_set_operations.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:48:57 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 17 Apr 2010 21:48:57 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271540937.82.0.205051515641.issue8404@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Removed file: http://bugs.python.org/file16927/fix_dictviews_as_number.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:52:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 21:52:52 +0000
Subject: [issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk
In-Reply-To: <1271528445.34.0.175485251427.issue8434@psf.upfronthosting.co.za>
Message-ID: <1271541172.79.0.354761910368.issue8434@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, this is a duplicate of #8279.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8434>
_______________________________________

From report at bugs.python.org  Sat Apr 17 23:53:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 21:53:15 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1271541195.88.0.0523193345912.issue8279@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#8434 is a duplicate of this issue.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8279>
_______________________________________

From report at bugs.python.org  Sun Apr 18 00:01:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 22:01:03 +0000
Subject: [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1271541663.91.0.980614415096.issue8281@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, my last message (msg103435) was for #8434, not this issue. Anyway, #8434 is a duplicate of #8279, it doesn't matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8281>
_______________________________________

From report at bugs.python.org  Sun Apr 18 00:34:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 22:34:13 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1271543653.66.0.483425076927.issue8279@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

In GDB 7.1, a gdb.frame object has no more function method: it's replaced by a name method. Tools/gdb/libpython.py should be modified:

Add >>GDB_70 = gdb.VERSION.startswith("7.0")<< at the beginning, and replace is_evalframeex() by:

    def is_evalframeex(self):
        '''Is this a PyEval_EvalFrameEx frame?'''
        if GDB_70:
            func = self._gdbframe.function()
            if not func:
                return False
            func_name = func.name
        else:
            func_name = self._gdbframe.name()

        if func_name != 'PyEval_EvalFrameEx':
            return False

        # I believe we also need to filter on the inline
        # struct frame_id.inline_depth, only regarding frames with
        # an inline depth of 0 as actually being this function
        #
        # So we reject those with type gdb.INLINE_FRAME
        return (self._gdbframe.type() == gdb.NORMAL_FRAME)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8279>
_______________________________________

From report at bugs.python.org  Sun Apr 18 00:42:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 17 Apr 2010 22:42:30 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1271544150.23.0.860772864897.issue8279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch, committed as r80156. As expected, there are still complaints about gdb.Frame.

As the original issue is now resolved, I'm closing this issue as fixed, and open a new issue for the remaining failures.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8279>
_______________________________________

From report at bugs.python.org  Sun Apr 18 00:45:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 17 Apr 2010 22:45:09 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

I get a number of failures in test_gdb with gdb 7.0.1 about gdb.Frame, e.g.

FAIL: test_basic_command (test.test_gdb.PyListTests)                  
Verify that the "py-list" command works                               
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 538, in test_basic_command
    cmds_after_breakpoint=['py-list'])                                             
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace   
    self.assertEquals(err, '')                                                     
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

----------
assignee: dmalcolm
messages: 103442
nosy: dmalcolm, haypo, loewis, ncoghlan
severity: normal
status: open
title: test_gdb: gdb.Frame has no attribute function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Sun Apr 18 00:51:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 22:51:25 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271544685.2.0.0193270363363.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See my msg103440 of issue #8279.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:02:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 23:02:05 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271545325.21.0.79610055788.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

According to documentation of the Python API of gdb, a frame has a function method. I read gdb 7.0, 7.0.1 and 7.1 (downloaded from http://ftp.gnu.org/gnu/gdb): there is not "function" method, but a "name" method.

On my Debiand Sid (gdb 7.1), gdb has the name method, but not the function method.

Can we use frame.name() instead of frame.function().name on any OS and all gdb 7.x versions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:05:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 23:05:05 +0000
Subject: [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1271545505.39.0.666001886835.issue8279@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> In GDB 7.1, a gdb.frame object has no more function method (...)

Missing function method is not related to gdb version: see #8437 (msg103444).

As Martin wrote: let's continue the discussion in issue #8437 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8279>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:08:45 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Apr 2010 23:08:45 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271545725.61.0.859854077166.issue8431@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine is right: On a fast machine (3.16GHz) test_io.py takes 810s
on debian-arm/qemu. All tests pass, so perhaps the limit is just too
restrictive on slow machines.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:13:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 23:13:51 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271546031.06.0.730007150803.issue8431@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On ARMv7Thumb Ubuntu trunk, build 47 hung after the following tests:
---
test_wait3
test_genericpath
test_uuid
test_zipimport_support
test_slice
test_decorators
---

build 48 hung after the following tests:
---
test_memoryio
test_robotparser
test_charmapcodec
test_ast
---

build 49 hung after the following tests:
---
test_grp
test_binascii
test_uu
test_zlib
test_unpack
test_array
test_list
test_cmd_line
test_traceback
test_global
test_index
test_cd
test_cd skipped -- No module named cd
test_bz2
test_fnmatch
test_posixpath
test_random
test_code
test_gc
test_dict
test_threading_local
test_eof
test_codecmaps_hk
test_aifc
test_descr
---

test_tokenize and test_io were not yet executed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:16:11 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Apr 2010 23:16:11 +0000
Subject: [issue8436] set.__init__ accepts keyword args
In-Reply-To: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>
Message-ID: <1271546171.18.0.332647891314.issue8436@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thx, will look at it when I get a chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8436>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:16:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 23:16:26 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271546186.75.0.186533840177.issue8431@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It would help if regrtest.py added a timestamp to messages (at least "test_xxx" lines). Eg. "18:08:34.750933: test_io".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:17:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Apr 2010 23:17:01 +0000
Subject: [issue7811] [decimal] ValueError -> TypeError in from_tuple
In-Reply-To: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>
Message-ID: <1271546221.23.0.442416820689.issue7811@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7811>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:18:17 2010
From: report at bugs.python.org (Darryl Miles)
Date: Sat, 17 Apr 2010 23:18:17 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271546297.73.0.705910010942.issue8108@psf.upfronthosting.co.za>


Darryl Miles <darryl.miles at darrylmiles.org> added the comment:

With regards to create test cases for certain situations, sure this would be possible but not with "pure python" since your APIs deny/inhibit the particular things required to force a situation for a test case.

With regards to SSL_peek() blocking, you'd need to explain yourself better on that one.  The patch has been tested with the test cases from Python SVN enough to be happy they run ok.  Maybe you have some offline not yet checked in SSL test cases you are referring to.  To clarify why this is being done, if there is unread data then SSL_shutdown() will never return 1.  Maybe you can simulate this situation by using SSL_write() with 1 byte payloads and a 10ms delay between each SSL_write() of the "QUIT response message" (you are trying to simulate network propagation delay).  Then you have a client that tries to do unwrap() right after having sent the quit command, but makes no attempt to receive the response.

I'll leave you guys too it about how you want to handle things with python (i.e. to make the design choice trade offs).  I think all the points have been covered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:19:30 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Apr 2010 23:19:30 +0000
Subject: [issue8435] It is possible to observe a mutating frozenset
In-Reply-To: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>
Message-ID: <1271546370.75.0.118341836072.issue8435@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm not sure that I care about this one.  The only way to pull it off it is to intentionally try to mutate the frozenset.  Will look at it along with the others though.

----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8435>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:25:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 23:25:37 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1271546737.7.0.871071625854.issue8263@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The test_break unit test is now skipped for freebsd6 on trunk in r80155.  I suspect this affects py3k as well on freebsd6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:26:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 23:26:25 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1271546785.92.0.743978895459.issue5099@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:32:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 23:32:22 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271547142.73.0.114542661431.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The commit creating methods "function", "select" were added the 24th february 2010, whereas gdb 7.1 was released around the 18th february 2010.
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-frame.c?cvsroot=src

I guess that the author (Dave Malcolm?) of the is_evalframeex() method in Tools/gdb/libpython.py uses the HEAD version of GDB.

About the select() method, Dave added the following comment to its Frame wrapper:
---

    def select(self):
        '''If supported, select this frame and return True; return False if unsupported

        Not all builds have a gdb.Frame.select method; seems to be present on Fedora 12
        onwards, but absent on Ubuntu buildbot'''
---

gdb in Fedora 12 is based on 7.0.1 plus a lot of patches. But I don't see a patch added the select() method to the Python API:
http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:35:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 23:35:48 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1271547348.49.0.448021075561.issue8263@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8432.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:35:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 23:35:52 +0000
Subject: [issue8432] build: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1271547352.09.0.311846277941.issue8432@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8263.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8432>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:45:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Apr 2010 23:45:14 +0000
Subject: [issue8424] buildbots: test_itimer_virtual failures
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271547914.93.0.281149093546.issue8424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

i486 Ubuntu also showed the test_itimer_virtual failure (but not the other one...FreeBSD didn't show the other one either) here:

http://www.python.org/dev/buildbot/builders/i386 Ubuntu trunk/builds/949/steps/test/logs/stdio

----------
title: tiger/FreeBSD7.2 buildbots: test_itimer_virtual failures -> buildbots: test_itimer_virtual failures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Sun Apr 18 01:53:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Apr 2010 23:53:13 +0000
Subject: [issue850728] Semaphore.acquire() timeout parameter
Message-ID: <1271548393.96.0.865124580083.issue850728@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Modified patch committed in r80157 (py3k). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850728>
_______________________________________

From report at bugs.python.org  Sun Apr 18 02:03:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 00:03:56 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271549036.5.0.87852991746.issue8394@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed: r80159 (py3k), r80160 (3.1). I commited a different version of my patch to support None.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Sun Apr 18 02:10:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 00:10:34 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271549434.81.0.619748326822.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Current code of execve() has a bug: it uses the length of the environment variable value in *characters* and not in *bytes* to allocate the "p" buffer. I remember that someone wrote a comment somewhere about that... The result is that the environment variable value is truncated by 1 byte.

Example (copy of http://dpaste.com/184803/):
-----------
$ cat test.py
#!/usr/bin/python
# -*- coding: utf-8 -*-

import os

env = {"VAR": "?d"}
os.execve("test.sh", [], env)
$ cat test.sh
#!/bin/bash

declare -p VAR
$ python2.6 test.py
declare -x VAR="?d"
$ python3.1 test.py
declare -x VAR="?"
-----------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Sun Apr 18 02:19:33 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 18 Apr 2010 00:19:33 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271549973.44.0.322954735005.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16947/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Apr 18 02:20:04 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 18 Apr 2010 00:20:04 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271550004.75.0.966982821099.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Added file: http://bugs.python.org/file16967/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Apr 18 02:23:09 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 18 Apr 2010 00:23:09 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271550189.99.0.702170760638.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Yet another update to bfs.patch.

I upload a variation on Florent's write test which prints progress of background CPU bound threads as: thread-name timestamp progress

Here are some numbers from Windows XP 32bit with Intel q9400 (4 cores). Builds produced with VS express (alas - no optimizations, so official builds may behave differently).

BFS - 
33% CPU, 37,000 context switches per second

z:\bfs\PCbuild\python.exe y:\writes.py
t1 2.34400010109 0
t2 2.42199993134 0
t1 4.67199993134 1
t2 4.79699993134 1
t1 7.01600003242 2
t2 7.20300006866 2
t1 9.375 3
t2 9.625 3
t1 11.7039999962 4
t2 12.0309998989 4
t1 14.0469999313 5
t2 14.4219999313 5
t1 16.4070000648 6
t2 16.7809998989 6
t1 18.7820000648 7
t2 19.125 7
t1 21.1570000648 8
t2 21.4839999676 8
t1 23.5 9
t2 23.8589999676 9
t1 25.8599998951 10
t2 26.2339999676 10
t1 28.2349998951 11
28.2189998627

gilinter - starves both bg threads and high rate of context switches.
45% CPU, 203,000 context switches per second

z:\gilinter\PCbuild\python.exe y:\writes.py
t1 13.0939998627 0
t1 26.4219999313 1
t1 39.8129999638 2
t1 53.1559998989 3
57.5470001698

PyCON - starves one bg thread and slow IO thread 
Py32 - starves IO thread as expected.

Note, PyCON, gilinter and py32 starve the bg thread with Dave's original buffered write test as well - http://bugs.python.org/issue7946#msg101116

----------
Added file: http://bugs.python.org/file16968/writes.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Apr 18 04:37:16 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 18 Apr 2010 02:37:16 +0000
Subject: [issue8424] buildbots: test_itimer_virtual failures
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271558236.73.0.21998654619.issue8424@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

To make the situation worse, this Ubuntu buildbot passed all signal tests on the next run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Sun Apr 18 07:25:08 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Apr 2010 05:25:08 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1271568308.55.0.173530650199.issue6095@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Sun Apr 18 07:42:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 05:42:28 +0000
Subject: [issue8436] set.__init__ accepts keyword args
In-Reply-To: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>
Message-ID: <1271569348.55.0.838763269862.issue8436@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If you submit a patch, be sure to include a test that covers both set.__init__() and frozenset.__init__().  Model the code are the equivalent checks in Modules/itertoolsmodule.c

----------
priority:  -> low
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8436>
_______________________________________

From report at bugs.python.org  Sun Apr 18 07:44:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Apr 2010 05:44:10 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271569450.25.0.923029146772.issue8437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Victor, please leave that to David. He will fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Sun Apr 18 07:45:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 05:45:09 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1271569509.23.0.788308884896.issue8425@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
keywords: +easy
stage:  -> patch review
versions: +Python 2.7, Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Sun Apr 18 07:45:52 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 05:45:52 +0000
Subject: [issue8436] set.__init__ accepts keyword args
In-Reply-To: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>
Message-ID: <1271569552.59.0.407034561864.issue8436@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8436>
_______________________________________

From report at bugs.python.org  Sun Apr 18 08:32:39 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 18 Apr 2010 06:32:39 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1271572359.02.0.824831234253.issue5099@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i don't see your attachment brett.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sun Apr 18 09:52:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 18 Apr 2010 07:52:10 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271577130.19.0.47978035394.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Ok. I just wanted to make it compatible with my patch.py utility designed as a counterpart to diff.py to make Python contributing process self-sufficient on any platform. Its parser component doesn't support context diffs.

http://code.google.com/p/python-patch/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Sun Apr 18 09:59:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 18 Apr 2010 07:59:27 +0000
Subject: [issue8355] diff.py produce unified format by default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1271577567.36.0.0761680564005.issue8355@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

But I still think sticking to -c behavior by default is too conservative for clear minds. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8355>
_______________________________________

From report at bugs.python.org  Sun Apr 18 10:01:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 08:01:19 +0000
Subject: [issue8430] test_site failure with non-ASCII directory
In-Reply-To: <1271511593.69.0.166956245853.issue8430@psf.upfronthosting.co.za>
Message-ID: <1271577679.35.0.35890130479.issue8430@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r80161 (py3k).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8430>
_______________________________________

From report at bugs.python.org  Sun Apr 18 10:02:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 08:02:44 +0000
Subject: [issue8422] tiger buildbot: test_abspath_issue3426 failure
	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1271577764.84.0.916535282822.issue8422@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8423.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8422>
_______________________________________

From report at bugs.python.org  Sun Apr 18 10:02:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 08:02:47 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1271577767.76.0.98651512323.issue8423@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8422.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Sun Apr 18 10:25:33 2010
From: report at bugs.python.org (Ray.Allen)
Date: Sun, 18 Apr 2010 08:25:33 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

According to PEP 383, the new "surrogateescape" error handler of codecs should begin to appear since Python3.1, but in the trunk I found some code have already used it:

Modules/_io/fileio.c:

static int
fileio_init(PyObject *oself, PyObject *args, PyObject *kwds){
    ...
    stringobj = PyUnicode_AsEncodedString(
		u, Py_FileSystemDefaultEncoding, "surrogateescape");
    ...

Obviously, the "surrogateescape" error handler not exists. 

Some test code:
===========================
import io

file_name = u'\udc80.txt'
f = io.FileIO(file_name)
===========================

When run this piece of code on a machine whose file system default encoding is gb2312, will raise an exception:

LookupError: unknown error handler name 'surrogateescape'

I don't know weather this is a bug?

Thanks.

----------
components: Unicode
messages: 103470
nosy: loewis, ysj.ray
severity: normal
status: open
title: Codecs: "surrogateescape" error handler in Python 2.7
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 10:25:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 08:25:47 +0000
Subject: [issue8422] tiger buildbot: test_abspath_issue3426 failure
	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1271579147.71.0.0944881795711.issue8422@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r80163: move the test to a new function and skip the function on Mac.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8422>
_______________________________________

From report at bugs.python.org  Sun Apr 18 10:27:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 08:27:01 +0000
Subject: [issue8430] test_site failure with non-ASCII directory
In-Reply-To: <1271577679.35.0.35890130479.issue8430@psf.upfronthosting.co.za>
Message-ID: <201004181026.52687.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Fixed by r80161 (py3k).

It works, the buildbot is now green.

http://www.python.org/dev/buildbot/all/builders/AMD64 Ubuntu wide 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8430>
_______________________________________

From report at bugs.python.org  Sun Apr 18 10:46:18 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 08:46:18 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271580378.13.0.474449301959.issue8420@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching a patch for set_lookkey() that does a DECREF only when the refcnt > 1 so that the DECREF won't trigger any state changes.

The merge crasher still needs a patch.

----------
keywords: +patch
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16969/lookkey.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sun Apr 18 11:27:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Apr 2010 09:27:03 +0000
Subject: [issue8401] Strange behavior of bytearray slice assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271582823.92.0.655775900164.issue8401@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Python is not (e.g.) Haskell; Python strings are not lists whose contents happen to be characters.  Allowing an empty string here is a step backwards in the direction of "why not allow any string whose contents have an unambiguous meaning as bytes", i.e. the default encoding ASCII in Python 2.x.  Passing a string where bytes are expected is a programming error, and it should be rewarded with an exception, no matter if the string happens to be empty or not.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8401>
_______________________________________

From report at bugs.python.org  Sun Apr 18 12:20:37 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 18 Apr 2010 10:20:37 +0000
Subject: [issue8439] test_linecache failing in py3k r80169
In-Reply-To: <4BCADCEA.2060609@timgolden.me.uk>
Message-ID: <4BCADCEA.2060609@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

test_linecache in the current py3k branch is failing on my WinXP machine with ERROR_SHARING_VIOLATION.
The attached trivial patch appears to fix the problem, altho' I'm unfamiliar
with the module in question so it may be that there's more to be done.

----------
files: test_linecache.py.patch
keywords: patch
messages: 103475
nosy: tim.golden
severity: normal
status: open
title: test_linecache failing in py3k r80169
Added file: http://bugs.python.org/file16970/test_linecache.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8439>
_______________________________________
-------------- next part --------------
Index: test_linecache.py
===================================================================
--- test_linecache.py	(revision 80169)
+++ test_linecache.py	(working copy)
@@ -114,6 +114,7 @@
                 for index, line in enumerate(source):
                     self.assertEquals(line, getline(source_name, index + 1))
                     source_list.append(line)
+                source.close ()
 
         finally:
             support.unlink(source_name)

From report at bugs.python.org  Sun Apr 18 12:34:09 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 18 Apr 2010 10:34:09 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271586849.07.0.160905217279.issue8431@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I ran the whole test suite on

http://people.debian.org/~aurel32/qemu/arm/debian_lenny_arm_small.qcow2

and there were no hanging processes. test_tokenize also takes around
10min on a fast machine (12s without -uall).

Probably the timeout has to be increased drastically or -uall should
be dropped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sun Apr 18 12:52:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 10:52:12 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271586849.07.0.160905217279.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271588057.3432.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Probably the timeout has to be increased drastically or -uall should
> be dropped.

We should probably increase the timeout on this particular set of
buildbots. -uall has no influence on the duration of e.g. test_io.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sun Apr 18 12:53:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 10:53:12 +0000
Subject: [issue8439] test_linecache failing in py3k r80169
In-Reply-To: <4BCADCEA.2060609@timgolden.me.uk>
Message-ID: <1271587992.87.0.853638574792.issue8439@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8439>
_______________________________________

From report at bugs.python.org  Sun Apr 18 12:57:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 10:57:31 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271588251.86.0.890304335898.issue8438@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Certainly a bug indeed.

----------
components: +IO -Unicode
nosy: +pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 13:00:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Apr 2010 11:00:01 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271588401.29.0.151717014911.issue8438@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 13:26:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 18 Apr 2010 11:26:30 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271589990.69.0.924922559137.issue8438@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think it would be best to backport the handler (even though it is not needed in Python 2.7), since it makes porting apps to 3.x easier.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 13:29:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Apr 2010 11:29:38 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271590178.06.0.284800417115.issue8438@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1 on backporting. The handler isn't really meant to be used in applications, plus 2.7 is in feature-freeze.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 13:37:52 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 18 Apr 2010 11:37:52 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271590178.06.0.284800417115.issue8438@psf.upfronthosting.co.za>
Message-ID: <4BCAEF47.1070303@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> -1 on backporting. The handler isn't really meant to be used in applications, plus 2.7 is in feature-freeze.

Since 2.7 is meant to be the last release of the 2.x series,
we have to make sure that it has all the bits necessary to make
porting apps to 3.x easy.

As a result, omissions such as the new handler which became
necessary after the change to the UTF-8 codec in 3.x deserve
special attention, overriding such self-imposed restrictions.

The handler is not meant to be used internally only. In fact,
it was the prerequisite for me to be +1 on the UTF-8 codec
change in 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 13:41:16 2010
From: report at bugs.python.org (George Sakkis)
Date: Sun, 18 Apr 2010 11:41:16 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271590876.27.0.823287851841.issue2090@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

FWIW attached is a patch that allows only valid identifiers before calling import_submodule(), and returns silently otherwise (for backwards compatibility).

For the record, the reason that empty strings and some combinations of slashes/dots caused the double import was that they were concatenated to the path, and if the final path was a valid directory and contained an __init__.py it was imported. E.g. __import__('pkg.subpkg', fromlist=['/../.']) ends up looking in "pkg/subpkg//../.". On the surface this seems like a potential directory traversal attack hole, although I couldn't get past 'pkg' by passing '../../../', so I guess there must be other checks before attempting the import.

----------
keywords: +patch
Added file: http://bugs.python.org/file16971/issue_2090.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Sun Apr 18 14:03:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Apr 2010 12:03:39 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <4BCAEF47.1070303@egenix.com>
Message-ID: <4BCAF515.10604@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Since 2.7 is meant to be the last release of the 2.x series,
> we have to make sure that it has all the bits necessary to make
> porting apps to 3.x easy.

Any new features in 2.7 require approval from the release manager now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 14:05:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 12:05:34 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271592334.86.0.840577967729.issue8438@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Any new features in 2.7 require approval from the release manager now.

Not only, but they also need someone to provide a patch :)
Removing any surrogateescape use from the io module would be comparatively much easier.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 14:05:38 2010
From: report at bugs.python.org (George Sakkis)
Date: Sun, 18 Apr 2010 12:05:38 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271592338.01.0.755764710475.issue2090@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

> On the surface this seems like a potential directory traversal attack
> hole, although I couldn't get past 'pkg' by passing '../../../', so I 
> guess there must be other checks before attempting the import.

I rushed to post; it turns out one *can* access packages in parent directories, so I think it's accurate to describe it as a directory traversal hole.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Sun Apr 18 14:43:00 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sun, 18 Apr 2010 12:43:00 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271594580.99.0.484248787628.issue8420@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

This patch still assumes that if so->table didn't change then the table wasn't reallocated (see http://en.wikipedia.org/wiki/ABA_problem). One solution is to check that so->mask didn't change as well. Also, checking that refcnt > 1 is redundant because if entry->key == startkey then there are at least two references: one from entry->key and another from startkey.

These functions have a bug that may cause them to refer to deallocated memory when both arguments are sets: set_intersection, set_isdisjoint, set_difference_update_internal, set_difference, set_symmetric_difference_update, set_issubset.
These functions may also do the same if the first argument is a set and the second argument is a dict: set_difference, set_symmetric_difference_update.

Bugs in set_repr:
> keys = PySequence_List((PyObject *)so);
> if (keys == NULL)
> 	goto done;
> 
> listrepr = PyObject_Repr(keys);
> Py_DECREF(keys);
List pointed to by keys is already deallocated at this point.
> if (listrepr == NULL) {
> 	Py_DECREF(keys);
But this code tries to DECREF it.
> 	goto done;
> }
> newsize = PyUnicode_GET_SIZE(listrepr);
> result = PyUnicode_FromUnicode(NULL, newsize);
> if (result) {
> 	u = PyUnicode_AS_UNICODE(result);
> 	*u++ = '{';
> 	/* Omit the brackets from the listrepr */
> 	Py_UNICODE_COPY(u, PyUnicode_AS_UNICODE(listrepr)+1,
> 			   PyUnicode_GET_SIZE(listrepr)-2);
> 	u += newsize-2;
> 	*u++ = '}';
> }
> Py_DECREF(listrepr);
> if (Py_TYPE(so) != &PySet_Type) {
result may be NULL here.
> 	PyObject *tmp = PyUnicode_FromFormat("%s(%U)",
> 					     Py_TYPE(so)->tp_name,
> 					     result);
I think PyUnicode_FromFormat won't like it.
> 	Py_DECREF(result);
> 	result = tmp;
> }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sun Apr 18 15:00:57 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 18 Apr 2010 13:00:57 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271595657.14.0.670328841036.issue8431@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the ARMv4 buildbot is a 500Mhz Xscale, with a SATA disk attached, 256MB RAM. It can't go faster :-/

the ARMv7 buildbot is a cortex-a8, 500Mhz, 512MB RAM. I found here five or six python processes still running, now killed. The machine may be unresponsive sometime, as one other (non python) build might run in parallel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sun Apr 18 15:13:43 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 18 Apr 2010 13:13:43 +0000
Subject: [issue8440] test_heapq interfering with test_import on py3k
In-Reply-To: <4BCB057A.7030108@timgolden.me.uk>
Message-ID: <4BCB057A.7030108@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

If test_heapq is run before test_import on the current py3k head,
test_import will fail as per the attached traceback.

python -m test.regrtest -W test_heapq test_import > test_import.log

At a glance I can't see any obvious reason why test_heapq should have
any effect on test_import. Raising this bug while I try to narrow down.

An extra assert inside support.make_legacy_pyc confirms that
the .pyc being renamed into does in fact already exist.

Running test_import on its own or via regrtest when not preceded
by test_heapq runs with error.

----------
files: test_import.log
messages: 103488
nosy: tim.golden
severity: normal
status: open
title: test_heapq interfering with test_import on py3k
Added file: http://bugs.python.org/file16972/test_import.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8440>
_______________________________________
-------------- next part --------------
test_heapq
test_import
compiled to __pycache__\longlist.cpython-32.pyc
test test_import failed -- Traceback (most recent call last):
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py", line 167, in test_module_with_large_stack
    exec('import ' + module)
  File "<string>", line 1, in <module>
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py", line 320, in load_module
    code_object = self.get_code(module.__name__)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py", line 429, in get_code
    "object for {0!r}".format(fullname))
ImportError: no source or bytecode available to create code object for 'longlist'

Re-running test test_import in verbose mode
test_case_sensitivity (test.test_import.ImportTests) ... ok
test_double_const (test.test_import.ImportTests) ... ok
test_execute_bit_not_copied (test.test_import.ImportTests) ... skipped 'test meaningful only on posix systems'
test_failing_import_sticks (test.test_import.ImportTests) ... ok
test_failing_reload (test.test_import.ImportTests) ... ok
test_file_to_source (test.test_import.ImportTests) ... ok
test_imp_module (test.test_import.ImportTests) ... ok
test_import (test.test_import.ImportTests) ... ok
test_import_by_filename (test.test_import.ImportTests) ... ok
test_import_initless_directory_warning (test.test_import.ImportTests) ... ok
test_import_name_binding (test.test_import.ImportTests) ... ok
test_module_with_large_stack (test.test_import.ImportTests) ... compiled to __pycache__\longlist.cpython-32.pyc
ERROR
test___cached__ (test.test_import.PycacheTests) ... ok
test___cached___legacy_pyc (test.test_import.PycacheTests) ... ok
test_import_pyc_path (test.test_import.PycacheTests) ... ok
test_missing_source (test.test_import.PycacheTests) ... ok
test_missing_source_legacy (test.test_import.PycacheTests) ... ok
test_package___cached__ (test.test_import.PycacheTests) ... ok
test_package___cached___from_pyc (test.test_import.PycacheTests) ... ok
test_unwritable_directory (test.test_import.PycacheTests) ... skipped 'test meaningful only on posix systems'
test_basics (test.test_import.PycRewritingTests) ... ok
test_foreign_code (test.test_import.PycRewritingTests) ... ok
test_incorrect_code_name (test.test_import.PycRewritingTests) ... ok
test_module_without_source (test.test_import.PycRewritingTests) ... ok
test_UNC_path (test.test_import.PathsTests) ... ok
test_trailing_slash (test.test_import.PathsTests) ... ok
test_issue3221 (test.test_import.RelativeImportTests) ... ok
test_relimport_star (test.test_import.RelativeImportTests) ... ok
test_override_builtin (test.test_import.OverridingImportBuiltinTests) ... ok

======================================================================
ERROR: test_module_with_large_stack (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py", line 161, in test_module_with_large_stack
    make_legacy_pyc(filename)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\support.py", line 209, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
WindowsError: [Error 183] Cannot create a file when that file already exists

----------------------------------------------------------------------
Ran 29 tests in 1.672s

FAILED (errors=1, skipped=2)
test test_import failed -- Traceback (most recent call last):
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py", line 161, in test_module_with_large_stack
    make_legacy_pyc(filename)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\support.py", line 209, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
WindowsError: [Error 183] Cannot create a file when that file already exists


From report at bugs.python.org  Sun Apr 18 15:15:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 13:15:54 +0000
Subject: [issue8431] buildbot: hung on ARM Debian
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271596554.88.0.887308410127.issue8431@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> the ARMv4 buildbot is a 500Mhz Xscale, with a SATA disk attached, 256MB 
> RAM. It can't go faster :-/

Have you checked running the test suite manually (possibly with the -v option for more progress information), to check whether these were genuine freezes? Have you also checked that there was no swapping during the test suite?

In any case, we should probably increase the timeout on that buildbot. Perhaps Martin knows how to do that.

----------
components: +Tests
nosy: +loewis
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8431>
_______________________________________

From report at bugs.python.org  Sun Apr 18 15:29:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 13:29:40 +0000
Subject: [issue8440] test_heapq interfering with test_import on py3k
In-Reply-To: <4BCB057A.7030108@timgolden.me.uk>
Message-ID: <1271597380.39.0.129291543933.issue8440@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests
nosy: +barry, brett.cannon
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8440>
_______________________________________

From report at bugs.python.org  Sun Apr 18 15:55:28 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 18 Apr 2010 13:55:28 +0000
Subject: [issue3817] ftplib: ABOR does not consider 225 response code
In-Reply-To: <1220968645.43.0.419983108509.issue3817@psf.upfronthosting.co.za>
Message-ID: <1271598928.56.0.565985415215.issue3817@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed as r80172 (python 2.7) and r80176 (python 3.2).

----------
assignee:  -> giampaolo.rodola
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
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/issue3817>
_______________________________________

From report at bugs.python.org  Sun Apr 18 16:09:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 14:09:04 +0000
Subject: [issue8441] Framework build broken in 3.2 brunk
In-Reply-To: <1271599744.14.0.685635086765.issue8441@psf.upfronthosting.co.za>
Message-ID: <1271599744.14.0.685635086765.issue8441@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I cannot build a framework build of the 3.2 branch at the moment due to unresolved references to "_Py_char2wchar" when linking the dylib that gets placed into the framework:

Undefined symbols:
  "__Py_char2wchar", referenced from:
      _Py_Main in libpython3.2.a(main.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
Undefined symbols:
  "__Py_char2wchar", referenced from:
      _Py_Main in libpython3.2.a(main.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status


This is because that symbol is defined in Modules/python.c which doesn't get linked into the shared library.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 103491
nosy: ronaldoussoren
priority: release blocker
severity: normal
status: open
title: Framework build broken in 3.2 brunk
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8441>
_______________________________________

From report at bugs.python.org  Sun Apr 18 16:09:26 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 14:09:26 +0000
Subject: [issue8441] Framework build broken in 3.2 brunk
In-Reply-To: <1271599744.14.0.685635086765.issue8441@psf.upfronthosting.co.za>
Message-ID: <1271599766.28.0.860262856918.issue8441@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8441>
_______________________________________

From report at bugs.python.org  Sun Apr 18 16:12:43 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 18 Apr 2010 14:12:43 +0000
Subject: [issue1726451] ftplib and ProFTPD NLST 226 without 1xx response
Message-ID: <1271599963.72.0.0788310672243.issue1726451@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726451>
_______________________________________

From report at bugs.python.org  Sun Apr 18 16:21:49 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 18 Apr 2010 14:21:49 +0000
Subject: [issue1037516] ftplib PASV error bug
Message-ID: <1271600509.64.0.638139556179.issue1037516@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Closing this out as invalid as an exception being raised after an invalid PASV response makes perfect sense.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1037516>
_______________________________________

From report at bugs.python.org  Sun Apr 18 16:48:32 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 14:48:32 +0000
Subject: [issue8441] Framework build broken in 3.2 brunk
In-Reply-To: <1271599744.14.0.685635086765.issue8441@psf.upfronthosting.co.za>
Message-ID: <1271602112.77.0.214998668791.issue8441@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r80181 (3.2)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8441>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:12:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 15:12:15 +0000
Subject: [issue7072] isspace(0xa0) is true on Mac OS X
In-Reply-To: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>
Message-ID: <1271603535.14.0.169947616364.issue7072@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r80178 (trunk), r80180 (2.6), r80182 (3.2), r80183 (3.1)

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7072>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:15:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 15:15:37 +0000
Subject: [issue8442] Broken zipfile with  python 3.2 on osx
In-Reply-To: <1271603737.34.0.035153225146.issue8442@psf.upfronthosting.co.za>
Message-ID: <1271603737.34.0.035153225146.issue8442@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

In the output of test_distutils with python 3.2 (current version checkout):
======================================================================
ERROR: test_prune_file_list (distutils.tests.test_sdist.SDistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/python-3.x/Lib/distutils/tests/test_sdist.py", line 131, in test_prune_file_list
    zip_file = zipfile.ZipFile(join(dist_folder, 'fake-1.0.zip'))
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 684, in __init__
    self._GetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 710, in _GetContents
    self._RealGetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 758, in _RealGetContents
    filename = filename.decode('cp437')
LookupError: unknown encoding: cp437

----------
components: Library (Lib)
messages: 103495
nosy: ronaldoussoren
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Broken zipfile with  python 3.2 on osx
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8442>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:15:41 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 15:15:41 +0000
Subject: [issue8443] Broken zipfile with  python 3.2 on osx
In-Reply-To: <1271603740.29.0.626086145163.issue8443@psf.upfronthosting.co.za>
Message-ID: <1271603740.29.0.626086145163.issue8443@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

In the output of test_distutils with python 3.2 (current version checkout):
======================================================================
ERROR: test_prune_file_list (distutils.tests.test_sdist.SDistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/python-3.x/Lib/distutils/tests/test_sdist.py", line 131, in test_prune_file_list
    zip_file = zipfile.ZipFile(join(dist_folder, 'fake-1.0.zip'))
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 684, in __init__
    self._GetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 710, in _GetContents
    self._RealGetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 758, in _RealGetContents
    filename = filename.decode('cp437')
LookupError: unknown encoding: cp437

----------
components: Library (Lib)
messages: 103496
nosy: ronaldoussoren
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Broken zipfile with  python 3.2 on osx
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8443>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:19:03 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 18 Apr 2010 15:19:03 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271603943.06.0.745457977867.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

To clarify a couple of things:

On some systems (Redhat?) readline is not linked against ncurses in order to give the user the possibility to choose. This is why setup.py
has to select an ncurses version.

However, things can go wrong if readline is already linked against
a specific ncurses version. On FreeBSD-8.0 this version is ncurses,
but setup.py selects ncursesw:


stefan at freebsd-amd64:~> ldd /lib/libreadline.so.8 
/lib/libreadline.so.8:
        libncurses.so.8 => /lib/libncurses.so.8 (0x800b3e000)
        libc.so.7 => /lib/libc.so.7 (0x800648000)
stefan at freebsd-amd64:~> ls /lib/libncurses*
/lib/libncurses.so.8    /lib/libncursesw.so.8


issue7384.patch suppresses the selection, but is a little primitive.

I've created a new patch, which does the following:

  1) Detect if readline is already linked against ncurses and
     if so, skip any further selection. This must be done.

  2) Use the same version of ncurses for readline.so and _curses.so.


I'm not sure if 2) is necessary. With the previous patch, readline.so
was linked against ncurses and _curses.so against ncursesw. All tests
were passed though.



Any thoughts whether readline.so and _curses.so should link against
the same curses library?

----------
Added file: http://bugs.python.org/file16973/issue7384-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:22:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Apr 2010 15:22:18 +0000
Subject: [issue8443] Broken zipfile with  python 3.2 on osx
In-Reply-To: <1271603740.29.0.626086145163.issue8443@psf.upfronthosting.co.za>
Message-ID: <1271604138.41.0.61750784527.issue8443@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Duplicate of #8442

----------
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> Broken zipfile with  python 3.2 on osx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8443>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:25:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 15:25:37 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tk
	configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1271604337.69.0.106278952695.issue5651@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed the patch in r80179 (trunk), r80184 (2.6), r80185 (3.2), r80186 (3.1)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5651>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:39:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Apr 2010 15:39:51 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271345993.52.0.689698262359.issue8299@psf.upfronthosting.co.za>
Message-ID: <4BCB27C3.8040904@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, I don't know if you were suggesting that a "fair" mutex would
> make the emulated semaphore fair too.  You probably weren't, but just
> in case, the fairness of the mutex is immaterial because it is only
> held for a short time to guard the internal state of the "semaphore".
> You won't see threads queing up on it, but they will queue on the
> Contition variable.

Exactly so. I still don't see why you then infer that the GIL is unfair.
It is not IF THE CONDITION VARIABLE IS FAIR. As I said, some
implementations of condition variables *are* fair, e.g. the Linux one
(which in itself isn't really relevant here, because Linux uses the
semaphore GIL, anyway). However, it remains unclear why you think that
the GIL is not fair in pthreads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:41:35 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 15:41:35 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1271605295.62.0.239727234745.issue8366@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This problem is caused by this bit in Makefile.pre.in:

OPT=            @OPT@
BASECFLAGS=     @BASECFLAGS@
CFLAGS=         $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS)


There both 'BASECFLAGS' and 'CFLAGS' get patched in from configure.in, while the intention of the configure script always was that only BASECFLAGS gets set from configure CFLAGS. 


BTW. I always test with a build directory separate from the source directory, that makes it a lot easier to ensure that you have a clean environment:

$ mkdir build
$ cd build
$ ../configure ....


I'm currently testing a fix that only sets CFLAGS and CPPFLAGS and will apply that if this results in a valid build.


Adding 2.6 and 3.1 to the list of versions because those also have the same change to Makefile.pre.in

----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 18 17:55:46 2010
From: report at bugs.python.org (Gath-Gealaich)
Date: Sun, 18 Apr 2010 15:55:46 +0000
Subject: [issue8435] It is possible to observe a mutating frozenset
In-Reply-To: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>
Message-ID: <1271606146.48.0.137457118482.issue8435@psf.upfronthosting.co.za>


Gath-Gealaich <gathgealaich at gmail.com> added the comment:

I have found this in Python 3.1.2 documentation:

"Note, the elem argument to the __contains__(), remove(), and discard() methods may be a set. To support searching for an equivalent frozenset, the elem set is temporarily mutated during the search and then restored. During the search, the elem set should not be read or mutated since it does not have a meaningful value."

I seems to me that this is precisely what happens in this code. Now we might argue whether this is an acceptable state of affairs, but at least it's a documented behavior (and people shouldn't write equality predicates like this anyway. ;)).

----------
nosy: +ggeal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8435>
_______________________________________

From report at bugs.python.org  Sun Apr 18 18:06:16 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 18 Apr 2010 16:06:16 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271606776.25.0.331046446053.issue8391@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Sun Apr 18 18:27:15 2010
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Sun, 18 Apr 2010 16:27:15 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271608035.82.0.787025865937.issue7384@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Just to state the obvious: ncursesw is needed for wide character support (i.e. Unicode).

Also, have you tried asking Thomas Dickey (dickey at invisible-island.net) about this? He might be able to give some clue about it since he's the main curses maintainer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sun Apr 18 19:26:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 17:26:40 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1271611600.04.0.983208863561.issue8366@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Btw. this issue is caused by the fix for issue 1628484.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 18 19:33:18 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 17:33:18 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271611998.81.0.0303742488908.issue8420@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> One solution is to check that so->mask didn't 
> change as well. 

I saw that and agree it would make a tighter check, but haven't convinced myself that it is necessary.

> Also, checking that refcnt > 1 is redundant 
> because if entry->key == startkey then there 
> are at least two references: one from entry->key 
> and another from startkey.

It is a meaningful check.  We have our own INCREF
and one for the key being in the table.  If the
count is 1, then it means that the comparison
check deleted the key from the table or replaced
its value (see issue 1517).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sun Apr 18 19:33:56 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Apr 2010 17:33:56 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271612036.53.0.359138800638.issue8438@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The 2.x io lib should use the same encoding principles as the rest of 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 19:35:02 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 18 Apr 2010 17:35:02 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1271612102.05.0.595073618919.issue6507@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Any chance, that my patch will be accepted? Is there a problem with it?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sun Apr 18 19:37:30 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 17:37:30 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1271612250.79.0.561743297476.issue6507@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
stage: needs patch -> commit review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:12:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 18:12:18 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271614338.62.0.504864949352.issue8438@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a fix + test.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file16974/surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:14:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 18:14:51 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271614491.48.0.487799501683.issue8438@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16974/surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:15:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 18:15:01 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271614501.56.0.82721127132.issue8438@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file16975/surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:20:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 18:20:17 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271614817.51.0.532587928673.issue8438@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think it would be best to backport the handler (even though 
> it is not needed in Python 2.7), since it makes porting apps 
> to 3.x easier.

surrogateescape should not be used directly be applications. It's used by Python3 internals using unicode by default.

I don't know if it's would help porting applications from Python2 to Python3. I don't know a use case of surrogateescape in Python2. By default, Python2 uses byte string everywhere, especially for filenames, and so it doesn't need any unicode error handler.

Another point to consider is that utf8 encoder rejects surrogates in Python3, whereas surrogates are accepted by the Python2 utf8 encoder.

I don't have a strong opinion. But if I have to choose, I would say that surrogateescape should not go to Python2. It's a solution to problem specific to Python3.

(... and surrogates introduces a lot of new issues ...)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:21:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 18:21:41 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271614901.23.0.143265863856.issue8420@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

>Bugs in set_repr:
>> keys = PySequence_List((PyObject *)so);
>> if (keys == NULL)
>> 	goto done;
>> 
>> listrepr = PyObject_Repr(keys);
>> Py_DECREF(keys);
>List pointed to by keys is already deallocated at this point.
>> if (listrepr == NULL) {
>> 	Py_DECREF(keys);
>>But this code tries to DECREF it.
>> 	goto done;
>> }

I don't follow why you think keys is already deallocated.
When assigned by PySequence_List() without a NULL return, the refcnt is one. The call to PyObject_Repr(keys) does not change the refcnt of keys,
so the Py_DECREF(keys) is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:26:42 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 18 Apr 2010 18:26:42 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1271615202.89.0.67146866773.issue5099@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Let's try this again...

----------
Added file: http://bugs.python.org/file16976/subprocess__del__.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:32:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 18 Apr 2010 18:32:53 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1271615573.72.0.243748736987.issue2090@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the patch, George. I will get it when I can.

And this make me even more glad that we removed the file path import from 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:32:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 18:32:56 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271615576.3.0.432562271088.issue8438@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch fixing Windows compatibility.

----------
Added file: http://bugs.python.org/file16977/surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:33:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 18:33:15 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271615595.01.0.224374102504.issue8438@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16975/surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:43:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 18:43:12 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1271616192.42.0.691522520621.issue8426@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Sun Apr 18 20:55:23 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 18 Apr 2010 18:55:23 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1271616923.68.0.44197435303.issue6095@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

Since I last submitted this patch, my leet C skills have improved.

I'm submitting another patch, without the needless PyUnicode creation this time. (Moreover, I think the previous patch was wrong to insert code before variable declaration of the block)

----------
Added file: http://bugs.python.org/file16978/t6095_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:09:28 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:09:28 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1271617768.28.0.880590418617.issue8366@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This should now be fixed:

* r80187 (trunk)
* r80188 (2.6)
* r80191 (3.2)
* r80192 (3.1)

The fix is not ideal, there's still two '-isysroot' flags in the compiler command-line, but at least everything compiles and works again.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:09:46 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:09:46 +0000
Subject: [issue8366] OS X universal builds fail on 2.7b1 and py3k with "Don't
	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1271617786.46.0.253554326263.issue8366@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8366>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:11:02 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sun, 18 Apr 2010 19:11:02 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271617862.83.0.606876629857.issue8420@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

> > One solution is to check that so->mask didn't 
> > change as well. 
> 
> I saw that and agree it would make a tighter check, but haven't convinced myself that it is necessary.

Without this check, it is possible that the comparison shrinks the table, so entry becomes out of bounds. However, if both so->table and so->mask didn't change then entry is still a pointer to one of table elements so it can be used safely.

> > Also, checking that refcnt > 1 is redundant 
> > because if entry->key == startkey then there 
> > are at least two references: one from entry->key 
> > and another from startkey.
> 
> It is a meaningful check.  We have our own INCREF
> and one for the key being in the table.  If the
> count is 1, then it means that the comparison
> check deleted the key from the table or replaced
> its value (see issue 1517).

If the comparison deleted or changed the key then the check entry->key == startkey would fail so refcnt check won't be reached. Checking refcounts is also bad because someone else may have references to the key.

> I don't follow why you think keys is already deallocated.
> When assigned by PySequence_List() without a NULL return, the refcnt is one. The call to PyObject_Repr(keys) does not change the refcnt of keys,
> so the Py_DECREF(keys) is correct.
Look at the code again. If listrepr happens to be NULL, you do Py_DECREF(keys) twice (this bug is only present in py3k branch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:14:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:14:40 +0000
Subject: [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: <1271618080.49.0.29552452878.issue8175@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Applied as r80193, thanks for looking into this.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8175>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:19:07 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:19:07 +0000
Subject: [issue7958] test_platform failure on OS X 10.6
In-Reply-To: <1266506997.43.0.181933833727.issue7958@psf.upfronthosting.co.za>
Message-ID: <1271618347.88.0.337603031966.issue7958@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm closing this issue because a patch simular to the attached patch was applied in r78835 and the issue therefore fixed.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7958>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:19:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 19:19:46 +0000
Subject: [issue8439] test_linecache failing in py3k r80169
In-Reply-To: <4BCADCEA.2060609@timgolden.me.uk>
Message-ID: <1271618386.09.0.0926652311457.issue8439@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed in r80194 / r80195.

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8439>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:22:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 19:22:05 +0000
Subject: [issue8439] test_linecache failing in py3k r80169
In-Reply-To: <4BCADCEA.2060609@timgolden.me.uk>
Message-ID: <1271618525.81.0.665894344497.issue8439@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8439>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:22:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 19:22:16 +0000
Subject: [issue8439] test_linecache failing in py3k r80169
In-Reply-To: <4BCADCEA.2060609@timgolden.me.uk>
Message-ID: <1271618536.74.0.873051350419.issue8439@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8439>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:22:29 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:22:29 +0000
Subject: [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: <1271618549.94.0.932786237881.issue8126@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This issue should be fixed in the repository for both python 3.1 and 3.2, could you please test this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8126>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:31:27 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:31:27 +0000
Subject: [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: <1271619087.72.0.430768536229.issue8095@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: I've attached a new patch, could you please test this one on an 10.3 box?

It turns out that testing if a weaklinked variable is defined should be done by testing the address of the variable, not its value.

I've tested this new approach with a symbol that is defined on 10.6 but not 10.5, but cannot test on 10.3.

----------
Added file: http://bugs.python.org/file16979/issue8095.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8095>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:33:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:33:43 +0000
Subject: [issue8001] os.stat on osx 10.5 or later doesn't expose all fields in
	struct stat
In-Reply-To: <1266938388.51.0.563048474529.issue8001@psf.upfronthosting.co.za>
Message-ID: <1271619223.15.0.0713141306718.issue8001@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixing this requires duplicating a significant amount of code in posixmodule.c and is imho not worth the effort.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8001>
_______________________________________

From report at bugs.python.org  Sun Apr 18 21:36:24 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 19:36:24 +0000
Subject: [issue8002] on OSX the file creation date not available in os.stat
In-Reply-To: <1266938492.4.0.0671883953878.issue8002@psf.upfronthosting.co.za>
Message-ID: <1271619384.37.0.417067141731.issue8002@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm closing this issue as won't fix.

The additional fields are available if you build from source and target 10.5 or later (set 'MACOSX_DEPLOYMENT_TARGET=10.5' when you run configure).

My current plan is to have two installers for python 2.7 and 3.2: one is a 32-bit only version that runs on OSX 10.3 or later and one will be be a new version that supports 64-bit x86 code as well and requires OSX 10.5. This new installer won't suffer from this issue.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8002>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:30:31 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 20:30:31 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271622631.5.0.914393631452.issue8420@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed set_repr() issue in r80197 and r80196.  Looks like someone futzed the unicode updates for 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:40:46 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 18 Apr 2010 20:40:46 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271623246.19.0.887018383428.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Martin, I?ve explained it in my other dissue, issue 8411, with a step by step example.
It is unfair because a thread can _bypass_ the condition variable.  A thread just woken up from the condition variable has to race to get the lock, and it is a race that it will invariably loose if the other thread is doing a release/acquire (yielding the GIL as happens in ceval.py)  The ConditionVariable can only endow the lock with its fairness property if all the threads play by the same rules.

This was a design decision made by Tim (according to the comment) but a misguided one.  It is a good stragegy for resources that are held for a short time to avoid lock convoying, but not appropriate in this case.

You also don't have to take my word for it.  Just try it out.  Notice that 99% of all yields between threads fail, causing starvation of a thread which is the definition of "unfairness."

Anyway, this is the last time I explain why the "emulated" semaphore is unfair.  I think I?ve done so on at least four or five different occasions and it would be helpful if people would actually bother to read my comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:44:10 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 20:44:10 +0000
Subject: [issue8444] openssl version detection doesn't work properly when
	using OSX SDK
In-Reply-To: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>
Message-ID: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

setup.py detects the version of openssl by looking for openssl headers on a deduced search path. That path is not guaranteed to be equal to the real compiler search path, in particular not when building using the OSX 10.4 SDK on MacOSX 10.6: in that situation the compiler will use a header file with the following definition:

#define OPENSSL_VERSION_NUMBER  0x009070cfL

While setup.py reads the header file in /usr/include which contains this definition:

#define OPENSSL_VERSION_NUMBER  0x009080cfL

The actual version is below the sha256 cutoff in setup.py, while setup.py detects a newer version that is above that cutoff. That results in a tree where setup.py tries to build _sha256 using OpenSSL, but fails. That in turn results in a build of hashlib that doesn't work.


Note that this is a specific instance of Issue7724, but fixing this particular issue is probably easier than fixing the generic issue.

----------
assignee: tarek
components: Build, Distutils
messages: 103526
nosy: ronaldoussoren, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: openssl version detection doesn't work properly when using OSX SDK
type: compile error
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8444>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:50:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 20:50:33 +0000
Subject: [issue7154] urllib.request system proxy configuration lookup broken
	for OS X in Python 3
In-Reply-To: <1255733208.5.0.407244004895.issue7154@psf.upfronthosting.co.za>
Message-ID: <1271623833.29.0.280272972103.issue7154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed a port of _scproxies and the related code in urllib in r80198 (3.2), r80199 (3.1)

BTW. With some luck this should already include a fix for the crash your seeing on OSX 10.3 with the trunk and 2.6.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7154>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:50:44 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 20:50:44 +0000
Subject: [issue7154] urllib.request system proxy configuration lookup broken
	for OS X in Python 3
In-Reply-To: <1255733208.5.0.407244004895.issue7154@psf.upfronthosting.co.za>
Message-ID: <1271623844.2.0.849760425387.issue7154@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7154>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:51:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 20:51:54 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1271623914.63.0.972032892958.issue7580@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've fixed this issue in the repository earlier today, the installer for the next 3.1 release will include that fix.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:52:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 20:52:09 +0000
Subject: [issue8444] openssl version detection doesn't work properly when
	using OSX SDK
In-Reply-To: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>
Message-ID: <1271623929.07.0.846290198562.issue8444@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

On recent trunk and py3k you can get the real version number:
http://docs.python.org/dev/library/ssl.html#ssl.OPENSSL_VERSION

So perhaps you can first build the _ssl module, then import it to get that information.
Of course it would be much better to build against the proper headers.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8444>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:55:16 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 20:55:16 +0000
Subject: [issue5652] OS X Installer: remove references to Mac/Tools which no
	longer exists
In-Reply-To: <1238603386.16.0.0582109660822.issue5652@psf.upfronthosting.co.za>
Message-ID: <1271624116.85.0.437047775877.issue5652@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fix in r80201 (3.1) and r80200 (3.2). The fix is already in 2.6 and the trunk.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5652>
_______________________________________

From report at bugs.python.org  Sun Apr 18 22:57:00 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 20:57:00 +0000
Subject: [issue8381] IDLE 2.6 freezes on OS X 10.6
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271624220.91.0.889965450331.issue8381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Aaron: How did you install python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Sun Apr 18 23:04:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 21:04:47 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271624687.12.0.900431448361.issue8410@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

W.r.t. "This appears to be the case on Mac OS X": OSX 10.4 and later seem to support posix semaphores, the program below prints "yes":

#include <unistd.h>

int main()
{
#ifdef _POSIX_SEMAPHORES
        printf("yes\n");
#else
        printf("no\n");
#endif
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Sun Apr 18 23:18:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Apr 2010 21:18:39 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1271623246.19.0.887018383428.issue8299@psf.upfronthosting.co.za>
Message-ID: <4BCB772C.7050307@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, I?ve explained it in my other dissue, issue 8411, with a step by step example.

Hmm. Can't find it there. What message or file should I be looking at?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Sun Apr 18 23:29:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 21:29:12 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86 Tiger trunk/builds/15/steps/test/logs/stdio

test test_ttk_guionly failed -- multiple errors occurred; run in verbose mode for details
Re-running test 'test_ttk_guionly' in verbose mode
test_horizontal_range (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_initialization (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_resize (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_variable_change (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_widget_destroy (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_initialization (test_ttk.test_extensions.OptionMenuTest) ... ok
test_menu (test_ttk.test_extensions.OptionMenuTest) ... ok
test_widget_destroy (test_ttk.test_extensions.OptionMenuTest) ... ok
test_configure (test_ttk.test_style.StyleTest) ... ok
test_layout (test_ttk.test_style.StyleTest) ... ok
test_lookup (test_ttk.test_style.StyleTest) ... ok
test_map (test_ttk.test_style.StyleTest) ... ok
test_theme_use (test_ttk.test_style.StyleTest) ... ok
test_identify (test_ttk.test_widgets.WidgetTest) ... FAIL
test_widget_state (test_ttk.test_widgets.WidgetTest) ... ok
test_invoke (test_ttk.test_widgets.ButtonTest) ... ok
test_invoke (test_ttk.test_widgets.CheckbuttonTest) ... ok
test_invoke (test_ttk.test_widgets.RadiobuttonTest) ... ok
test_postcommand (test_ttk.test_widgets.ComboboxTest) ... ok
test_values (test_ttk.test_widgets.ComboboxTest) ... ok
test_virtual_event (test_ttk.test_widgets.ComboboxTest) ... ok
test_bbox (test_ttk.test_widgets.EntryTest) ... ok
test_identify (test_ttk.test_widgets.EntryTest) ... ok
test_revalidation (test_ttk.test_widgets.EntryTest) ... ok
test_validation (test_ttk.test_widgets.EntryTest) ... ok
test_validation_options (test_ttk.test_widgets.EntryTest) ... ok
test_add (test_ttk.test_widgets.PanedwindowTest) ... ok
test_forget (test_ttk.test_widgets.PanedwindowTest) ... ok
test_insert (test_ttk.test_widgets.PanedwindowTest) ... ok
test_pane (test_ttk.test_widgets.PanedwindowTest) ... ok
test_sashpos (test_ttk.test_widgets.PanedwindowTest) ... ok
test_custom_event (test_ttk.test_widgets.ScaleTest) ... ok
test_get (test_ttk.test_widgets.ScaleTest) ... ok
test_set (test_ttk.test_widgets.ScaleTest) ... ok
test_add_and_hidden (test_ttk.test_widgets.NotebookTest) ... ok
test_forget (test_ttk.test_widgets.NotebookTest) ... ok
test_index (test_ttk.test_widgets.NotebookTest) ... ok
test_insert (test_ttk.test_widgets.NotebookTest) ... ok
test_select (test_ttk.test_widgets.NotebookTest) ... ok
test_tab (test_ttk.test_widgets.NotebookTest) ... ok
test_tab_identifiers (test_ttk.test_widgets.NotebookTest) ... ERROR
test_tabs (test_ttk.test_widgets.NotebookTest) ... ok
test_traversal (test_ttk.test_widgets.NotebookTest) ... FAIL
test_bbox (test_ttk.test_widgets.TreeviewTest) ... ok
test_children (test_ttk.test_widgets.TreeviewTest) ... ok
test_column (test_ttk.test_widgets.TreeviewTest) ... ok
test_delete (test_ttk.test_widgets.TreeviewTest) ... ok
test_detach_reattach (test_ttk.test_widgets.TreeviewTest) ... ok
test_exists (test_ttk.test_widgets.TreeviewTest) ... ok
test_focus (test_ttk.test_widgets.TreeviewTest) ... ok
test_heading (test_ttk.test_widgets.TreeviewTest) ... ok
test_heading_callback (test_ttk.test_widgets.TreeviewTest) ... FAIL
test_index (test_ttk.test_widgets.TreeviewTest) ... ok
test_insert_item (test_ttk.test_widgets.TreeviewTest) ... ok
test_set (test_ttk.test_widgets.TreeviewTest) ... ok
test_tag_bind (test_ttk.test_widgets.TreeviewTest) ... ok
test_tag_configure (test_ttk.test_widgets.TreeviewTest) ... ok

======================================================================
ERROR: test_tab_identifiers (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 560, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/ttk.py", line 318, in _val_or_dict
    res = func(*(args + options))
TclError: tab '@5,5' not found

======================================================================
FAIL: test_identify (test_ttk.test_widgets.WidgetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 27, in test_identify
    self.assertEqual(self.widget.identify(5, 5), "label")
AssertionError: 'Button.button' != 'label'

======================================================================
FAIL: test_traversal (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 721, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.33941048' != '.33942584'

======================================================================
FAIL: test_heading_callback (test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 941, in test_heading_callback
    self.fail("The command associated to the treeview heading wasn't "
AssertionError: The command associated to the treeview heading wasn't invoked.

----------------------------------------------------------------------
Ran 57 tests in 0.361s

----------
keywords: buildbot
messages: 103534
nosy: haypo
severity: normal
status: open
title: buildbot: test_ttk_guionly failures
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sun Apr 18 23:58:25 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 21:58:25 +0000
Subject: [issue8435] It is possible to observe a mutating frozenset
In-Reply-To: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>
Message-ID: <1271627905.27.0.465038931328.issue8435@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks ggeal.  Closing as won't fix.  The code is functioning as designed and documented.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8435>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:01:18 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 18 Apr 2010 22:01:18 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271628078.03.0.152344777219.issue8410@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Is it possible that unistd.h isn't included by Python on mac builds? perhaps the config script is broken and HAVE_UNISTD_H doesn't get defined.  I'll have a look at the generated pyconfig.h file on my colleague's machine tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:03:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:03:29 +0000
Subject: [issue6661] Transient test_multiprocessing failure
	(test_active_children)
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1271628209.67.0.81978904019.issue6661@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Transient test_multiprocessing failure -> Transient test_multiprocessing failure (test_active_children)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:03:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:03:37 +0000
Subject: [issue5930] Transient error in multiprocessing
	(test_number_of_objects)
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1271628217.87.0.9609098156.issue5930@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Transient error in multiprocessing -> Transient error in multiprocessing (test_number_of_objects)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5930>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:12:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:12:37 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86 Tiger trunk/builds/15/steps/test/logs/stdio

test_py3kwarn
test test_py3kwarn failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 387, in test_platform_specific_removals
    self.check_removal(module_name, optional=True)
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 376, in check_removal
    .format(module_name))
AssertionError: DeprecationWarning not raised for icglue

Re-running test 'test_py3kwarn' in verbose mode
test_backquote (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_buffer (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_builtin_function_or_method_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_cell_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_code_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_dict_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_file_xreadlines (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_forbidden_names (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_frame_attributes (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_hash_inheritance (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_methods_members (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_object_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_operator (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_paren_arg_names (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_slice_methods (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_softspace (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_sort_cmp_arg (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_sys_exc_clear (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_tuple_parameter_unpacking (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_type_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_mutablestring_removal (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_optional_module_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_os_path_walk (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_platform_independent_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_platform_specific_removals (test.test_py3kwarn.TestStdlibRemovals) ... FAIL
test_reduce_move (test.test_py3kwarn.TestStdlibRemovals) ... ok

======================================================================
FAIL: test_platform_specific_removals (test.test_py3kwarn.TestStdlibRemovals)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 387, in test_platform_specific_removals
    self.check_removal(module_name, optional=True)
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 376, in check_removal
    .format(module_name))
AssertionError: DeprecationWarning not raised for icglue

----------------------------------------------------------------------

----------
keywords: buildbot
messages: 103537
nosy: haypo
severity: normal
status: open
title: buildbot: DeprecationWarning not raised for icglue (test_py3kwarn.TestStdlibRemovals)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:17:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:17:51 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1271629071.32.0.47359656589.issue8445@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://www.python.org/dev/buildbot/builders/x86 FreeBSD 3.1/builds/149/steps/test/logs/stdio

======================================================================
FAIL: test_traversal (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.1.bolen-freebsd/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 708, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.219316556' != '.219317508'

----------------------------------------------------------------------
Ran 57 tests in 13.798s

FAILED (failures=1)
test test_ttk_guionly failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.1.bolen-freebsd/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 708, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.219316556' != '.219317508'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:19:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:19:23 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1271629163.49.0.141332285726.issue8445@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:20:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:20:48 +0000
Subject: [issue3771] test_httpservers intermittent failure, test_post and EINTR
In-Reply-To: <1220489239.6.0.433848845577.issue3771@psf.upfronthosting.co.za>
Message-ID: <1271629248.96.0.953713647479.issue3771@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_httpservers intermittent failure -> test_httpservers intermittent failure, test_post and EINTR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3771>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:23:03 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 18 Apr 2010 22:23:03 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>
Message-ID: <1271629383.65.0.667015944678.issue8191@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

attached is a search for execlp for all files found in Ubuntu lucid, there's one package which uses just one argument to execlp.

----------
Added file: http://bugs.python.org/file16980/execlp.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:23:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:23:09 +0000
Subject: [issue8447] buildbot: test_httpservers failure (No module named
	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86 Tiger 3.1/builds/16/steps/test/logs/stdio

test_httpservers
[28139 refs]
[28139 refs]
[28139 refs]
Traceback (most recent call last):
  File "/private/tmp/tmpqYIZuO/cgi-bin/file2.py", line 2, in <module>
    import cgi
  File "/Users/db3l/buildarea/3.1.bolen-tiger/build/Lib/cgi.py", line 34, in <module>
    from operator import attrgetter
ImportError: No module named operator
[28142 refs]
Warning: os.environ was modified by test_httpservers
test test_httpservers failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.1.bolen-tiger/build/Lib/test/test_httpservers.py", line 380, in test_post
    self.assertEquals(res.read(), b'1, python, 123456\n')
AssertionError: b'' != b'1, python, 123456\n'

----------
keywords: buildbot
messages: 103540
nosy: haypo
severity: normal
status: open
title: buildbot: test_httpservers failure (No module named operator)
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8447>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:25:48 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sun, 18 Apr 2010 22:25:48 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271629548.81.0.0198053721014.issue8420@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

This code crashes python by using another bug in set_repr. This only affects py3k. This code relies on out-of-memory condition, so run it like:
$ (ulimit -v 65536 && python3 test.py)
Otherwise, it will eat all your free memory before crashing.

val = "a" * 10000
class big:
	def __repr__(self):
		return val
i = 16
while True:
	repr(frozenset(big() for j in range(i)))
	i = (i * 5) >> 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:27:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:27:58 +0000
Subject: [issue8448] buildbot: test_subprocess failure (test_no_leaking,
	Broken pipe)
In-Reply-To: <1271629678.61.0.824360658357.issue8448@psf.upfronthosting.co.za>
Message-ID: <1271629678.61.0.824360658357.issue8448@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/sparc Debian 3.1/builds/49/steps/test/logs/stdio

test_subprocess
* ob
object  : <refcnt 0 at 0x1038220>
type    : str
refcount: 0
address : 0x1038220
* op->_ob_prev->_ob_next
object  : <refcnt 0 at 0x1038220>
type    : str
refcount: 0
address : 0x1038220
* op->_ob_next->_ob_prev
object  : [29082 refs]
.
    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 ...
test test_subprocess failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/test/test_subprocess.py", line 459, in test_no_leaking
    data = p.communicate(b"lime")[0]
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/subprocess.py", line 727, in communicate
    return self._communicate(input)
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/subprocess.py", line 1203, in _communicate
    stdout, stderr = self._communicate_with_poll(input)
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/subprocess.py", line 1269, in _communicate_with_poll
    input_offset += os.write(fd, chunk)
OSError: [Errno 32] Broken pipe

----------
keywords: buildbot
messages: 103542
nosy: haypo
severity: normal
status: open
title: buildbot: test_subprocess failure (test_no_leaking, Broken pipe)
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8448>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:28:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 22:28:26 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271629706.3.0.337465908813.issue8420@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Patch please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:30:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Apr 2010 22:30:41 +0000
Subject: [issue8447] buildbot: test_httpservers failure (No module named
	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1271629841.43.0.8814880855.issue8447@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8447>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:33:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:33:00 +0000
Subject: [issue5930] Transient error in multiprocessing
	(test_number_of_objects)
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1271629980.31.0.211535096405.issue5930@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5930>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:33:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:33:06 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI with soft floating
	point
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1271629986.21.0.95658474036.issue8265@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:38:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:38:28 +0000
Subject: [issue8447] buildbot: test_httpservers failure (No module named
	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1271630308.87.0.0355101620816.issue8447@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Library (Lib), Tests -Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8447>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:45:31 2010
From: report at bugs.python.org (mschu)
Date: Sun, 18 Apr 2010 22:45:31 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>


New submission from mschu <mschu.dev at gmail.com>:

Independent from HTTP strict, an invalid BadStatusLine() exception is raised when a keep-alive connection exceeds its timeout:

client->server <request>
s->c <answer>
<connection timeout passing>
s->c: FIN/ACK
c->s: ACK
c->s: <get request>/FIN
s->c: RST (without data)

which raises the exception.

An easy workaround is to either poll information often enough for the server to not close the connection or close and reopen the connection. However, the exception is misleading.

----------
components: Library (Lib)
messages: 103545
nosy: mschu
severity: normal
status: open
title: httplib: false BadStatusLine() raised
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8450>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:46:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:46:40 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1271630800.04.0.536228822461.issue8446@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Mac/Modules/icgluemodule.c has a call to PyErr_WarnPy3k

if (PyErr_WarnPy3k("In 3.x, the icglue module is removed.", 1))
   return;

Other modules check if the result is smaller than 0, but PyErr_WarnPy3k() possible results are only 0 or -1, so I don't understand the error.

----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Mon Apr 19 00:47:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:47:29 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1271630849.34.0.915667733047.issue8445@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Tests, Tkinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From roundup-admin at psf.upfronthosting.co.za  Mon Apr 19 00:30:17 2010
From: roundup-admin at psf.upfronthosting.co.za (roundup-admin at psf.upfronthosting.co.za)
Date: Mon, 19 Apr 2010 00:30:17 +0200 (CEST)
Subject: [issue8449] buildbot: test_dbm and test_dbm_ndbm
Message-ID: <20100418223017.7EA3678207@psf.upfronthosting.co.za>

failures
To: python-bugs-list at python.org
From: STINNER Victor <report at bugs.python.org>
Date: Sun, 18 Apr 2010 22:30:17 +0000
Precedence: bulk
X-Roundup-Name: Python tracker
X-Roundup-Loop: hello
X-Roundup-Version: 1.4.10
Reply-To: Python tracker <report at bugs.python.org>
Message-Id: <1271629817.22.0.668476357491.issue8449 at psf.upfronthosting.co.za>
In-Reply-To: <1271629817.22.0.668476357491.issue8449 at psf.upfronthosting.co.za>
X-Roundup-issue-status: open
X-Roundup-issue-keywords: buildbot
X-Roundup-issue-severity: normal
X-Roundup-issue-versions: Python 3.1
Content-Transfer-Encoding: quoted-printable


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/ia64 Ubuntu 3.1/builds/451/step=
s/test/logs/stdio

test_dbm
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
test test_dbm failed -- multiple errors occurred; run in verbose mode for d=
etails

test_dbm_ndbm
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
test test_dbm_ndbm failed -- multiple errors occurred; run in verbose mode =
for details

Re-running test 'test_dbm' in verbose mode
test_keys (test.test_dbm.WhichDBTestCase) ... ok
test_whichdb (test.test_dbm.WhichDBTestCase) ... __fop_file_setup:  Retry l=
imit (100) exceeded
ERROR
test_anydbm_access (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup: =
 Retry limit (100) exceeded
ERROR
test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup=
:  Retry limit (100) exceeded
ERROR
test_anydbm_keys (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup:  R=
etry limit (100) exceeded
ERROR
test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_s=
etup:  Retry limit (100) exceeded
ERROR
test_anydbm_not_existing (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup:  R=
etry limit (100) exceeded
ERROR
test_error (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_access (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_creation (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_keys (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_modification (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_not_existing (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_read (test.test_dbm.TestCase-dbm.dumb) ... ok
test_error (test.test_dbm.TestCase-dbm.dumb) ... ok

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_whichdb (test.test_dbm.WhichDBTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 127, in test_whichdb
    f =3D module.open(_fname, 'c')
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_access (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 93, in test_anydbm_access
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 66, in test_anydbm_creation
    f =3D dbm.open(_fname, 'c')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_keys (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 87, in test_anydbm_keys
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 74, in test_anydbm_modification
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 81, in test_anydbm_read
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

----------------------------------------------------------------------
Ran 16 tests in 602.508s

FAILED (errors=3D6)
test test_dbm failed -- multiple errors occurred
Re-running test 'test_dbm_ndbm' in verbose mode
test_keys (test.test_dbm_ndbm.DbmTestCase) ... __fop_file_setup:  Retry lim=
it (100) exceeded
ERROR
test_modes (test.test_dbm_ndbm.DbmTestCase) ... __fop_file_setup:  Retry li=
mit (100) exceeded
ERROR

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_keys (test.test_dbm_ndbm.DbmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
_ndbm.py", line 13, in setUp
    self.d =3D dbm.ndbm.open(self.filename, 'c')
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_modes (test.test_dbm_ndbm.DbmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
_ndbm.py", line 13, in setUp
    self.d =3D dbm.ndbm.open(self.filename, 'c')
_dbm.error: [Errno 17] File exists

----------------------------------------------------------------------
Ran 2 tests in 200.800s

FAILED (errors=3D2)
test test_dbm_ndbm failed -- multiple errors occurred

----------
keywords: buildbot
messages: 103544
nosy: haypo
severity: normal
status: open
title:=20
  buildbot: test_dbm and test_dbm_ndbm
  failures
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8449>
_______________________________________

From report at bugs.python.org  Mon Apr 19 01:04:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 23:04:49 +0000
Subject: [issue8448] buildbot: test_subprocess failure (test_no_leaking,
	Broken pipe)
In-Reply-To: <1271629678.61.0.824360658357.issue8448@psf.upfronthosting.co.za>
Message-ID: <1271631889.77.0.962457280797.issue8448@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"op->_ob_prev->_ob_next" comes from _Py_ForgetReference() compiled in pydebug mode and it should ends with "UNREF invalid object" but it looks like _PyObject_Dump(op->_ob_next->_ob_prev); crashed. Anyway, something gone wrong here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8448>
_______________________________________

From report at bugs.python.org  Mon Apr 19 01:05:22 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Apr 2010 23:05:22 +0000
Subject: [issue8436] set.__init__ accepts keyword args
In-Reply-To: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>
Message-ID: <1271631922.91.0.555461803055.issue8436@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r80202, r80203, r80204, and r80205

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8436>
_______________________________________

From report at bugs.python.org  Mon Apr 19 01:12:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 23:12:35 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1271632355.49.0.665847027342.issue8445@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: buildbot: test_ttk_guionly failures -> buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Mon Apr 19 01:16:19 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sun, 18 Apr 2010 23:16:19 +0000
Subject: [issue8420] Objects/setobject.c contains unsafe code
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271632579.77.0.28058936621.issue8420@psf.upfronthosting.co.za>


Changes by Eugene Kapun <abacabadabacaba at gmail.com>:


Added file: http://bugs.python.org/file16981/repr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8420>
_______________________________________

From report at bugs.python.org  Mon Apr 19 01:27:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 23:27:35 +0000
Subject: [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: <1271633255.99.0.119920020169.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +tarfile: use surrogates for undecode fields

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Mon Apr 19 01:29:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 23:29:51 +0000
Subject: [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: <1271633391.72.0.212019231412.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited the platform.py patch as r80166 (trunk) and r80167 (py3k), but quickly reverted it because the patch on trunk broke Python bootstrap. The patch might be applied, but only on py3k and with more tests (ensure that it doesn't break bootstrap on any OS) :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Mon Apr 19 02:42:35 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Apr 2010 00:42:35 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1271637755.04.0.817040175042.issue6095@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Mon Apr 19 03:59:06 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 19 Apr 2010 01:59:06 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271642346.65.0.693982607664.issue8299@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Here are the results of running the fair.py test on a Mac OS-X system using a "fair" GIL implementation (modified condition variable):

[ Fair GIL, Dual-Core, OS-X ]
Sequential execution
slow: 5.490943 (0 left)
fast: 0.369257 (0 left)
Threaded execution
slow: 6.122093 (0 left)
fast: 6.179179 (0 left)
Treaded, balanced execution:
fast C: 3.345452 (0 left)
fast B: 3.389235 (0 left)
fast A: 3.426407 (0 left)
Treaded, balanced execution, with quickstop:
fast C: 2.557972 (0 left)
fast B: 2.558551 (35087 left)
fast A: 2.558914 (13142 left)

Here is the same test with the original GIL.

[Unfair GIL, original implementation]

Sequential execution
slow: 5.444754 (0 left)
fast: 0.361340 (0 left)
Threaded execution
slow: 5.542008 (0 left)
fast: 5.225690 (0 left)
Treaded, balanced execution:
fast C: 1.381929 (0 left)
fast B: 1.499969 (0 left)
fast A: 1.549571 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 1.284043 (0 left)
fast B: 1.295507 (32490 left)
fast C: 1.294981 (274777 left)

Please observe that the performance of threads under the "fair" GIL are significantly worse than with the "unfair" GIL.

Having studied this in more depth, I have to say that I would much rather have fast-running unfair threads than slow-running fair threads.  Although I agree that there are other benefits to fairness, they just aren't enough to compensate for the huge performance hit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Mon Apr 19 06:20:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Apr 2010 04:20:05 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1271650805.77.0.668645308727.issue8425@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Raymond, have you forgotten to attach the patch or have you just set the stage to 'patch review' by mistake?

----------
nosy: +ezio.melotti
priority:  -> normal
stage: patch review -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Mon Apr 19 07:08:30 2010
From: report at bugs.python.org (H Krishnan)
Date: Mon, 19 Apr 2010 05:08:30 +0000
Subject: [issue8415] namedtuple vs tuple
In-Reply-To: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>
Message-ID: <1271653710.82.0.966161166377.issue8415@psf.upfronthosting.co.za>


H Krishnan <hetchkay at gmail.com> added the comment:

Sorry, I didn't know about "python-ideas".
Actually, there is a way to do this without breaking any existing code.

namedtuple could support an optional additional argument, say, useIterableCtr, which is by default False, and the class template could be appropriately modified based on this argument.

I couldn't find the PEP for this, but I notice that other people have also suggested iterable as argument in the ActiveState recipe page for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8415>
_______________________________________

From report at bugs.python.org  Mon Apr 19 07:14:13 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Apr 2010 05:14:13 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1271654053.67.0.214579546814.issue8425@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Mon Apr 19 07:15:33 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Apr 2010 05:15:33 +0000
Subject: [issue8415] namedtuple vs tuple
In-Reply-To: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>
Message-ID: <1271654133.62.0.54950999228.issue8415@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

We don't do flags either :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8415>
_______________________________________

From report at bugs.python.org  Mon Apr 19 07:26:40 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 19 Apr 2010 05:26:40 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>


New submission from Sean Reifschneider <jafo at tummy.com>:

As discussed in this thread:

http://mail.python.org/pipermail/python-dev/2010-March/098500.html

The syslog module is using the C argv[0] as the program name, not the python sys.argv[0].  So, in most cases this means that unless you explicitly set a ident, you get "python" as the ident.  Not entirely helpful.

This patch:

 - Makes openlog arguments keyword args.
 - Makes openlog ident argument optional.
 - If ident is not passed to ident, basename(sys.argv[0]) is used.
 - The first call to syslog.syslog() calls ident() with no options
   (if it hasn't previously been called).
 - Variously related documentation changes.

"make test" with this succeeds.

I think this is ready to go into the trunk, but would like a review.  I'll check with the release maintainer about if this is appropriate for 2.7b.

Sean

----------
components: Library (Lib)
keywords: easy, needs review, patch
messages: 103555
nosy: jafo
priority: normal
severity: normal
stage: patch review
status: open
title: syslog.syslog('msg') logs message with ident "python".
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Mon Apr 19 07:27:43 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 19 Apr 2010 05:27:43 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271654863.44.0.79545626394.issue8451@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Added file: http://bugs.python.org/file16982/syslog-kwargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Mon Apr 19 07:30:36 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 19 Apr 2010 05:30:36 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271655036.27.0.678007328288.issue8451@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Mon Apr 19 08:30:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 19 Apr 2010 06:30:34 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The current build_installer fails to build dependencies, e.g. with

gcc-4.0 -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -o bzip2 bzip2.o -L. -lbz2
collect2: cannot find 'ld'
collect2: cannot find 'ld'
lipo: can't open input file: /var/tmp//cc8o5UUU.out (No such file or directory)

For the full buildlog, see

http://www.python.org/dev/buildbot/builders/2.7.dmg/builds/9/steps/compile/logs/stdio

----------
assignee: ronaldoussoren
messages: 103557
nosy: loewis, ronaldoussoren
severity: normal
status: open
title: build_installer.py breaks bzip compilation
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Mon Apr 19 08:59:49 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 19 Apr 2010 06:59:49 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271660389.69.0.0134179605783.issue8451@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Added file: http://bugs.python.org/file16983/syslog-kwargs2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Mon Apr 19 09:08:54 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Mon, 19 Apr 2010 07:08:54 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1271660934.34.0.0472123522237.issue6095@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

Here's another one. I hadn't realized that it was useless to target the 2.x codebase. So I re-worked this on py3k. The change is non-trivial, since the non-windows/non-os2 part of the code has significantly changed in 3k. This time, since "oname" is released later and used in error conditions, I thought it was worth it to allocate a new PyBytes for the default value.

I also modified the documentation so that it tells about path's default value.

----------
Added file: http://bugs.python.org/file16984/t6095_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From roundup-admin at psf.upfronthosting.co.za  Mon Apr 19 01:17:46 2010
From: roundup-admin at psf.upfronthosting.co.za (roundup-admin at psf.upfronthosting.co.za)
Date: Mon, 19 Apr 2010 01:17:46 +0200 (CEST)
Subject: [issue8449] buildbot: test_dbm and test_dbm_ndbm
Message-ID: <20100418231746.53EF3781BC@psf.upfronthosting.co.za>

failures
To: python-bugs-list at python.org
From: STINNER Victor <report at bugs.python.org>
Date: Sun, 18 Apr 2010 23:17:46 +0000
Precedence: bulk
X-Roundup-Name: Python tracker
X-Roundup-Loop: hello
X-Roundup-Version: 1.4.10
Reply-To: Python tracker <report at bugs.python.org>
Message-Id: <1271632666.33.0.388840040556.issue8449 at psf.upfronthosting.co.za>
X-Roundup-issue-status: open
X-Roundup-issue-keywords: buildbot
X-Roundup-issue-severity: normal
X-Roundup-issue-versions: Python 3.1
In-Reply-To: <1271629817.22.0.668476357491.issue8449 at psf.upfronthosting.co.za>
Content-Transfer-Encoding: quoted-printable


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The tests delete generated files before and after the test using support.un=
link(). This function calls os.unlink() but ignores OSError.

I guess that the tests are unable to delete the file for an unknown reason,=
 and so the tests fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8449>
_______________________________________

From report at bugs.python.org  Mon Apr 19 10:15:56 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Apr 2010 08:15:56 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271664956.55.0.683931570897.issue8393@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It does not work on Windows:

>>> subprocess.Popen("c:/windows/notepad.exe", cwd=b'c:/temp')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\afa\python\py3k-1\lib\subprocess.py", line 681, in __init__
    restore_signals, start_new_session)
  File "D:\afa\python\py3k-1\lib\subprocess.py", line 892, in _execute_child
    startupinfo)
TypeError: must be string or None, not bytes

The function sp_CreateProcess() in PC/_subprocess.c should probably be fixed.
And please add unit tests...

----------
nosy: +amaury.forgeotdarc
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Mon Apr 19 10:43:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Apr 2010 08:43:19 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1271666599.6.0.433513117162.issue5650@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The 'See also' in the documentation should also be updated:
http://docs.python.org/dev/library/urlparse.html#urlparse.urldefrag

----------
nosy: +ezio.melotti
priority:  -> normal
status: closed -> open
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Mon Apr 19 10:45:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 19 Apr 2010 08:45:22 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271614817.51.0.532587928673.issue8438@psf.upfronthosting.co.za>
Message-ID: <4BCC185D.3070500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> I think it would be best to backport the handler (even though 
>> it is not needed in Python 2.7), since it makes porting apps 
>> to 3.x easier.
> 
> surrogateescape should not be used directly be applications. It's used by Python3 internals using unicode by default.
> 
> I don't know if it's would help porting applications from Python2 to Python3. I don't know a use case of surrogateescape in Python2. By default, Python2 uses byte string everywhere, especially for filenames, and so it doesn't need any unicode error handler.
> 
> Another point to consider is that utf8 encoder rejects surrogates in Python3, whereas surrogates are accepted by the Python2 utf8 encoder.

Sorry, I think I need to correct myself: I mixed up the handlers
surrogateescape and surrogatepass. I was actually thinking of the
surrogatepass handler which makes the Python3 UTF-8 codec have like the
Python2 UTF-8 codec (without extra handler), not the surrogatescape
handler which implements the UTF-8b logic of escaping non-encodable
bytes to lone surrogates.

* The surrogatepass handler is needed in Python 2.7 to make it
possible to write applications that work in both 2.7 and 3.x
without changing the code.

I consider this an important missing backport for 2.7, since
without this handler, the UTF-8 codecs in 2.7 and 3.x are
incompatible and there's no other way to work around this
other than to make use of the errorhandler conditionally
depend on the Python version.

As such, it's a bug rather than a new feature.

* The surrogateescape handler implements the UTF-8b escaping
logic:

b'\x91\x92'

In Python 3.x this is needed to work around problems with
wrong I/O encoding settings or situations where you have mixed
encoding settings used in external resources such as environment
variable content, filesystems using different encodings than
the system one, remote shell output, pipes which don't carry
any encoding information, etc. etc.

Backporting this handler would be useful for Python 2.7 as
well, since it allows preparing 2.7 applications for use in
3.x and again allows using the same code for 2.7 and 3.x.

Not having this handler in 2.7 is not as serious as the
surrogatepass handler, but still useful for applications to
use that are meant to run in 2.7 and 3.x unchanged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Mon Apr 19 10:55:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Apr 2010 08:55:48 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271667348.61.0.505710926212.issue8438@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I consider this an important missing backport for 2.7, since
> without this handler, the UTF-8 codecs in 2.7 and 3.x are
> incompatible and there's no other way to work around this
> other than to make use of the errorhandler conditionally
> depend on the Python version.

FWIW I tried to updated the UTF-8 codec on trunk from RFC 2279 to RFC 3629 while working on #8271, and found out this difference in the handling of surrogates (only on 3.x they are invalid).
I didn't change the behavior of the codec in the patch I attached to #8271 because it was out of the scope of the issue, but I consider the fact that in Python 2.x surrogates can be encoded as a bug, because it doesn't follow RFC 3629.
IMHO Python 2.x should provide an RFC-3629-compliant UTF-8 codec, however I didn't have time yet to investigate how Python 3 handles this and what is the best solution (e.g. adding another codec or change the default behavior).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:03:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 09:03:31 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271667811.08.0.732046094649.issue8393@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> And please add unit tests...

I'm thinking on this. I plan to write tests for all my last changes about surrogates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:05:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Apr 2010 09:05:29 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271667929.79.0.434101126971.issue8394@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It does not work on Windows:

>>> ctypes.CDLL(b'kernel32')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\afa\python\py3k-1\lib\ctypes\__init__.py", line 350, in __init__
    self._handle = _dlopen(self._name, mode)
TypeError: bad argument type for built-in operation

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:09:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 09:09:34 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271668174.33.0.876473729722.issue8393@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It does not work on Windows

I always consider Windows as a special case because Windows uses unicode internally. Byte string are converted quickly to unicode using the current locale.

My patch was for UNIX/BSD which uses byte string internally.

sp_CreateProcess() in PC/_subprocess.c uses CreateProcessW. To support byte string, we should use the byte string version of CreateProcess ("CreateProcessA" ?) or convert current directory to unicode (using the current locale). The second solution minimize the changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:13:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 09:13:19 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271668399.17.0.953371074064.issue8394@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

load_library() uses LoadLibraryW() which use a WCHAR*. To support bytes, we can use LoadLibraryA() and TCHAR*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:15:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 19 Apr 2010 09:15:30 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271667348.61.0.505710926212.issue8438@psf.upfronthosting.co.za>
Message-ID: <4BCC1F6E.5080306@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
>> I consider this an important missing backport for 2.7, since
>> without this handler, the UTF-8 codecs in 2.7 and 3.x are
>> incompatible and there's no other way to work around this
>> other than to make use of the errorhandler conditionally
>> depend on the Python version.
> 
> FWIW I tried to updated the UTF-8 codec on trunk from RFC 2279 to RFC 3629 while working on #8271, and found out this difference in the handling of surrogates (only on 3.x they are invalid).
> I didn't change the behavior of the codec in the patch I attached to #8271 because it was out of the scope of the issue, but I consider the fact that in Python 2.x surrogates can be encoded as a bug, because it doesn't follow RFC 3629.
> IMHO Python 2.x should provide an RFC-3629-compliant UTF-8 codec, however I didn't have time yet to investigate how Python 3 handles this and what is the best solution (e.g. adding another codec or change the default behavior).

We have good reasons to allow lone surrogates in the UTF-8
codec.

Please remember that Python is a programming language
meant to allow writing applications, which also includes constructing
Unicode data from scratch, rather than an application which is
only meant to work with UTF-8 data.

Also note that lone surrogates were considered valid UTF-8 at the
time of adding Unicode support to Python and many years after that.

Since the codec is used in lots of applications, following the
Unicode consortium change in 2.7 is not possible.

This is why it was done in the 3.x branch and then only with
the additional surrogatepass handler to get back the old behavior
where needed.

But this is getting offtopic for the issue in question... I'll
open a new ticket for the backports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:23:01 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Apr 2010 09:23:01 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271668981.72.0.710069532973.issue8393@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PEP 277 explicitly states that unicode strings should be passed to wide-character functions, whereas byte strings use "standard" functions.
This is done in posixmodule.c, for example.

The "current locale" is a moving thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:23:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 09:23:35 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271669015.7.0.556983589224.issue8394@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I only fixed UNIX/BSD versions of subprocess/ctypes.dlopen() because it's not possible to open some files with an undecodable filename. On Windows, the file system and Python3 use Unicode, and so there is no such corner case.

On Windows, should we encourage people migrating from byte to character string? Or should we support byte string for backward compatibility or because there is really a corner case where it's not possible to open a file with an unicode string?

See also my msg103565 (Issue #8393, subprocess),

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:25:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Apr 2010 09:25:29 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271669129.81.0.833361370556.issue8394@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

yes, except that TCHAR* depends on compilation settings (it resolves to wchar_t when UNICODE is #defined); simply use char*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Mon Apr 19 11:43:04 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 09:43:04 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271670184.85.0.756676225806.issue8453@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Odd, works for me on 10.4, 10.5, and 10.6 (but I have never tried running under buildbot, if that is what is happening here).
  
For 10.4 with its most-recent Xcode installed:

$ /usr/bin/ld -v
Apple Computer, Inc. version cctools-622.9~2
$ /usr/bin/gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)
$ uname -a
Darwin <hostname> 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
$ /usr/bin/python ./build-installer.py --build-dir ../../dmg
...
gcc-4.0 -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -o bzip2 bzip2.o -L. -lbz2
gcc-4.0 -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c bzip2recover.c
...
echo ".so man1/bzdiff.1" > /Users/nad/2.7.dmg/build/dmg/libraries/usr/local//man/man1/bzcmp.1
Done Bzip2 1.0.5

Using local copy of ZLib 1.2.3
...

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Mon Apr 19 12:02:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 10:02:55 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271671375.6.0.161084263973.issue8393@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> PEP 277 explicitly states that unicode strings should be passed to
>  wide-character functions, whereas byte strings use "standard"
> functions. This is done in posixmodule.c, for example.

CreateProcessW takes a lot of arguments. Should we CreateProcessA or CreateProcessW if some arguments are byte string and other are unicode string?

> The "current locale" is a moving thing.

Don't CreateProcessA do the same thing? Convert byte string to unicode using the current locale. To use the right words, by "current locale" I mean the "mbcs" Windows codec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From mal at egenix.com  Mon Apr 19 11:16:30 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 19 Apr 2010 11:16:30 +0200
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271667348.61.0.505710926212.issue8438@psf.upfronthosting.co.za>
References: <1271667348.61.0.505710926212.issue8438@psf.upfronthosting.co.za>
Message-ID: <4BCC1F6E.5080306@egenix.com>

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
>> I consider this an important missing backport for 2.7, since
>> without this handler, the UTF-8 codecs in 2.7 and 3.x are
>> incompatible and there's no other way to work around this
>> other than to make use of the errorhandler conditionally
>> depend on the Python version.
> 
> FWIW I tried to updated the UTF-8 codec on trunk from RFC 2279 to RFC 3629 while working on #8271, and found out this difference in the handling of surrogates (only on 3.x they are invalid).
> I didn't change the behavior of the codec in the patch I attached to #8271 because it was out of the scope of the issue, but I consider the fact that in Python 2.x surrogates can be encoded as a bug, because it doesn't follow RFC 3629.
> IMHO Python 2.x should provide an RFC-3629-compliant UTF-8 codec, however I didn't have time yet to investigate how Python 3 handles this and what is the best solution (e.g. adding another codec or change the default behavior).

We have good reasons to allow lone surrogates in the UTF-8
codec.

Please remember that Python is a programming language
meant to allow writing applications, which also includes constructing
Unicode data from scratch, rather than an application which is
only meant to work with UTF-8 data.

Also note that lone surrogates were considered valid UTF-8 at the
time of adding Unicode support to Python and many years after that.

Since the codec is used in lots of applications, following the
Unicode consortium change in 2.7 is not possible.

This is why it was done in the 3.x branch and then only with
the additional surrogatepass handler to get back the old behavior
where needed.

But this is getting offtopic for the issue in question... I'll
open a new ticket for the backports.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 19 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From report at bugs.python.org  Mon Apr 19 12:34:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Apr 2010 10:34:25 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271673265.9.0.460985573585.issue8451@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some notes about the patch:

- NEWS blurbs generally appear antichronologically, that is newest first :-)
- you don't have to mention that "The 3.2 changes mentioned above are included in 2.7"
- the part of the PyArg_ParseTupleAndKeywords string after the semi-colon is supposed to be a custom error message, which "[ident string [, logoption [, facility]]]" doesn't look like; how about simply using a colon and putting the function name?
- you should check PyList_Size()'s return value for error (sys.argv could have been overriden to something else than a list)
- similarly, scriptobj is not guaranteed to be a string object, so you have to check for that too
- to check for string length > 0, it looks more natural to check either that script[0] != 0, or that PyString_GET_SIZE(...) > 0 (rather than calling PyObject_IsTrue())
- why do you Py_INCREF() the "openargs" tuple? It looks like a reference leak
- if PyTuple_New(0) fails (which I admit is highly unlikely), you should free all other resources and bail out
- when manually calling syslog_openlog(), you should check the return value and either Py_DECREF it (if non-NULL) or bail out

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Mon Apr 19 12:46:13 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Apr 2010 10:46:13 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271673973.04.0.0114036634219.issue8410@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Also, _POSIX_SEMAPHORES must be defined to be greater than 200112L.  If it isn't, then it isn't supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Mon Apr 19 12:51:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 10:51:01 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271674261.4.0.301843106945.issue8428@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: buildbot: test_multiprocessing timeout -> buildbot: test_multiprocessing timeout (test_notify_all? test_pool_worker_lifetime?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Mon Apr 19 12:56:02 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 19 Apr 2010 10:56:02 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271674562.71.0.500951780983.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

test_itimer_virtual assumes that a process must get 0.3s of virtual
time within 5s of real time. This is not true:

I can easily make the test fail even on a fast machine by doing
as root (do it n times for n cores):

nice -n -19 sh -c 'echo "1234^123456789" | bc'


======================================================================
FAIL: test_itimer_prof (__main__.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_signal.py", line 401, in test_itimer_prof
    self.fail('timeout waiting for sig_prof signal')
AssertionError: timeout waiting for sig_prof signal

======================================================================
FAIL: test_itimer_virtual (__main__.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_signal.py", line 379, in test_itimer_virtual
    (signal.getitimer(self.itimer),))
AssertionError: timeout waiting for sig_vtalrm signal; signal.getitimer(self.itimer) gives: (0.200012, 0.200012)

----------
nosy: +skrah
title: buildbots: test_itimer_virtual failures -> Test assumptions for test_itimer_virtual and test_itimer_prof

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Mon Apr 19 12:56:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 10:56:31 +0000
Subject: [issue8428] buildbot: test_multiprocessing timeout (test_notify_all?
	test_pool_worker_lifetime?)
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271674591.98.0.0980386793893.issue8428@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8428>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:27:11 2010
From: report at bugs.python.org (Perbandt)
Date: Mon, 19 Apr 2010 11:27:11 +0000
Subject: [issue8454] unittest Module Problem with different Kinds of Invocation
In-Reply-To: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>
Message-ID: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>


New submission from Perbandt <adalbert.perbandt at infineon.com>:

I just figured out a problem with the Python module 'unittest.py',
version 1.63.

The function '__init__' behaves a bit strange in certain circumstances.
It is called either directly from the command line or it is called when
unit tests are to be executeded from a script.
The latter form is used by the pyunit Ant task. It generates such a
python script an passes it into a python process. Example:

import unittest
s = open('PyUnit-report.log', 'w')
unittest.main(module=None,
              defaultTest=None,       
         argv=[plugins.Excel_5P_Import_Test','plugins.HDL_Import_Test',
                    'plugins.IPXact_Import_Test'],
              testRunner=unittest.TextTestRunner(stream=s))
 
The paroblem with this way of activating the unittest module is that
in the function parseArgs (lines 775 to 796) the first element from
argv is skipped:
 
778: options, args = getopt.getopt(argv[1:], 'hHvq',
779                                ['help','verbose','quiet'])
 
This way the first test module from the list of test modules passed in
by pyunit gets lost.

After analyzing your code I think it would be better to do the
skipping of the first element from argv directly in the __init__
method of the class 'TestProgram' at lines 760, 761. The code there
should look as follows:
 
760     if argv is None:
761         argv = sys.argv[1:]
 
This code would skip the first element from the argv array only when
the __init__ method would be called indirectly from the command line.

----------
components: Extension Modules
messages: 103576
nosy: AP
severity: normal
status: open
title: unittest Module Problem with different Kinds of Invocation
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8454>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:29:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:29:04 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86 Tiger 3.x/builds/25/steps/test/logs/stdio

test_urllib2_localnet
test test_urllib2_localnet failed -- multiple errors occurred; run in verbose mode for details
Re-running test test_urllib2_localnet in verbose mode
test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR
test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR
test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR
test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok
test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... ok
test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok
test_chunked (test.test_urllib2_localnet.TestUrlopen) ... ok
test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok
test_info (test.test_urllib2_localnet.TestUrlopen) ... ok
test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok
test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok

======================================================================
ERROR: test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 938, in request
    self._send_request(method, url, body, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 976, in _send_request
    self.endheaders(body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 934, in endheaders
    self._send_output(message_body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 788, in _send_output
    self.send(msg)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 729, in send
    self.connect()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 711, in connect
    self.timeout, self.source_address)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 321, in create_connection
    raise error(msg)
socket.error: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_urllib2_localnet.py", line 278, in test_proxy_qop_auth_works
    result = self.opener.open(self.URL)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1090, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 61] Connection refused>

======================================================================
ERROR: test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 938, in request
    self._send_request(method, url, body, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 976, in _send_request
    self.endheaders(body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 934, in endheaders
    self._send_output(message_body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 788, in _send_output
    self.send(msg)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 729, in send
    self.connect()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 711, in connect
    self.timeout, self.source_address)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 321, in create_connection
    raise error(msg)
socket.error: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_urllib2_localnet.py", line 266, in test_proxy_with_bad_password_raises_httperror
    self.URL)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 456, in assertRaises
    callableObj(*args, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1090, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 61] Connection refused>

======================================================================
ERROR: test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 938, in request
    self._send_request(method, url, body, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 976, in _send_request
    self.endheaders(body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 934, in endheaders
    self._send_output(message_body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 788, in _send_output
    self.send(msg)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 729, in send
    self.connect()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 711, in connect
    self.timeout, self.source_address)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 321, in create_connection
    raise error(msg)
socket.error: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_urllib2_localnet.py", line 272, in test_proxy_with_no_password_raises_httperror
    self.URL)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 456, in assertRaises
    callableObj(*args, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1090, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 61] Connection refused>

----------------------------------------------------------------------
Ran 14 tests in 10.076s

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 103577
nosy: haypo
severity: normal
status: open
title: buildbot: test_urllib2_localnet failures (Connection refused) on Tiger buildbot
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:30:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:30:09 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271676609.95.0.127763036741.issue8455@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:30:12 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Apr 2010 11:30:12 +0000
Subject: [issue8454] unittest Module Problem with different Kinds of Invocation
In-Reply-To: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>
Message-ID: <1271676612.06.0.850108646192.issue8454@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord
versions: +Python 2.6, Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8454>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:31:32 2010
From: report at bugs.python.org (AndiDog)
Date: Mon, 19 Apr 2010 11:31:32 +0000
Subject: [issue8456] sqlite3.connect documentation is incorrect
In-Reply-To: <1271676692.22.0.105359668933.issue8456@psf.upfronthosting.co.za>
Message-ID: <1271676692.22.0.105359668933.issue8456@psf.upfronthosting.co.za>


New submission from AndiDog <AndiDog at web.de>:

The sqlite3.connect documentation (keyword args) is incorrect:

    sqlite3.connect(database[, timeout, isolation_level, detect_types, factory])

As opposed to the C implementation:

    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|diOiOi", kwlist,
                                     &database, &timeout, detect_types, &isolation_level, &check_same_thread, &factory, &cached_statements))
    {
        return NULL; 
   }

----------
assignee: georg.brandl
components: Documentation
messages: 103578
nosy: AndiDog, georg.brandl
severity: normal
status: open
title: sqlite3.connect documentation is incorrect
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8456>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:35:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:35:11 +0000
Subject: [issue8457] buildbot: test_asynchat and test_smtplib failures on
	Tiger: [Errno 9] Bad file descriptor
In-Reply-To: <1271676911.81.0.0770773207045.issue8457@psf.upfronthosting.co.za>
Message-ID: <1271676911.81.0.0770773207045.issue8457@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86 Tiger 2.6/builds/9/steps/test/logs/stdio

test_asynchat
test test_asynchat produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a04f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a09f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0b78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a09f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0cf8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07b8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0cb8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a04f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07b8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0d78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])

**********************************************************************

test_smtplib
test test_smtplib produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:55603 at 0x4323cb8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:55606 at 0x43236f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:55609 at 0x43152b8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])

**********************************************************************

----------
components: Library (Lib), Tests
messages: 103579
nosy: db3l, haypo
severity: normal
status: open
title: buildbot: test_asynchat and test_smtplib failures on Tiger: [Errno 9] Bad file descriptor
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8457>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:40:35 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 19 Apr 2010 11:40:35 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271677235.99.0.031419356566.issue8410@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Hi, 

krisvale:
> Since the exact mechanics seem to be unclair to many, let me just step you through the series of events.
> 1) A has the lock, B is waiting for it.  the bit is "set".
> 2) A releases the lock:  Clears the bit, signals the condition variable.
> 3) A tries to immediately reacquire the lock.  Sees the bit cleared, sets it, and claims the lock.
> 4) B wakes up from the condition variable.  Sees the bit "set" and goes back to sleep.  It has lost the race to A.

I don't quite understand the four steps you explained. After the time of step 2, B is going to waken up and acquire the lock, and at the same time A returns from release function and is going to reacquire the lock. Who is scheduled first after A signals the condition variable is not predictable. So why does A always acquire the lock?

Thanks!

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:47:01 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 19 Apr 2010 11:47:01 +0000
Subject: [issue8454] unittest Module Problem with different Kinds of Invocation
In-Reply-To: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>
Message-ID: <1271677621.02.0.115632593908.issue8454@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

That change would be backwards incompatible with existing scripts calling main(...) programattically though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8454>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:48:50 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Apr 2010 11:48:50 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271677730.95.0.995774606962.issue8410@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

In 2), B is indeed signaled and the OS makes it "runnable".  But it doesn?t run immediately. A is still running.  There is no need for A to stop running until it runs out of timeslice.  Meanwhile the OS has to put B on a separate core (which makes this problem more significant on multicore), putting it at the end of the runnable queue where it has to percolate to the top for it to actually start execution some time later.

In effect, B has has to 'race' with A (and any other threads) to get the lock and since A is already running, it is likely to win the race.

Having threads 'race' to get synchronization primitives is a valid technique to reduce lock convoying problems, but it also can cause thread starvation, and is not approppriate when you want to ensure fair use of the resource.  To ensure fairness, lock "handoff" must be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:53:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:53:47 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The error only occured once, and it was not reproduced when test_cmd_line was rerunning in verbose mode.

http://www.python.org/dev/buildbot/builders/x86 Tiger 3.x/builds/25/steps/test/logs/stdio

test test_cmd_line failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmd_line.py", line 58, in test_q
    self.verify_valid_flag('-Qold')
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmd_line.py", line 49, in verify_valid_flag
    data = self.start_python(cmd_line)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmd_line.py", line 34, in start_python
    p = spawn_python(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/script_helper.py", line 29, in spawn_python
    stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/subprocess.py", line 694, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor

Re-running test test_cmd_line in verbose mode
test_directories (test.test_cmd_line.CmdLineTest) ... ok
test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest) ... ok
test_optimize (test.test_cmd_line.CmdLineTest) ... ok
test_q (test.test_cmd_line.CmdLineTest) ... ok
test_run_code (test.test_cmd_line.CmdLineTest) ... ok
test_run_module (test.test_cmd_line.CmdLineTest) ... ok
test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_input (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_output (test.test_cmd_line.CmdLineTest) ... ok
test_usage (test.test_cmd_line.CmdLineTest) ... ok
test_verbose (test.test_cmd_line.CmdLineTest) ... ok
test_version (test.test_cmd_line.CmdLineTest) ... ok

----------------------------------------------------------------------
Ran 13 tests in 3.860s

OK

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 103583
nosy: db3l, haypo
severity: normal
status: open
title: buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:54:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:54:10 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1271678050.14.0.967390028695.issue8458@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8457.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Mon Apr 19 13:54:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:54:17 +0000
Subject: [issue8457] buildbot: test_asynchat and test_smtplib failures on
	Tiger: [Errno 9] Bad file descriptor
In-Reply-To: <1271676911.81.0.0770773207045.issue8457@psf.upfronthosting.co.za>
Message-ID: <1271678057.04.0.215249289438.issue8457@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8458.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8457>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:21:31 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 19 Apr 2010 12:21:31 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271679691.37.0.76277591026.issue4256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Patch for optparse with tests. If it's ok, I'll sit down to argparse.

----------
keywords: +patch
Added file: http://bugs.python.org/file16985/4256_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:24:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Apr 2010 12:24:16 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1271679856.91.0.413228501498.issue8450@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8450>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:24:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 12:24:35 +0000
Subject: [issue8459] buildbot: test_select failure on Python 2.6, Windows
In-Reply-To: <1271679875.89.0.922749709725.issue8459@psf.upfronthosting.co.za>
Message-ID: <1271679875.89.0.922749709725.issue8459@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86 XP-5 2.6/builds/147/steps/test/logs/stdio

test_select
test test_select failed -- Traceback (most recent call last):
  File "C:\buildslave\2.6.moore-windows\build\lib\test\test_select.py", line 24, in test_returned_list_identity
    r, w, x = select.select([], [], [], 1)
error: (10022, 'An invalid argument was supplied')

----------
components: Extension Modules, Tests
keywords: buildbot
messages: 103587
nosy: haypo
severity: normal
status: open
title: buildbot: test_select failure on Python 2.6, Windows
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8459>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:24:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Apr 2010 12:24:46 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271679886.97.0.123167392484.issue8424@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> test_itimer_virtual assumes that a process must get 0.3s of virtual
> time within 5s of real time. This is not true [...]

I agree it's not a good test, especially when run on machines that are heavily loaded, or on an OS running in VM.  I can't really think of *any* way of reliably testing the amount of virtual time that's passed.  Anyone else?

How about removing just the timing part of the itimer_virtual tests? (Leaving the calls in so that the functionality does at least get exercised.)   Or we could leave the timing in so that the test is still useful on an otherwise lightly-loaded machine, but don't count it as a failure if the test times out without getting a signal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:25:31 2010
From: report at bugs.python.org (Perbandt)
Date: Mon, 19 Apr 2010 12:25:31 +0000
Subject: [issue8454] unittest Module Problem with different Kinds of Invocation
In-Reply-To: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>
Message-ID: <1271679931.45.0.992845690991.issue8454@psf.upfronthosting.co.za>


Perbandt <adalbert.perbandt at infineon.com> added the comment:

Yes, the proposed fix would be an incompatible change. But my assumption is that in scenarios where main(...) is called programmatically the fix would correct an erroneous behavior. In these scenarios whatever is being passed as the first entry in the argv array gets lost currently. Possibly many users who already noticed this implemented a workaround (I changed the pyunit Ant task's code to add a dummy argument as the first element in the argv array).

----------
versions: +Python 2.5 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8454>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:42:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 12:42:26 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If an URL doesn't answer, the whole test hung. Many buildbots turned red because an URL (maybe ftp://ftp.kernel.org/pub/linux/kernel/README) didn't answer during few minutes (it works again).

We should add a timeout, eg. 5 minutes. I don't know what to do on timeout: ignore the test? skip the test? Ignore should be fine.

----------
components: Library (Lib), Tests
messages: 103590
nosy: haypo
severity: normal
status: open
title: Set a timeout in test_urllib2net
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:49:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 12:49:39 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271681379.86.0.214973557257.issue8424@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I can't really think of *any* way of reliably testing the amount of virtual time that's passed.

Can't we try to increase the timeout step by step? Eg. 5 sec => 10 sec, then 15 sec, etc. until the buildbots turn green?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Mon Apr 19 14:55:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Apr 2010 12:55:47 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271681747.75.0.98347734721.issue8424@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Can't we try to increase the timeout step by step? Eg. 5 sec => 10 sec, > then 15 sec, etc. until the buildbots turn green?

I think you'd need an increase of an order of magnitude or two (possibly more) in some cases to make this work:  notice that the failure message from the itimer_virtual test gives an indication of how much virtual time *has* actually passed, and in some cases it's none at all (to within the timer resolution).

Also, this doesn't seem like a very future-proof solution.

Reducing the time intervals (0.2, 0.3, ...) probably isn't much of an option either:  I'd expect difficulties with timer resolution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Mon Apr 19 15:27:46 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 19 Apr 2010 13:27:46 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271683666.65.0.365572951612.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, I also think there is no reliable witness function that checks
the amount of virtual time used.

I guess it's best to increase the timeout and just print a diagnostic
if the test "fails".

----------
keywords: +patch
Added file: http://bugs.python.org/file16986/issue8424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Mon Apr 19 15:43:42 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 13:43:42 +0000
Subject: [issue8461] PythonLauncher universal build fails due to missing -arch
	and -sysroot
In-Reply-To: <1271684622.87.0.695093789846.issue8461@psf.upfronthosting.co.za>
Message-ID: <1271684622.87.0.695093789846.issue8461@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Fixes for Issue8366 corrected build failures with universal builds on OS X due to changes in the settings of CFLAGS and BASECFLAGS, which had caused -arch values to be added to both CFLAGS and BASECFLAGS.  The Mac Makefile for the PythonLauncher app needs to be changed as well, otherwise universal builds can now fail with errors like:

ld warning: in FileSettings.o, file is not of required architecture
ld warning: in MyAppDelegate.o, file is not of required architecture
ld warning: in MyDocument.o, file is not of required architecture
ld warning: in PreferencesWindowController.o, file is not of required architecture
ld warning: in doscript.o, file is not of required architecture
ld warning: in main.o, file is not of required architecture
Undefined symbols for architecture i386:
  "_main", referenced from:
      __start in crt1.o
ld: symbol(s) not found for architecture i386

The attached patch corrects the problem.

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-python-launcher-arch.txt
messages: 103594
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: PythonLauncher universal build fails due to missing -arch and -sysroot
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16987/issue-python-launcher-arch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8461>
_______________________________________

From report at bugs.python.org  Mon Apr 19 15:47:05 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 19 Apr 2010 13:47:05 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271683666.65.0.365572951612.issue8424@psf.upfronthosting.co.za>
Message-ID: <i2nac2200131004190646o7a016c5dpeafcb0b3358a857c@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Wasn't the freebsd problem unrelated to this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Mon Apr 19 15:59:21 2010
From: report at bugs.python.org (Stac)
Date: Mon, 19 Apr 2010 13:59:21 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1271685561.59.0.00474849981492.issue4768@psf.upfronthosting.co.za>


Stac <stac_agenais at yahoo.fr> added the comment:

Hello,

This patch has never been commited. I tested today with the 3.1 branch  (and checked in the lib code). Is there a better way to attach images in an email ?

Thanks in advance for your help,

Regards,
Stac

----------
nosy: +stac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:08:16 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 14:08:16 +0000
Subject: [issue8457] buildbot: test_asynchat and test_smtplib failures on
	Tiger: [Errno 9] Bad file descriptor
In-Reply-To: <1271676911.81.0.0770773207045.issue8457@psf.upfronthosting.co.za>
Message-ID: <1271686096.74.0.0899848346514.issue8457@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Duplicate of Issue7037 (test_asynchat) and Issue7040 (test_smtplib).

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8457>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:16:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 14:16:01 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1271686561.81.0.525215917332.issue8458@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I have also seen this test failure occasionally but only on OS X 10.4 systems, not 10.5 or 10.6.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:20:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 14:20:27 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271686827.73.0.193598619717.issue8455@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This appears to be a recently introduced failure; the same failure is seen on current trunk build on 10.5 and 10.6 as well.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:22:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 14:22:14 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271686934.17.0.332072391017.issue8455@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Maybe r80198 of #7154?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:22:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 14:22:57 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271686977.95.0.32151617448.issue8455@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:24:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 19 Apr 2010 14:24:21 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271687061.68.0.245686408535.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Right, the skip should be left in place.

----------
Added file: http://bugs.python.org/file16988/issue8424-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:26:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 14:26:02 +0000
Subject: [issue8459] buildbot: test_select failure
	(test_returned_list_identity) on Python 2.6, Windows
In-Reply-To: <1271679875.89.0.922749709725.issue8459@psf.upfronthosting.co.za>
Message-ID: <1271687162.11.0.723753841341.issue8459@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The fail looks to be related to #8329 (r79867:trunk, r79868:py3k, r79869:2.6, r79870:3.1).

----------
title: buildbot: test_select failure on Python 2.6, Windows -> buildbot: test_select failure (test_returned_list_identity) on Python 2.6, Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8459>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:26:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Apr 2010 14:26:20 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>
Message-ID: <1271687180.76.0.0567242057421.issue8191@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Google code search for

os.execlp\([^*,]+\) lang:python

returns 15 hits, two of which are the same as Matthias found.  I am not sure what these results mean for the issue (and Matthias does not reach a conclusion either.)

Note that the status quo in 3.x is that os.execlp(single_arg) is invalid, so all these examples will stop working in 3.x and will not be fixed by 2to3.  My patch will only make failure happen sooner and reason for it more obvious.

I am not very happy about issue1039 (r57731) to begin with.  (See my comments at issue8154.)  It was rather hastily applied 3.x feature without a corresponding -3 warning and not even a mention in the NEWS file.  However if r57731 stays as a strict POSIX compliance feature, I think it will be cleaner to enforce >1 argument to os.execl* functions in their signatures rather than in a run-time check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:26:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Apr 2010 14:26:23 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1271546297.73.0.705910010942.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271687309.3405.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With regards to SSL_peek() blocking, you'd need to explain yourself
> better on that one.  The patch has been tested with the test cases
> from Python SVN enough to be happy they run ok.

IIRC it worked with OpenSSL 1.0.0 but failed with 0.9.8k.
I could test it again if you think that is unlikely.

Can SSL_pending() be used in place of SSL_peek() in this case?
(note: there doesn't seem to be any documentation for SSL_peek() on the
openssl.org website)

> I'll leave you guys too it about how you want to handle things with
> python (i.e. to make the design choice trade offs).  I think all the
> points have been covered.

Thanks a lot for your help. I believe it has been fruitful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:28:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Apr 2010 14:28:18 +0000
Subject: [issue8459] buildbot: test_select failure
	(test_returned_list_identity) on Python 2.6, Windows
In-Reply-To: <1271679875.89.0.922749709725.issue8459@psf.upfronthosting.co.za>
Message-ID: <1271687298.38.0.97501532429.issue8459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8459>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:29:04 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 14:29:04 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271687344.29.0.846453651613.issue8455@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

That wouldn't explain trunk failures.  The _scproxy code has been in 26 and trunk for a long time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:30:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Apr 2010 14:30:08 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1271687408.79.0.568189980658.issue8154@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

If this new feature stays in 3.x, shouldn't 2.7 have a -3 warning?

Also, I would consider adding os.execlp(path) -> os.execlp(path, os.path.basename(path)) transformation to 2to3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Mon Apr 19 16:47:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Apr 2010 14:47:24 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1271688444.23.0.809582780118.issue8154@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I noticed that the change is still present in 2.7a.  For what it's worth, I agree with David:

"""
Since it does trigger a crash on the windows equivalent API, the check should be conditional on platform.  And it should generate a py3k warning on other platforms.
"""

I am changing classification to "feature request" and adding "Windows" to the list of components because if I understand David correctly, the title of the issue is valid only on Windows platform.  (On other platforms os.execlp(path) may cause a crash of the program found at path, but not a crash of python interpreter itself.)  I also remove 2.6 from the list of versions since after r79190 no further action is contemplated for 2.6 branch.

----------
components: +Windows
type: crash -> feature request
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Mon Apr 19 17:00:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 15:00:28 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271689228.45.0.505018425875.issue8460@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch sets the timeout to 60 seconds. It writes "<timeout: %s>" % url to stderr on timeout. I don't know better place to write the error. (The test doesn't fail, it just continues to the next URL)

----------
keywords: +patch
Added file: http://bugs.python.org/file16989/test_urllib2net_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Mon Apr 19 17:34:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 15:34:47 +0000
Subject: [issue8462] raise test_support.TestSkipped() is used outside main() /
	test_main()
In-Reply-To: <1271691287.55.0.252586227307.issue8462@psf.upfronthosting.co.za>
Message-ID: <1271691287.55.0.252586227307.issue8462@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

unittest in Python 2.6 has to SkipTest exception, but test_support has a TestSkipped which can be used to skip the whole file.

TestSkipped should not be used in a test function. Following tests have to be fixed: test_decimal, test_ioctl, test_largefile, test_nis, test_ossaudiodev, test_pty. Replace raise by return. To dislpay, print >>sys.stderr can be used.

----------
components: Tests
messages: 103609
nosy: haypo
severity: normal
status: open
title: raise test_support.TestSkipped() is used outside main() / test_main()
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8462>
_______________________________________

From report at bugs.python.org  Mon Apr 19 17:36:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 15:36:48 +0000
Subject: [issue8462] raise test_support.TestSkipped() is used outside main() /
	test_main()
In-Reply-To: <1271691287.55.0.252586227307.issue8462@psf.upfronthosting.co.za>
Message-ID: <1271691408.57.0.198465882392.issue8462@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

TestSkipped docstring should also explain that it should not be used in a test function, but only to skip the whole file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8462>
_______________________________________

From report at bugs.python.org  Mon Apr 19 17:59:12 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Apr 2010 15:59:12 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271692752.63.0.0370548801055.issue8393@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"mbcs" is not a fixed encoding and may change between Windows sessions, see the Rationale in PEP277 http://www.python.org/dev/peps/pep-0277/

The mixed case is interesting. We could use CreateProcessW when at least one string is Unicode, and CreateProcessA when all strings are bytes.
OTOH this is unlikely, because for example the environment will be passed as unicode; so I'm OK to use CreateProcessW in all cases, and use mbcs to convert bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Mon Apr 19 18:07:32 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Apr 2010 16:07:32 +0000
Subject: [issue8273] move generally useful test_support functions into the
	unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271693252.12.0.845961842962.issue8273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Also note that the test_support module is for some reason documented here: http://docs.python.org/library/test.html#module-test.test_support
This means that there are probably developers out there that are already using these functions even if some of them are not intended/designed to be used outside the Python test suite.
This situation is sub-optimal for two reasons:
1) test_support can't evolve quickly because the documented functions have to be backward-compatible;
2) other developers are using these python-test-suite-specific functions in their tests;
It would be better to keep test_support for our test suite only and provide/move useful function in unittest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Mon Apr 19 18:10:35 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 19 Apr 2010 16:10:35 +0000
Subject: [issue8273] move generally useful test_support functions into the
	unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271693435.21.0.441810310667.issue8273@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
nosy:  -tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Mon Apr 19 18:20:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 16:20:30 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271694030.02.0.0960918124675.issue8460@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Mon Apr 19 18:21:27 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 19 Apr 2010 16:21:27 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271694087.62.0.73267286814.issue4256@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Sorry, what does "I'll sit down to" mean? Does that mean you're offering to try to do the argparse patch too? Or that you'd rather someone else do it? (Either one's fine - I just couldn't tell which you meant.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon Apr 19 18:25:25 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Mon, 19 Apr 2010 16:25:25 +0000
Subject: [issue8463] shutil.make_archive() supports bz2,
	but it's not documented
In-Reply-To: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>
Message-ID: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>


New submission from Lino Mastrodomenico <l.mastrodomenico at gmail.com>:

The new function shutil.make_archive() supports bzip2 compression using "bztar" as format parameter, but neither the documentation nor the docstring mention it (all the other compression formats are correctly listed).

----------
assignee: georg.brandl
components: Documentation
messages: 103614
nosy: georg.brandl, mastrodomenico
severity: normal
status: open
title: shutil.make_archive() supports bz2, but it's not documented
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8463>
_______________________________________

From report at bugs.python.org  Mon Apr 19 18:56:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Apr 2010 16:56:32 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271696192.96.0.681406126927.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am attaching a forward port of Victor's timedelta_true_divide_divmod.patch to py3k.

----------
nosy: +Alexander.Belopolsky
Added file: http://bugs.python.org/file16990/issue2706.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 18:58:56 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 19 Apr 2010 16:58:56 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271696336.43.0.771488106646.issue4256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I guess I am using my English too little, that's why I am using polish expressions too often. What I meant was of course, that I will do argparse patch too.

I haven't provided docs for --help-options yet, becuase it is not clear to me, it is an accepted feature. When it is, I will update the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon Apr 19 19:06:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Apr 2010 17:06:21 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271696781.41.0.714261983987.issue2706@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy:  -belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 19:17:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 19 Apr 2010 17:17:56 +0000
Subject: [issue8273] move generally useful test_support functions into the
	unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1271697476.96.0.542760867623.issue8273@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy:  -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Mon Apr 19 19:39:01 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Mon, 19 Apr 2010 17:39:01 +0000
Subject: [issue8464] tarfile creates tarballs with execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>


New submission from Lino Mastrodomenico <l.mastrodomenico at gmail.com>:

tarfile.open(filename, "w|") creates a tar file with execute permissions set, if filename doesn't exist (i.e. it uses mode 0777 minus the umask). It should instead use mode 0666 minus the umask, which is what happens when using mode "w:..." instead of "w|...".

AFAICT this bug has always been present since the introduction of tarfile in Python 2.3, but it may soon become more noticeable since the new function shutil.make_archive() in Python 2.7 and 3.2 uses tarfile with mode "w|".

I have attached a patch for the trunk.

----------
components: Library (Lib)
files: tarfile.diff
keywords: patch
messages: 103617
nosy: mastrodomenico
severity: normal
status: open
title: tarfile creates tarballs with execute permissions set
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16991/tarfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8464>
_______________________________________

From report at bugs.python.org  Mon Apr 19 19:42:47 2010
From: report at bugs.python.org (Aaron)
Date: Mon, 19 Apr 2010 17:42:47 +0000
Subject: [issue8381] IDLE 2.6 freezes on OS X 10.6
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271698967.14.0.934380801888.issue8381@psf.upfronthosting.co.za>


Aaron <aaron.the.cow at gmail.com> added the comment:

I just used the biult in mac softwere

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:33:22 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 18:33:22 +0000
Subject: [issue8463] shutil.make_archive() supports bz2,
	but it's not documented
In-Reply-To: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>
Message-ID: <1271702002.6.0.0365772985123.issue8463@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Seems like these formats are supported, so yes "bztar" can be used as a format parameter.

_ARCHIVE_FORMATS = {
     'gztar': (_make_tarball, [('compress', 'gzip')], "gzip'ed tar-file"),
     'bztar': (_make_tarball, [('compress', 'bzip2')], "bzip2'ed tar-file"),                      
     'ztar':  (_make_tarball, [('compress', 'compress')],
                 "compressed tar file"),
     'tar':   (_make_tarball, [('compress', None)], "uncompressed tar file"),
     'zip':   (_make_zipfile, [],"ZIP file")
     }

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8463>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:44:22 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 18:44:22 +0000
Subject: [issue8463] shutil.make_archive() supports bz2,
	but it's not documented
In-Reply-To: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>
Message-ID: <1271702662.79.0.469014676453.issue8463@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Attaching the fix

----------
keywords: +patch
Added file: http://bugs.python.org/file16992/shutil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8463>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:50:40 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 18:50:40 +0000
Subject: [issue8381] IDLE 2.6 freezes on OS X 10.6
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271703040.9.0.472496883149.issue8381@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Idle provided by built-in python in Mac OS X Snow leopard i.e. python 2.6.1  is running without any issues. It is /usr/bin/idle2.6. And if by very new mac you mean latest intel based macs released last summer, then yes I have the same machine.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:53:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Apr 2010 18:53:14 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271703194.87.0.593829369626.issue8438@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed to trunk in r80215. I'm going to watch the buildbots, I suspect OS X might dislike surrogates in the filename.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:53:52 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 18:53:52 +0000
Subject: [issue8464] tarfile creates tarballs with execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1271703232.75.0.640973348757.issue8464@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Is "self.fd = os.open(name, mode, 0666)" Ok ? Should not it be "self.fd = os.open(name, mode, 0644)", because that is what the default permissions are.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8464>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:56:34 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 18:56:34 +0000
Subject: [issue8464] tarfile creates tarballs with execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1271703394.51.0.786946788546.issue8464@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8464>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:57:16 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 18:57:16 +0000
Subject: [issue8463] shutil.make_archive() supports bz2,
	but it's not documented
In-Reply-To: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>
Message-ID: <1271703436.85.0.853064578505.issue8463@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8463>
_______________________________________

From report at bugs.python.org  Mon Apr 19 20:59:34 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 18:59:34 +0000
Subject: [issue8463] shutil.make_archive() supports bz2,
	but it's not documented
In-Reply-To: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>
Message-ID: <1271703574.23.0.904069452128.issue8463@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee: georg.brandl -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8463>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:01:14 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 19:01:14 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1271703674.02.0.728122548124.issue4768@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:04:47 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 19 Apr 2010 19:04:47 +0000
Subject: [issue8454] unittest Module Problem with different Kinds of Invocation
In-Reply-To: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>
Message-ID: <1271703887.23.0.809537856508.issue8454@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'm sure that there are many places using the API as it is, inserting a dummy entry into the argv they pass. Although the fix you propose would solve the problem for users who are currently using the API wrongly it would break code for people who are using it correctly. It is certainly an unfortunate API wart - but I don't think it is worth breaking people's code to fix it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8454>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:08:50 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 19 Apr 2010 19:08:50 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271704130.37.0.390873332594.issue8460@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Hello Victor,

The patch looks for fine for a timeout enforcement.

A couple of changes required.

-                if isinstance(err[0], timeout):
+                if isinstance(err[0], socket.timeout):

And, in this portion:

+                try:
+                    with test_support.transient_internet():
+                        buf = f.read()
+                except socket.timeout:
+                    print >>sys.stderr, "<timeout: %s>" % url
                 f.close()
                 debug("read %d bytes" % len(buf))

The last line references, buf. It wont be available if a socket.timeout had happened. So, it can simply be moved to the line below buf = f.read(). Attaching the patch with these changes.

Question: Were you able to simulate a timeout at kernel.org site to test this? If yes, how? I am unable to simulate (by changing the kernel.org:81, kernel42.org etc), it immediately throws a connection refused. ( In general, I could simulate the timeout by urlopen('www.google.com:81', timeout=30) and test the exception) 

As build-bot seems to be hung, a timeout enforcement as the patch accomplishes is fine.

----------
Added file: http://bugs.python.org/file16993/test_urllib2net_timeout.patch-2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:19:02 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 19:19:02 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1271704742.45.0.845555386121.issue4768@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:38:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Apr 2010 19:38:54 +0000
Subject: [issue8438] Codecs: "surrogateescape" error handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271705934.64.0.140362402146.issue8438@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8438>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:46:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Apr 2010 19:46:18 +0000
Subject: [issue2302] Uses of SocketServer.BaseServer.shutdown have a race
In-Reply-To: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za>
Message-ID: <1271706378.15.0.896444553742.issue2302@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, getting rid of poll_interval for a file descriptor is easy under Unix, but wouldn't work under Windows (where select() only takes sockets, not arbitrary file descriptors).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2302>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:48:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 19:48:44 +0000
Subject: [issue8381] IDLE 2.6 freezes on OS X 10.6
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271706524.44.0.802384755157.issue8381@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Shashwat: what happens when you launch /usr/bin/idle2.6 and then open a new window in it (CMD N)?  My experience is like Aaron's (and many other reports): the Apple-supplied idle2.6 in OS X 10.6 usually hangs after opening a second window, requiring a Force Quit.  The problem appears to be pretty specific to the combination of idle2.6 and the 10.6 Apple-supplied Tk 8.5.  It's not a problem with the python.org 2.6 which links to Tk 8.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:55:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Apr 2010 19:55:13 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1271706913.68.0.421411127812.issue6692@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The patch in attachment implements support for epoll() and kqueue() by adding a new "poller" argument to asyncore.loop().

However, I had a chat with Jean Paul Calderone today which pointed out how useless this is. =)
The problem is basically how asyncore.loop() is implemented.
Being impossible to let loop() function know when a file descriptor gets added or removed from the socket map we are forced to iterate over all existing fds on every loop which nullifies the benefits offered by epoll() and kqueue() syscalls.

As of right now I can't think of a solution to this problem which doesn't imply a change to the current asyncore API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Mon Apr 19 21:57:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Apr 2010 19:57:37 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1271707057.17.0.298889387937.issue6692@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:02:01 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 19 Apr 2010 20:02:01 +0000
Subject: [issue8381] IDLE 2.6 freezes on OS X 10.6
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271707321.07.0.125442838096.issue8381@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Ned : After I opened a new window, that is how it opened : http://imagebin.us/images/gbg8zdr25hviw26hnqfv.png
And IDLE hanged a little later. Had to do a force quit. So yes, the problem is in Apple build Idle2.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:04:47 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Apr 2010 20:04:47 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1271707487.75.0.191583223014.issue6692@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Forgot to add the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file16994/asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:09:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Apr 2010 20:09:28 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271707768.64.0.772381155564.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Why is divmod(timedelta, timedelta) supported but not timedelta % timedelta?  I think if one is implemented, the other should be too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:15:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 19 Apr 2010 20:15:57 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271708157.78.0.134354950283.issue8453@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

David Bolen reported that this occurs with r80179, which now clears the PATH environment variable, removing ld from the path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:19:28 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Mon, 19 Apr 2010 20:19:28 +0000
Subject: [issue8464] tarfile creates tarballs with execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1271708368.09.0.0944150947329.issue8464@psf.upfronthosting.co.za>


Lino Mastrodomenico <l.mastrodomenico at gmail.com> added the comment:

I think 0666 is correct because os.open() does a bitwise AND between this value and the bitwise inversion of the umask, something like oct(0666 & ~umask).

Since the umask is usually 022 octal (18 decimal), the actual permission on disk should be 0644 as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8464>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:29:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Apr 2010 20:29:15 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1271707768.64.0.772381155564.issue2706@psf.upfronthosting.co.za>
Message-ID: <x2qd38f5331004191321p4942e09bz3062fcea2905ccd2@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Mon, Apr 19, 2010 at 4:09 PM, Mark Dickinson <report at bugs.python.org>wrote:

I noticed that as I was porting Victor's patch.   I did not add  timedelta %
timedelta because I found out that timedelta % int is not supported in the
released versions while timedelta // int is.

I was contemplating opening a separate RFE for divmod(timedelta, int)
and timedelta % int because I feel that increasing the number of added
features will reduce the likelihood of patch being accepted.  Personally, I
only had need for  timedelta // timedelta in my code and not any other
proposed features.

----------
Added file: http://bugs.python.org/file16995/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Mon, Apr 19, 2010 at 4:09 PM, Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Why is divmod(timedelta, timedelta) supported but not timedelta % timedelta? ??I think if one is implemented, the other should be too.<br><br></blockquote><div><br></div><div>I noticed that as I was porting Victor&#39;s patch. ?? I did not add ??timedelta % timedelta because I found out that??timedelta % int is not supported in the released versions while??timedelta // int is.</div>
<div><br></div><div>I was contemplating opening a separate RFE for divmod(timedelta, int) and??timedelta % int because I feel that increasing the number of added features will reduce the likelihood of patch being accepted. ??Personally, I only had need for????timedelta // timedelta in my code and not any other proposed features.</div>
</div>

From report at bugs.python.org  Mon Apr 19 22:37:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Apr 2010 20:37:01 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271709421.29.0.786522510434.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

By the way, the patch looks good to me, as far as it goes, and I'm +1 on adding all this.  I only have the tiniest of nits:

 - the patch deletes a line at the top of Lib/test/test_datetime.py, for no apparent reason

 - in delta_add, I think the added 'if' block should be an 'else if' (yes, I know this is excessively picky ;)

 - the brace style for if blocks is inconsistent:  please put the opening brace on the same line as the if.

One other thought:  with this division operation added, it might be nice to add constants like td_hour, td_minute, etc. to the module.  Then the perennial 'how can I convert my timedelta x to minutes' questions could be answered with 'just do x/td_minute'.  I would personally find x/td_second to be a more obvious and natural way to find the total number of seconds in a timedelta than x.total_seconds.  I also quite like the idea of being able to create a 2.5-hour timedelta with something like

2*td_hour + 30*td_minute

On the other hand, maybe such constants would just be added clutter, since it's easy to create them when needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:46:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Apr 2010 20:46:12 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271709972.34.0.842703267137.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tennessee, are you still tracking this issue?  If not, can I steal it from you.  :)

> I found out that timedelta % int is not supported in the
> released versions while timedelta // int is.

Mmm.  Interesting.  :)

I think it would be fine to add timedelta % timedelta in this patch, and then open another feature request for timedelta % int and friends as you suggest.  I don't think divmod(timedelta, timedelta) should go in if timedelta % timedelta doesn't also go in.

> I feel that increasing the number of added
> features will reduce the likelihood of patch being accepted.

Perhaps;  I haven't seen much opposition to these ideas anyway---I think the only reason they haven't been implemented yet is lack of round-tuits.

I'd be +1 on accepting the current patch if timedelta % timedelta were added to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:46:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Apr 2010 20:46:28 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271709988.59.0.18792786318.issue2706@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file16995/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:53:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Apr 2010 20:53:50 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271710430.92.0.745635834394.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Having timedelta // int work is *really* peculiar, since it can only be made sense of with reference to some implicit particular chosen unit of time;  in this case, that unit of time is apparently microseconds, as far as I can tell.

Surely there aren't any applications for timedelta // int?!  The operation just doesn't make dimensional sense, since it involves taking floor of a timedelta.

I vote -3.2 minutes on extending this craziness by adding timedelta % int or divmod(timedelta, int).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 22:54:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Apr 2010 20:54:09 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271710449.28.0.682221671352.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I should be able to add timedelta % timedelta and fix the nits that Mark mentioned tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Mon Apr 19 23:03:27 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 19 Apr 2010 21:03:27 +0000
Subject: [issue5250] Document __instancecheck__ and __subclasscheck__
In-Reply-To: <1234548219.84.0.437841096999.issue5250@psf.upfronthosting.co.za>
Message-ID: <1271711007.02.0.885577729725.issue5250@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

One last triviality: Could the mention of __subclasscheck__() in http://docs.python.org/dev/library/abc.html#abc.ABCMeta.__subclasshook__ get linked to the newly-added docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5250>
_______________________________________

From report at bugs.python.org  Mon Apr 19 23:11:17 2010
From: report at bugs.python.org (Aaron Sherman)
Date: Mon, 19 Apr 2010 21:11:17 +0000
Subject: [issue8465] Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>


New submission from Aaron Sherman <ajs at ajs.com>:

I tested this under 2.6 and 3.1. Under both, the common mistake that I'm sure many others have made, and which cost me quite some time today was:

 re.sub(r'(foo)bar', '\1baz', 'foobar')

It's obvious, I'm sure, to many reading this that the second "r" was left out before the replacement spec. It's probably obvious that this is going to happen quite a lot, and there are many edge cases which are equally baffling to the uninitiated (e.g. \8, \418 and \1111)

In order to avoid this, I'd like to request that such usage be deprecated, leaving only numeric escapes of the form matched by r'\\[0-7][0-7][0-7]?(?!\d)' as valid, non-deprecated uses (e.g. \01 or \111 are fine). Let's look at what that would do:

Right now, the standard library uses escape sequences with \n where n is a single digit in a handful of places like sndhdr.py and difflib.py. These are certainly not widespread enough to consider this a common usage, but certainly those few would have to change to add a leading zero before the digit.

OK, so the specific requested feature is that \xxx produces a warning where xxx is:

* any single digit or
* any invalid sequence of two or three digits (e.g containing 8 or 9) or
* any sequence of 4 or more digits

... guiding the user to the more explicit \01, \x01 or, if they intended a literal backslash, the r notation.

If you wish to go a step further, I'd suggest adding a no-op escape \e such that:

 \41\e1

would print "!1". Otherwise, there's no clean way to halt the interpretation of a digit-based escape sequence.

----------
components: Regular Expressions, Unicode
messages: 103640
nosy: Aaron.Sherman
severity: normal
status: open
title: Backreferences vs. escapes: a silent failure solved
type: feature request
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Mon Apr 19 23:21:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 21:21:36 +0000
Subject: [issue8464] tarfile creates tarballs with execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1271712096.69.0.897237087568.issue8464@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8464>
_______________________________________

From report at bugs.python.org  Mon Apr 19 23:33:42 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 21:33:42 +0000
Subject: [issue8463] shutil.make_archive() supports bz2,
	but it's not documented
In-Reply-To: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>
Message-ID: <1271712822.48.0.866557197394.issue8463@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r80221, r80224, 

Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8463>
_______________________________________

From report at bugs.python.org  Mon Apr 19 23:42:49 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 21:42:49 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271713369.8.0.0154013370084.issue6547@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Sorry, what's a "dangling symlink" ?

can you provide steps to reproduce this ?

I am moving the Python version to 2.6. If we are unable to reproduce it for Python > 2.5 we'll close it since we don't fix bugs for 2.5 anymore

----------
assignee:  -> tarek
nosy: +tarek
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Mon Apr 19 23:45:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 21:45:36 +0000
Subject: [issue4843] make distutils use shutil
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1271713536.78.0.536134969615.issue4843@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Mon Apr 19 23:59:01 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 19 Apr 2010 21:59:01 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271714341.7.0.73895577221.issue4256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Ok, here comes patch for argparse too.

----------
Added file: http://bugs.python.org/file16996/4256_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:03:50 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 19 Apr 2010 22:03:50 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271714630.68.0.392815918311.issue8437@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

If I'm reading this bug correctly, there are two issues here:
  
(A) that we shouldn't use gdb.Frame.function.name(), and should instead use gdb.Frame.name().  I believe this is a duplicate of issue 8279, and that this was fixed in trunk in r80156.    It hasn't yet been fixed in the py3k branch; the patch from r80156 does appear to apply cleanly there.

(B) That different builds of gdb may or may not have gdb.Frame.select.

I'm attaching a patch to trunk which tries to autodetect whether the gdb.Frame.select method is present.  The "py-up" and "py-down" commands and their selftest (StackNavigationTests) are made conditional upon this.


> gdb in Fedora 12 is based on 7.0.1 plus a lot of patches. But I don't see a patch added the
> select() method to the Python API:
> http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/
FWIW, the relevant patch is this one:
http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/gdb-archer.patch?revision=1.40&view=markup
(search for "frapy_select" within that patch); as I understand it this generating from the git repository used by the team that created the Python support within gdb, and as such it's a snapshot of work, much of which is now in upstream gdb's CVS repository.

----------
keywords: +patch
Added file: http://bugs.python.org/file16997/add-conditions-for-gdb.Frame.select-to-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:04:42 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 19 Apr 2010 22:04:42 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271714682.97.0.307885270277.issue8437@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Assigning to loewis for review

----------
assignee: dmalcolm -> loewis
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:15:38 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 22:15:38 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271715338.52.0.427958480058.issue8453@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I still don't understand why that isn't showing up in my environment (I've been running with that change for over a year) and I can't see why ld would fail but ar and ran don't.  Can you verify the version of Xcode that has been installed?  Perhaps there is an older tool chain on the buildbot.  It is certainly easy to change the PATH test in r80179 to supply some default path (/usr/bin:/bin perhaps) but I'd like to know why it is needed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:16:06 2010
From: report at bugs.python.org (Timothee Besset)
Date: Mon, 19 Apr 2010 22:16:06 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271715366.82.0.701190255078.issue6547@psf.upfronthosting.co.za>


Timothee Besset <ttimo at idsoftware.com> added the comment:

It's a symlink that points to a file that doesn't exist. There are many ways this can happen, in this particular case my text editor (emacs) seems to keep some metadata about which user, machine and process is editing a file. I tried to reproduce in 2.6 (Debian sid amd64) and I can confirm it still happens:

timo at ttimozilla:~$ mkdir test
timo at ttimozilla:~$ cd test
timo at ttimozilla:~/test$ ln -s foo bar
timo at ttimozilla:~/test$ ls -1l bar
lrwxrwxrwx 1 timo timo 3 Apr 19 17:12 bar -> foo
timo at ttimozilla:~/test$ ls -1l foo
ls: cannot access foo: No such file or directory
timo at ttimozilla:~/test$ python2.6
Python 2.6.5 (r265:79063, Mar 20 2010, 03:56:44) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copytree( '../test', '../test2' )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/shutil.py", line 177, in copytree
    raise Error, errors
shutil.Error: [('../test/bar', '../test2/bar', "[Errno 2] No such file or directory: '../test/bar'")]
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:18:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 22:18:37 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271715517.33.0.535855458209.issue8453@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(er, "ranlib")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:26:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 22:26:31 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271715991.45.0.968346538097.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> (A) that we shouldn't use gdb.Frame.function.name(), ...
> that this was fixed in trunk in r80156.

This command is not correct: it still calls .function() method:
     def is_evalframeex(self):
        '''Is this a PyEval_EvalFrameEx frame?'''
        if self._gdbframe.function():
            if self._gdbframe.name() == 'PyEval_EvalFrameEx':

Call to self._gdbframe.function() can be removed.

> The "py-up" and "py-down" commands and their selftest
> (StackNavigationTests) are made conditional upon this.

It's not enough, test_print_after_up() and test_locals_after_up() require also py-up command.

Attached patch is based on add-conditions-for-gdb.Frame.select-to-trunk.patch and fix described problems. Using test_gdb-2.patch, test_gdb pass without any error on my Debian Sid (gdb 7.1).

----------
Added file: http://bugs.python.org/file16998/test_gdb-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:30:46 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Apr 2010 22:30:46 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1271716246.93.0.052617268594.issue4814@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed as r80226 (2.7) and r80228 (3.2).

----------
components: +Library (Lib)
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:32:37 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 22:32:37 +0000
Subject: [issue1540112] Allow choice of copy function in shutil.copytree
Message-ID: <1271716357.81.0.659020756154.issue1540112@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r80230, thanks !

----------
assignee:  -> tarek
nosy: +tarek
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540112>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:35:12 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 22:35:12 +0000
Subject: [issue5168] shutil.copystat does not copy the "hidden" flag on windows
In-Reply-To: <1233926318.17.0.887740362056.issue5168@psf.upfronthosting.co.za>
Message-ID: <1271716512.72.0.369889005037.issue5168@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
nosy: +tarek
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5168>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:37:25 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 19 Apr 2010 22:37:25 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271716645.54.0.523186758565.issue8437@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> Attached patch is based on add-conditions-for-gdb.Frame.select-to-
> trunk.patch and fix described problems. Using test_gdb-2.patch, test_gdb 
> pass without any error on my Debian Sid (gdb 7.1).

The patch conditionalizes each test within StackNavigationTests, but then drops it from the list of classes at the end.  Looks like it needs to be reinstated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:47:30 2010
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 19 Apr 2010 22:47:30 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1271709972.34.0.842703267137.issue2706@psf.upfronthosting.co.za>
Message-ID: <j2y43c8685c1004191547g741875a0me8eae7a6eb5dd93c@mail.gmail.com>


Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:

On Tue, Apr 20, 2010 at 6:46 AM, Mark Dickinson <report at bugs.python.org>wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Tennessee, are you still tracking this issue?  If not, can I steal it from
> you.  :)
>

Hi Mark,

Please feel free to steal it from me! Wonderful to see some movement on this
issue...

> > I found out that timedelta % int is not supported in the
> > released versions while timedelta // int is.
>
> Mmm.  Interesting.  :)
>
> I think it would be fine to add timedelta % timedelta in this patch, and
> then open another feature request for timedelta % int and friends as you
> suggest.  I don't think divmod(timedelta, timedelta) should go in if
> timedelta % timedelta doesn't also go in.
>

I'm an incrementalist -- I'm happy with one step at a time, so for what it's
worth I'd be happy to see divmod go in alone with % to be added later.
However, seeing as I'm really contributing, I'd say feel free to disregard
my vote of +1... :)

Regards,
-Tennessee

----------
Added file: http://bugs.python.org/file16999/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Tue, Apr 20, 2010 at 6:46 AM, Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br>
<br>
</div>Tennessee, are you still tracking this issue? ??If not, can I steal it from you. ??:)<br></blockquote><div><br></div><div>Hi Mark,??</div><div><br></div><div>Please feel free to steal it from me! Wonderful to see some movement on this issue...</div>
<div><br></div><div>??</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">&gt; I found out that timedelta % int is not supported in the<br>
&gt; released versions while timedelta // int is.<br>
<br>
</div>Mmm. ??Interesting. ??:)<br>
<br>
I think it would be fine to add timedelta % timedelta in this patch, and then open another feature request for timedelta % int and friends as you suggest. ??I don&#39;t think divmod(timedelta, timedelta) should go in if timedelta % timedelta doesn&#39;t also go in.<br>
</blockquote><div><br></div><div>I&#39;m an incrementalist -- I&#39;m happy with one step at a time, so for what it&#39;s worth I&#39;d be happy to see divmod go in alone with % to be added later. However, seeing as I&#39;m really contributing, I&#39;d say feel free to disregard my vote of +1... :)</div>
<div><br></div><div>Regards,</div><div>-Tennessee</div></div>

From report at bugs.python.org  Tue Apr 20 00:53:52 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 19 Apr 2010 22:53:52 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271717632.84.0.274977601112.issue8437@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Sorry about that.

Here's an updated version of the patch, combining my work with Victor's.

----------
Added file: http://bugs.python.org/file17000/add-conditions-for-gdb.Frame.select-to-trunk-003.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 00:55:40 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 22:55:40 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271717740.18.0.898334444038.issue6547@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok. what behavior would you expect in that case ? 

I propose that copytree() ignores symlinks that are not linked to an existing file in the copy process, and display a warning in this case.

We could add an option to transform this warning into an error that would stop the process.

----------
priority:  -> normal
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 01:00:35 2010
From: report at bugs.python.org (Timothee Besset)
Date: Mon, 19 Apr 2010 23:00:35 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271718035.75.0.910322722106.issue6547@psf.upfronthosting.co.za>


Timothee Besset <ttimo at idsoftware.com> added the comment:

I am not sure what shutil does with symlinks already. At the very least it should not abort the operation.

Ideally I feel it should create the same symlink pointing to a possibly missing file, since that's what '/bin/cp' does, and shutil.copytree is broadly understood as a drop in replacement..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 01:08:11 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Apr 2010 23:08:11 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271718491.29.0.368460428962.issue6547@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> Ideally I feel it should create the same symlink pointing to a 
> possibly missing file, since that's what '/bin/cp' does, 
> and shutil.copytree is broadly understood as a drop in replacement..

That's what would happen if the symlink option is set to True.
When False, copytree() is supposed to copy the file pointed by the symlink, so copying the symlink as a fallback in case the file doesn't exists seems wrong to me in case symlink=False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 01:13:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 23:13:10 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271718790.4.0.0925740821903.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_gdb pass with add-conditions-for-gdb.Frame.select-to-trunk-003.patch.

In a new patch, or maybe a last version of the add-.... patch, could you move all "main" code at the end? I found these instructions:
----
# register Python pretty printer
register (gdb.current_objfile())

# register commands
PyList()
if hasattr(gdb.Frame, 'select'):
    # Not all builds of gdb have gdb.Frame.select
    PyUp()
    PyDown()
PyBacktrace()
PyPrint()
PyLocals()
----

Could you also document how libpython.py is loaded automatically, and can I load it manually?

Anyway, thanks for libpython: it really rocks! I often use gdb with Misc/gdbinit, but pystack does not always work, and pyo crashs if Python is not yet initialized. It will be easier to improve the gdb scripting if it's written in Python!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 01:23:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 23:23:06 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271719386.16.0.90692709375.issue8460@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The last line references, buf. It wont be available if a
> socket.timeout had happened. So, it can simply be moved to 
> the line below buf = f.read(). Attaching the patch with 
> these changes.

Good catch :-)

> Question: Were you able to simulate a timeout at kernel.org 
> site to test this? If yes, how?

I used a firewall rule. On Linux, you can try: iptables -I OUTPUT DROP to drop all output packets (and then iptables -F to remove all rules). It's not reliable, but the test does sometimes fail :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Tue Apr 20 01:25:09 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Mon, 19 Apr 2010 23:25:09 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1271719509.15.0.934934599383.issue2986@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I just stumbled on some seemingly different unexpected behaviour of
difflib.SequenceMatcher, but it turns out, it may have the same cause, i.e. the "popular" heuristics.
I hopefully managed to replicate it on an illustrative sample text - in as included in the attached file. (I also mentioned this issue in hte python-list 
http://mail.python.org/pipermail/python-list/2010-April/1241951.html but as there were no replies I eventually found, this might be more appropriate place.)
Both strings differ in a minimal way, each having one extra character
in a "strategic" position, which probably meets some pathological case
for difflib.
Instead of just reporting the insertion and deletion of these single
characters (which works well for most cases - with most other
positions of the differing characters), the output of the
SequenceMatcher decides to delete a large part of the string in
between the differences and to insert the almost same text after that.
The attached code simply prints the results of the comparison with the
respective tags, and substrings. No junk function is used.
I get the same results on Python 2.5.4, 2.6.5, 3.1.1 on windows XPp SP3.
I didn't find any plausible mentions of such cases in the documentation, but after some searching I found several reports in the bug tracker mentioning the erroneous output of SequenceMatcher on longer repetitive sequences.

besides this
http://bugs.python.org/issue2986
e.g.
http://bugs.python.org/issue1711800
http://bugs.python.org/issue4622
http://bugs.python.org/issue1528074

In my case, disabling the "popular" heuristics as mentioned by John Machin in
http://bugs.python.org/issue1528074#msg29269

seems to have solved the problem; with a modified version of difflib containing:

                if 0:   # disable popular heuristics
                    if n >= 200 and len(indices) * 100 > n:
                        populardict[elt] = 1
                        del indices[:]

the comparison catches the differences in the test strings as expected - i.e. one character addition and deletion only. It is likely, that some other use cases for difflib may rely on the "popular"-heuristics but it also seems useful to have some control over this behaviour, which might not be appropriate in all cases.
(The issue seems to be the same in python 2.5, 2.6 and 3.1.)

regards,
   vbr

----------
nosy: +vbr
Added file: http://bugs.python.org/file17001/difflib_test_inq.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Tue Apr 20 02:04:43 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 20 Apr 2010 00:04:43 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1271721883.4.0.905786715322.issue7992@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Marking closed, as promised; 2.7b1 has been out for nine days and there hasn't been a peep.  If new problems crop up from the capsule backport, please create a new issue and assign it to me.

For posterity: 2.7b1 shipped with a bsddb that still publishes a CObject.  This is the only CObject left in 2.7b1, and Python doesn't itself use that CObject for anything.  Therefore there are no CObject exploits left in pure Python 2.7b1.  I don't know if bsddb will switch to a capsule in a later Python 2.7 beta; that's up to Jesus and Benjamin and co.  But I suspect it won't.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Tue Apr 20 02:25:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 00:25:31 +0000
Subject: [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: <1271723131.17.0.0377792913147.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch:
 - Some parts have been applied in other issues
 - Remove assert(PyBytes_Check(x)): support PyByteArray type
 - use PyErr_Format() instead of sprintf+PyErr_SetString in tokenizer.c
 - don't convert message to byte and then back to unicode in err_input(): keep the unicode object

----------
Added file: http://bugs.python.org/file17002/surrogates-7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 02:27:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 00:27:55 +0000
Subject: [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: <1271723275.69.0.829876327744.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16919/surrogates-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 02:28:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 00:28:20 +0000
Subject: [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: <1271723300.66.0.0363060369584.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

$ diffstat ~/surrogates-7.patch
 Doc/library/tarfile.rst     |   15 +--
 Include/moduleobject.h      |    1
 Lib/platform.py             |   12 +-
 Lib/subprocess.py           |    2
 Lib/tarfile.py              |   14 --
 Lib/test/regrtest.py        |    5 -
 Lib/test/test_import.py     |    5 +
 Lib/test/test_reprlib.py    |    4
 Lib/test/test_subprocess.py |    4
 Lib/test/test_tarfile.py    |    4
 Lib/test/test_urllib.py     |    8 +
 Lib/test/test_urllib2.py    |    4
 Lib/test/test_xml_etree.py  |    6 +
 Lib/traceback.py            |   10 +-
 Lib/unittest/runner.py      |    4
 Modules/_ctypes/callproc.c  |   12 +-
 Modules/_ssl.c              |   10 +-
 Modules/_tkinter.c          |    6 -
 Modules/getpath.c           |  100 ++++++++++++++++++--
 Modules/main.c              |   46 +++++----
 Modules/posixmodule.c       |   18 ++-
 Modules/pyexpat.c           |   11 +-
 Modules/zipimport.c         |  210 ++++++++++++++++++++++++++++++++------------
 Objects/codeobject.c        |    7 +
 Objects/exceptions.c        |   49 ++++++----
 Objects/fileobject.c        |    6 -
 Objects/moduleobject.c      |   22 +++-
 Objects/unicodeobject.c     |   22 +++-
 Parser/tokenizer.c          |   18 ++-
 Python/_warnings.c          |   26 ++++-
 Python/ast.c                |   10 +-
 Python/bltinmodule.c        |   33 ++++--
 Python/ceval.c              |    4
 Python/compile.c            |   12 ++
 Python/errors.c             |    4
 Python/import.c             |   88 ++++++++++++------
 Python/pythonrun.c          |   39 ++++----
 Python/traceback.c          |   39 ++++++--
 38 files changed, 625 insertions(+), 265 deletions(-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 03:23:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 01:23:24 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271726604.25.0.649371474887.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

New patch, issue2706a.diff, implements timedelta % timedelta and addresses  Mark's code review comments.


With respect to Mark's
"""
One other thought:  with this division operation added, it might be nice to add constants like td_hour, td_minute, etc. to the module.  Then the perennial 'how can I convert my timedelta x to minutes' questions could be answered with 'just do x/td_minute'.  I would personally find x/td_second to be a more obvious and natural way to find the total number of seconds in a timedelta than x.total_seconds.  I also quite like the idea of being able to create a 2.5-hour timedelta with something like

2*td_hour + 30*td_minute

On the other hand, maybe such constants would just be added clutter, since it's easy to create them when needed.
"""

I dislike this proposal for the same reason as Mark likes it: 2*td_hour + 30*td_minute == timedelta(hours=2, minutes=30) is a violation of TOOWTDI.

----------
Added file: http://bugs.python.org/file17003/issue2706a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Tue Apr 20 03:24:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 01:24:38 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271726678.08.0.0311828992654.issue2706@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


Removed file: http://bugs.python.org/file16990/issue2706.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Tue Apr 20 04:49:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Apr 2010 02:49:33 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271731773.18.0.936172731293.issue8424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just to be clear, the freebsd6 problem was unrelated (presumably).  Freebsd7 seems to be suffering from the issue discussed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Tue Apr 20 05:03:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Apr 2010 03:03:18 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>
Message-ID: <1271732598.29.0.433365047198.issue8191@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Alexander, do you think it would be worthwhile to write up a summary of all the issues involved in these three releated bugs and post it to python-dev?  Alternatively we could ask for a decision on what should be done in python 2.7 from Benjamin.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Tue Apr 20 05:21:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 03:21:37 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1271732598.29.0.433365047198.issue8191@psf.upfronthosting.co.za>
Message-ID: <q2xd38f5331004192021occf8e72bh882faade53d49c0c@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Mon, Apr 19, 2010 at 11:03 PM, R. David Murray
<report at bugs.python.org> wrote:
>
> Alexander, do you think it would be worthwhile to write up a summary of all the issues
> involved in these three releated bugs and post it to python-dev?

Sure.  I ranted about a related issue8154 on python-dev in a not so
relevant message:

http://mail.python.org/pipermail/python-dev/2010-March/098600.html

and can follow up with a more on-topic post unless you beat me to it.

> ?Alternatively we could ask for a decision on what should be done in python 2.7 from
> Benjamin.

I would much rather see os.exec* functions left unchanged in both 2.x
and 3.x series except possibly for Windows where  issue8154 is a bona
fide crash.  Lets see what python-dev has to say about this feature in
general first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Tue Apr 20 06:26:09 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 20 Apr 2010 04:26:09 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271737565.16.0.219151301863.issue8451@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Antoine: I believe I have everything you mentioned addressed with the new patch.  That was an awesome review, thank you so much.

The only things I didn't do were parts of the last two items you bring up:

If PyTuple_New(0) fails, bail out.
If syslog_openlog fails, bail out.

syslog(3) can continue even if the openlog() fails.  It won't have the expected "ident" string, but it *WILL* log.

I believe this is the desired behavior.

NOTE: I puled the code out that does all the sys.argv handling, which I think made that whole section of code much easier to read, particularly with the new changes.  The down side is that the code to be reviewed is quite different now.

I also found a leak in the call to syslog_openlog() where I wasn't DECREFing the return.

Can you please review these changes?

----------
Added file: http://bugs.python.org/file17004/syslog-kwargs3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Tue Apr 20 07:34:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 05:34:09 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271741649.86.0.878951160745.issue8437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Folks, can we please focus at one issue at a time? I'm not sure I understand the issue that this patch is supposed to fix; in any case, I can report that it doesn't fix *this* issue. I'm still getting the very same failures after applying the patch.

Victor, please don't hijack existing bug reports for new issues. If you have a new issue, create a new bug report. They are really cheap to get :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 07:38:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 05:38:00 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271741880.99.0.872891205001.issue8453@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I personally can't verify what version of Xcode is installed. David?

In any case, David reported that he could build installers just fine on that very machine before r80179, but not after.

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 07:46:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 05:46:00 +0000
Subject: [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: <1271742360.92.0.350016935548.issue8242@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I haven't reviewed the patch in detail yet, but it seems to me that it fixes independent issues. -1000 on that. One problem, one bug report in the tracker, one commit.

If this issue is about the import machinery not working anymore if there is a non-ASCII character in the path, then why the heck does it touch posixmodule.c????

As for modules that have non-ASCII characters in their module name: this is, again, an unrelated issue (ISTM), so if you want to deal with it, please create a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 07:50:31 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 20 Apr 2010 05:50:31 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271742631.72.0.338047719863.issue8453@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

I believe it's XCode 2.4.1.

I know the script worked fine prior to the change that clears the environment, and commenting out just that piece of the latest trunk copy continues to work.

To be honest, I'm not sure how the build even finds gcc-4.0 (e.g., why it doesn't fail until ld) once PATH is cleared, nor do I fully understand the change.  How is the process supposed to work without a PATH?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 07:59:18 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 05:59:18 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271743158.33.0.0164825856843.issue8453@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

r80232 explicitly sets $PATH to the system default one, which hopefully fixes the issue.

What would be interesting to know is which shell is the user shell on the buildbot. The original patch worked for me because my shell is bash and bash sets a default $PATH when it doesn't have one on startup, other shells might not be as friendly as that.

That default value contains unwanted locations though (in particular /usr/local and /usr/gnu), which is why r80232 is a good idea anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 08:14:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 06:14:15 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271744055.06.0.480890443179.issue8453@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That fixes it indeed, see

http://www.python.org/dev/buildbot/builders/2.7.dmg/builds/11/steps/compile/logs/stdio

As for "which shell is being used": the slave reports that in his environment, there is

SHELL=/bin/bash

Not sure whether this actually means that new shells that get started are /bin/bash, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 08:14:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 06:14:29 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271744069.29.0.554592566892.issue8453@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 08:16:10 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 20 Apr 2010 06:16:10 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271744170.27.0.91779619219.issue8453@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

The buildbot user's shell is also bash, so not entirely sure yet why it's behaving differently in my environment.  I had completely forgotten about bash having a default path.

I do agree that explicitly setting a minimal path is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 08:35:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 20 Apr 2010 06:35:56 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271745356.43.0.780665586786.issue8453@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

+1.  Thanks, all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 08:44:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 06:44:47 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271745887.44.0.309552084952.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm not sure I understand the issue that this patch is supposed 
> to fix

It should fix all test_gdb errors :-)

> in any case, I can report that it doesn't fix *this* issue. 
> I'm still getting the very same failures after applying the patch.

The "'gdb.Frame' object has no attribute 'function'" error? Could you copy/paste the output of test_gdb?

--

Sorry for the issue hijaking, I will open a new issue ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 08:56:36 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 20 Apr 2010 06:56:36 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271746596.27.0.290255216195.issue8460@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Committed revision 80236 in the trunk. The build-bots should not hang now. Shall merge to other branches too.

----------
assignee:  -> orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Tue Apr 20 09:11:03 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 20 Apr 2010 07:11:03 +0000
Subject: [issue8464] tarfile creates tarballs with execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1271747463.25.0.250528773937.issue8464@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

0666 is the right mode and the patch is correct.

@Tarek: Why does shutil.make_archive() use mode "w|..." instead of "w:..."? IMHO that is not necessary, because it works on regular files only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8464>
_______________________________________

From report at bugs.python.org  Tue Apr 20 09:25:48 2010
From: report at bugs.python.org (Alexandre Conrad)
Date: Tue, 20 Apr 2010 07:25:48 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1271748348.52.0.289032518713.issue8190@psf.upfronthosting.co.za>


Changes by Alexandre Conrad <alexandre.conrad at gmail.com>:


----------
nosy: +aconrad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Tue Apr 20 10:01:28 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 08:01:28 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271750488.75.0.64688161599.issue6547@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

So, here's what I am planing to do after a little thought:

When a dangling symlink occurs and symlinks=false, copytree() will just emit a warning, unless the onerror option (new option) is set to a callable. In that case it will receive the src/dst values, and it will be up to the developer to decide what to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 10:04:31 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 08:04:31 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271750671.22.0.964001329453.issue6547@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 10:13:57 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 08:13:57 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271751237.9.0.478484663541.issue6547@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Please ignore my last message.

I've written a test for your error, and it turns out that the error is caught and just raised at the end of the process, meaning that everything else was copied before you get the exception.

So shutil.copytree didn't fail.

Now, the behavior is a little bit hard for this case, so I am going to add an option to ignore errors when a dangling symlink is found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 10:28:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 20 Apr 2010 08:28:21 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271752101.28.0.409730291062.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed fix (with the freebsd6 skips intact) in r80238, r80239, r80240
and r80241.



David, is it intentional that py3k doesn't have the freebsd6 fixes?

----------
assignee:  -> skrah
resolution:  -> accepted
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Tue Apr 20 10:55:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 08:55:15 +0000
Subject: [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: <1271753715.96.0.942364011524.issue8095@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed my proposed fix in r80243 (trunk)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8095>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:07:18 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 09:07:18 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271754438.93.0.683494866813.issue6547@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Added in r80244. This new option willl be available in the next 3.2 release. Until 3.2 is released, what you can do is catch the errors
and re-raise the ones that are not due to dangling symlinks:

(not tested)

>>> from shutil import copytree, Error
>>> try:
...     shutil.copytree('../test', '../test2')
... except Error, e:
...     for src, dst, error in e.args[0]:
...         if not os.path.islink(src):
...             raise
...         else:
...             linkto = os.readlink(srcname)
...             if os.path.exists(linkto):
...                 raise
...         # dangling symlink found.. ignoring..
...

----------
status: open -> closed
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:21:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 09:21:00 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1271755260.98.0.311502813077.issue7969@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I agree with all your points. 

The copystat error can be fixed right away and applied for 2.6 to 3.x

For other points, I'll change the way the Error works but this will require an heavy deprecation process.

In the meantime I can document the behavior, and provide some examples in the documentation (eg how to catch and manage the errors that were raised)

----------
assignee:  -> tarek
nosy: +tarek
priority:  -> normal
resolution:  -> accepted
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:26:09 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 09:26:09 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1271755569.47.0.709466665099.issue4489@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Mart,

I took over the maintenance of shutil, if you are interested in contributing a bullet-proof version of rmtree, please drop a line at python-ideas, and let's see what we can do in a new function maybe.

I'll be happy to review and apply patches if we get a consensus

----------
assignee:  -> tarek
nosy: +tarek
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.3, Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:28:23 2010
From: report at bugs.python.org (Anthon van der Neut)
Date: Tue, 20 Apr 2010 09:28:23 +0000
Subject: [issue8466] typo in tp_name of cStringIO
In-Reply-To: <1271755703.18.0.103883949918.issue8466@psf.upfronthosting.co.za>
Message-ID: <1271755703.18.0.103883949918.issue8466@psf.upfronthosting.co.za>


New submission from Anthon van der Neut <anthon at mnt.org>:

if you execute the following code from 
  cStringIO import StringIO
  x = StringIO()
  x.get_value()
you will see that the AttributeError line has a typo
it displays 'cStringIO.StringO' instead of 'cStringIO.StringIO'
this error is in line 529 of the Modules/cStringIO.c code (of 2.7b1)

----------
components: Library (Lib)
messages: 103687
nosy: anthon
severity: normal
status: open
title: typo in tp_name of cStringIO
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8466>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:30:21 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 09:30:21 +0000
Subject: [issue1355826] shutil.move() does not preserve ownership
Message-ID: <1271755821.58.0.439740912012.issue1355826@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That's because there's no simple, portable way to copy all metadata.

If you need to copy all of them you will need to use OS-specific APIs

----------
assignee:  -> tarek
nosy: +tarek
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1355826>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:30:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 09:30:30 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271755830.31.0.889985593341.issue8460@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Don't you port the fix to py3k?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:31:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 09:31:36 +0000
Subject: [issue1145257] shutil.copystat() may fail...
Message-ID: <1271755896.71.0.221621470213.issue1145257@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
nosy: +tarek
resolution:  -> accepted
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1145257>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:32:30 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 09:32:30 +0000
Subject: [issue1666318] shutil.copytree doesn't preserve directory permissions
Message-ID: <1271755950.66.0.110796662986.issue1666318@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666318>
_______________________________________

From report at bugs.python.org  Tue Apr 20 11:55:51 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 20 Apr 2010 09:55:51 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271757351.09.0.491602811886.issue8460@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, definitely it needs to be ported. I realized that, py3k was in a bad shape at moment.

File "Lib/test/test_urllib2net.py", line 151, in _test_urls
    import logging
File "/home/senthil/python/py3k/Lib/logging/__init__.py", line 43, in <module>
    import threading
File "/home/senthil/python/py3k/Lib/threading.py", line 34, in <module>
    TIMEOUT_MAX = _thread.TIMEOUT_MAX
AttributeError: 'module' object has no attribute 'TIMEOUT_MAX'

This is without the patch in.
I was looking at what was wrong there, and once that is fix, merging this change to py3k would be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Tue Apr 20 12:22:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 20 Apr 2010 10:22:49 +0000
Subject: [issue8466] typo in tp_name of cStringIO
In-Reply-To: <1271755703.18.0.103883949918.issue8466@psf.upfronthosting.co.za>
Message-ID: <1271758969.88.0.83814234826.issue8466@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

>From issue 8121:

That name is actually correct.  cStringIO features two different types, depending on whether you call cStringIO.StringIO() with or without an argument.  One is called "StringI", the other "StringO".

----------
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8466>
_______________________________________

From report at bugs.python.org  Tue Apr 20 12:48:16 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 20 Apr 2010 10:48:16 +0000
Subject: [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271760496.59.0.917193647654.issue8460@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

make distclean erased the problem. :) merged to py3k in r80256 and release31-maint in r80257. Had merged to release26-maint in r80237

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8460>
_______________________________________

From report at bugs.python.org  Tue Apr 20 13:16:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 11:16:16 +0000
Subject: [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: <1271762176.62.0.768219018214.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +utf8, backslashreplace and surrogates

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 13:20:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 11:20:46 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271762446.6.0.598207092846.issue8424@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan, you move too fast!  I was going to review that second patch, honest!

I'm not 100% sure (David can probably confirm), but I think your sys.stdout.write should be a sys.stderr.write.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:02:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:02:55 +0000
Subject: [issue8467] subprocess: surrogates of the error message (Python
	implementation on non-Windows)
In-Reply-To: <1271764975.75.0.223846589239.issue8467@psf.upfronthosting.co.za>
Message-ID: <1271764975.75.0.223846589239.issue8467@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

On a non-Windows OS where _posixsubprocess is missing (subprocess uses the pure Python implementation), if the child fails with a Python exception and the exception message contains a surrogate character, message.encode() fails silently (exception while processing exceptions are just ignored).

Surrogates should be passed to the parent process: surrogatepass can be used for that. Attached patch implements this idea with an unit test.

--

_posixsubprocess is not concerned because it writes an empty message for OSError (the parent process calls os.strerror() to get the message) or "Exception occurred in preexec_fn." (pure ASCII string) for RuntimeError.

On Windows, _subprocess.CreateProcess() calls PyErr_SetFromWindowsErr() on failure without the filename. So there is no surrogates here.

----------
components: Library (Lib)
files: subprocess_errmsg.patch
keywords: patch
messages: 103694
nosy: haypo
severity: normal
status: open
title: subprocess: surrogates of the error message (Python implementation on non-Windows)
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17005/subprocess_errmsg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8467>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:03:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:03:03 +0000
Subject: [issue8467] subprocess: surrogates of the error message (Python
	implementation on non-Windows)
In-Reply-To: <1271764975.75.0.223846589239.issue8467@psf.upfronthosting.co.za>
Message-ID: <1271764983.21.0.176207745829.issue8467@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8467>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:03:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:03:16 +0000
Subject: [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: <1271764996.19.0.649526125235.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +subprocess: surrogates of the error message (Python implementation on non-Windows)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:10:09 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 20 Apr 2010 12:10:09 +0000
Subject: [issue8465] Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271765409.29.0.0465526114309.issue8465@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Octal escapes are at most 3 octal digits, so the normal way to handle "\41" + "1" is "\0411".

Some languages support variable-length hex escapes of the form "\x{1B}", so we could add that and also "\o{41}" for octal.

BTW, in some languages "\e" is "\x1B".

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:12:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:12:49 +0000
Subject: [issue8468] bz2: support surrogates in filename,
	and bytes/bytearray filename
In-Reply-To: <1271765569.25.0.596764444797.issue8468@psf.upfronthosting.co.za>
Message-ID: <1271765569.25.0.596764444797.issue8468@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

bz2 uses "s" format to parse the filename argument: it uses the default (unicode) encoding to encode the unicode filename to a byte string. It should use the default file system encoding instead.

It should also support surrogates in unicode filename and bytes/bytearray filenames.

Attached patch uses PyUnicode_FSConverter() to implement that.

----------
components: Library (Lib), Unicode
files: bz2_surrogates.patch
keywords: patch
messages: 103696
nosy: haypo
severity: normal
status: open
title: bz2: support surrogates in filename, and bytes/bytearray filename
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17006/bz2_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8468>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:12:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:12:56 +0000
Subject: [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: <1271765576.62.0.362872542588.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +bz2: support surrogates in filename, and bytes/bytearray filename

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:20:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:20:45 +0000
Subject: [issue8242] Improve support of PEP 383 (surrogates) in Python3:
	meta-issue
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1271766045.63.0.571365334536.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I haven't reviewed the patch in detail yet, but it seems to me that
> it fixes independent issues.

Right. First I only wanted to fix import machinery, but then I fixed a lot of "indenpendent" issues to test the patch on import. All fixes are related to surrogates. I'm splitting the big patch into small parts: see the dependency list of this issue.

I will open a new issue for the import machinery. But this patch requires extra changes which are now discussed in new issues.

> (...) why the heck does it > touch posixmodule.c?

I opened issue #8391 for this change: "os.execvpe() doesn't support surrogates in env".

----------
title: Support surrogates in import ; install Python in a non-ASCII directory -> Improve support of PEP 383 (surrogates) in Python3: meta-issue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:26:42 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 20 Apr 2010 12:26:42 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271766402.05.0.24504448845.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, sorry, let me know if I should revert anything.

I took the stdout over from some similar print statements that
once were in test_uuid (I agree that stderr would seem more
natural).

[http://svn.python.org/view/python/trunk/Lib/test/test_uuid.py?r1=50896&r2=50949]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:30:50 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Tue, 20 Apr 2010 12:30:50 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

The struct module is often used (at least by me) to implement protocols  and binary formats. That makes the exact sizes (number of bits/bytes) of the different types very important.

Please add the sizes to for example the table on http://docs.python.org/library/struct . I know that some of the sizes varies with the platform, and in these cases it is fine to define it in terms of the C types, but for Python programmers writing cross-platform code such variable types doesn't matter and are "never" used. (I assume that it is possible to specify all possible types in a cross-platform way, but I'm not sure and the answer is not obvious from the documentation.)

----------
components: Library (Lib)
messages: 103699
nosy: kiilerix
severity: normal
status: open
title: struct - please make sizes explicit
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:42:03 2010
From: report at bugs.python.org (Julian Andres Klode)
Date: Tue, 20 Apr 2010 12:42:03 +0000
Subject: [issue6483] Modules are not deallocated correctly if m_size = -1
In-Reply-To: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>
Message-ID: <1271767323.93.0.376802278858.issue6483@psf.upfronthosting.co.za>


Julian Andres Klode <jak at jak-linux.org> added the comment:

This bug still exists in Python 3.1.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6483>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:49:52 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 20 Apr 2010 12:49:52 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271767792.5.0.939523569404.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The Tiger buildbot triggers the message in build #31:

test_signal
test_itimer_virtual: timeout: likely cause: machine too slow or load too high.


But build #23 is ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Tue Apr 20 14:58:56 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 20 Apr 2010 12:58:56 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271768336.48.0.239541928742.issue7332@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> Does Ubuntu use a small stack size?

it's 8192 on all architectures.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 15:05:04 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 20 Apr 2010 13:05:04 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271768704.54.0.956622622526.issue7332@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

I'm told it's 10240 on Fedora 12, x86 and x86_64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 15:11:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 13:11:11 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271769071.65.0.442926804361.issue7332@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Allocate more than 16 bytes on the stack is never a good idea. Eg. Linux does never resize the size automatically, and the only way to catch "allocatation failed" error is to handle the SIGSEGV signal...

Remove buf allocated on the stack by a buffer allocated on the heap is definitly a good ide :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 15:14:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 13:14:47 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271769287.18.0.191541179441.issue7332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A 16KB stack buffer is tiny compared to a 8MB stack. I'm not sure removing that buffer would really fix the problems.
Perhaps other threads get a smaller stack?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 15:27:42 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 20 Apr 2010 13:27:42 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271770062.49.0.725531058689.issue8451@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

A couple of points:

Didn't we decide that instead of using:
  openlog(ident[, logopt[, facility]])
we'd use:
  openlog(ident, logopt=None, facility=None)
(or whatever the defaults are)? I can't find a reference, but the argument was that it's how Python signatures are written, so it's clearer if they're all written this way.

You should add some comments to syslog_get_argv explaining why you're handling errors the way you are. That is, why you're swallowing exceptions and continuing. Similarly with the call to PyTuple_New(0).

I also think it would be clearer if using the string "python" were inside syslog_get_argv, but that's a style thing.

Should the fallback be "python", or derived from C's argv[0]?

Is it possible that sys.argv[0] would be unicode?

Is SEP correct, or should it really be using os.path.sep and/or os.path.altsep? This is probably a nit, but I could see it being a problem under cygwin (which I haven't tested yet).

Your "if" statements shouldn't all be on one line. The single-line style with braces isn't used anywhere else in this module, and it's not in the Python code base that I could see (except for the occasional macro).

The example code has some extra spaces around the equal signs. It should be:
   syslog.openlog(logopt=syslog.LOG_PID, facility=syslog.LOG_MAIL)

Thanks for doing this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Tue Apr 20 15:43:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 13:43:59 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271771039.78.0.649080213739.issue7332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What's the value of MAXPATHLEN and PATH_MAX on those systems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 15:47:00 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 20 Apr 2010 13:47:00 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271771220.8.0.392283554955.issue7332@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

The problem is highlighted with recursive imports:
a module which imports another module, which imports another module, etc. PyMarshal_ReadLastObjectFromFile is not the only function to use stack-allocated buffers, there are also load_source_module, load_package, import_module_level, which use char buf[MAXPATHLEN+1]: with a MAXPATHLEN to 1024, you lose 2 or 3K every time you do a recursive import.
And, as has been said, it might very well happen that new threads get a reduced stack size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 15:57:40 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 20 Apr 2010 13:57:40 +0000
Subject: [issue6600] MemoryError in AiX 64-bit - PyMem_MALLOC fails in
	open/fdopen
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1271771860.88.0.166176699798.issue6600@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It really looks like a broken compiler: if you want to convince yourself, perform a disassembly of the crashing code.
I'd suggest to close this one.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:00:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 14:00:10 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1271771220.8.0.392283554955.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271772137.3523.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The problem is highlighted with recursive imports:
> a module which imports another module, which imports another module,
> etc. PyMarshal_ReadLastObjectFromFile is not the only function to use
> stack-allocated buffers, there are also load_source_module,
> load_package, import_module_level, which use char buf[MAXPATHLEN+1]:
> with a MAXPATHLEN to 1024, you lose 2 or 3K every time you do a
> recursive import.

Let's assume we lose ten times 1024 bytes, that's still only 10KB. The
stack is 8MB. We are argueing about less than 1% of the total stack
size.

I just went through all of the functions highlighted in one of these
stack traces (*). The only big consumers of stack space seem to be the
stack buffer in PyMarshal_ReadLastObjectFromFile, and the various file
path buffers using MAXPATHLEN.

(*) https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/432546

And that report shows only a single thread, so I have to assume that the
8MB figure applies there.

Nevertheless, we can remove the stack buffer since it's probably
useless. It just seems unlikely to me to be the root cause of the stack
overflow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:11:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 14:11:04 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1271772664.03.0.0498671328062.issue8124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another solution: disable call to PyErr_CheckSignals() in mywrite().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:11:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 14:11:41 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1271772701.43.0.851578010879.issue8469@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

It is very easy to generate the size table programmatically:

>>> for c in "xcbB?hHiIlLqQfdspP":
...     print(c, struct.calcsize(c))
... 
x 1
c 1
b 1
B 1
? 1
h 2
H 2
i 4
I 4
l 8
L 8
q 8
Q 8
f 4
d 8
s 1
p 1
P 8

However, all values above except trivial 1-byte entries are platform dependent and C types are already well documented.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:17:29 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 14:17:29 +0000
Subject: [issue8395] shutil.copytree() add a copy_func parameter.
In-Reply-To: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>
Message-ID: <1271773049.67.0.803841726328.issue8395@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I have just added this feature yesterday, see #1540112.

Thanks!

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Allow choice of copy function in shutil.copytree

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8395>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:19:39 2010
From: report at bugs.python.org (Timothee Besset)
Date: Tue, 20 Apr 2010 14:19:39 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271773179.64.0.392266745643.issue6547@psf.upfronthosting.co.za>


Timothee Besset <ttimo at idsoftware.com> added the comment:

Good stuff. Didn't occur to me that the operation could have successfully completed before raising the exception

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:20:33 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 14:20:33 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271773233.13.0.851631771325.issue6547@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for your work on Quake btw ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:25:12 2010
From: report at bugs.python.org (resc)
Date: Tue, 20 Apr 2010 14:25:12 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1271527897.39.0.0595609721075.issue7332@psf.upfronthosting.co.za>
Message-ID: <j2qcfb5a3d21004200725v16cb3f87gde39b031936bdd2d@mail.gmail.com>


resc <thomathom at gmail.com> added the comment:

Hi,
I'm working on reproducing this again, but it's always been a very
sporadic bug, and I haven't gotten a bingo yet.

- return the result of "ulimit -s" on their box
8192

- return the result of "ltrace -e pthread_attr_setstacksize <command
used to start program>"
There's no output from ltrace when I do this (except "exited (status
0)"), so I guess that function isn't called.

I wish I had a test case that would trigger the bug more reliably...
-Thomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:25:59 2010
From: report at bugs.python.org (Timothee Besset)
Date: Tue, 20 Apr 2010 14:25:59 +0000
Subject: [issue6547] shutil.copytree fails on dangling symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1271773559.91.0.881806831416.issue6547@psf.upfronthosting.co.za>


Timothee Besset <ttimo at idsoftware.com> added the comment:

My pleasure! We do use a lot of python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:27:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 14:27:57 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1271773677.77.0.85100104771.issue7150@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

My patch includes unit tests and I tested it on Mac OS X.  Anand, what kind of testing do you have in mind?

----------
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:28:44 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 20 Apr 2010 14:28:44 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271773724.35.0.364144602782.issue7332@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

PATH_MAX/MAXPATHLEN is 4096

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:30:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 14:30:47 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1271773847.98.0.0348498965653.issue8469@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

As Alexander says, *all* the sizes except those for bytes are platform-dependent:  there are platforms where sizeof(short) isn't 2, for example, or where sizeof(int) isn't 4.

It would be possible to add the 'standard' sizes to that table (i.e. the sizes that you get when using '<', '>', etc.);  would that be helpful?  If you're trying to write cross-platform code then you should probably be using standard size, alignment and byte order anyway.

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:33:25 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Apr 2010 14:33:25 +0000
Subject: [issue8295] add unpack_archive to shutil
In-Reply-To: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>
Message-ID: <1271774005.22.0.19187093612.issue8295@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> accepted
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8295>
_______________________________________

From report at bugs.python.org  Tue Apr 20 16:44:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 14:44:32 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271773847.98.0.0348498965653.issue8469@psf.upfronthosting.co.za>
Message-ID: <q2yd38f5331004200744n1f551218r13305ac2e4bbdcdc@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Apr 20, 2010 at 10:30 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> It would be possible to add the 'standard' sizes to that table (i.e. the sizes that you get when using '<', '>', etc.); ?would that be helpful?

The documentation already includes standard sizes in text:

"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."

It may be helpful to add "Standard size" column to the code table with
a footnote that it only applies when <, > or ! code is used and that
for native sizes one should consult struct.calcsize().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:01:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Apr 2010 15:01:44 +0000
Subject: [issue8453] build_installer.py breaks bzip compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271775704.01.0.884635086359.issue8453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think bash itself has a default path, I think the default path is set by the system bash profile, and is therefore system dependant.  I could be wrong, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8453>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:13:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Apr 2010 15:13:52 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271776432.28.0.552832728948.issue8424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The only reason the freebsd6 skips aren't in py3k is that I wanted to make sure they worked first, and then I was on vacation and haven't gotten to the merge yet.  If you want to merge your patch before I get to it, feel free to merge mine along with yours.

For 2.6 writing to stderr is indeed better (maybe even requried; I forget if the regrtest stdout check is still in 2.6...I think it probably is).

For 2.7/3.x, I think you should raise a unittest.SkipTest instead, so that it will be counted as a skipped test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:27:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Apr 2010 15:27:13 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271777233.69.0.980141668356.issue8451@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The argument documentation style change was made for py3k.  The old convention is still used in the 2.x docs.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:28:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 15:28:17 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1271777297.91.0.788788195978.issue1083@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

This is certainly not a bug, so I don't think targeting 2.7 is appropriate.  I have explained in a comment on issue2706 (see msg75917) why I believe true division of timedelta by int should not be supported.  In short, true division of timedelta by int is supposed to return fractional number of microseconds, but python lacks a type that can represent it.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:29:09 2010
From: report at bugs.python.org (phep)
Date: Tue, 20 Apr 2010 15:29:09 +0000
Subject: [issue8470] Let cmd.cmd.intro be unicode friendly
In-Reply-To: <1271777349.17.0.192920763608.issue8470@psf.upfronthosting.co.za>
Message-ID: <1271777349.17.0.192920763608.issue8470@psf.upfronthosting.co.za>


New submission from phep <patrice.pillot at teletopie.net>:

Since cmd.cmdloop() says:

# ...
self.stdout.write(str(self.intro)+"\n")
# ....

one cannot use unicode characters in cmd.cmd.intro, for example the copyright (?) character (u'\xa9').

TIA

----------
messages: 103726
nosy: phep
severity: normal
status: open
title: Let cmd.cmd.intro be unicode friendly
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8470>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:31:00 2010
From: report at bugs.python.org (Aaron Sherman)
Date: Tue, 20 Apr 2010 15:31:00 +0000
Subject: [issue8465] Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271777460.54.0.452370017601.issue8465@psf.upfronthosting.co.za>


Aaron Sherman <ajs at ajs.com> added the comment:

Matthew, thank you for replying. I still think the primary issue is the potential for confusion between single digit escapes and backreferences, and the ease with which they could be addressed, but to cover what you said:

Quote: the normal way to handle "\41" + "1" is "\0411"

That might be the way dictated by the limitations of escape expansion as it is now, but it's entirely non-intuitive and seems more like the "exciting" edge cases (and obfuscated code opportunities) in other languages than something Python would be proud of.

With \41\e1 you would actually be able to tell, visually that the 1 does not get read by the code which reads the \41. This seems to me to be a serious win for maintainability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:41:13 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 20 Apr 2010 15:41:13 +0000
Subject: [issue8471] Unicode returns in doctest can make subsequent tests fail
In-Reply-To: <1271778073.88.0.928922878854.issue8471@psf.upfronthosting.co.za>
Message-ID: <1271778073.88.0.928922878854.issue8471@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

If we return unicode, SpoofOut's buf variable becomes automagically converted to unicode. This means all subsequent output becomes converted to unicode, and if the output contains non-ascii characters that fails.

That means that 

    >>> print u'\xe9'.encode('utf-8')
    ?

Will work just fine, but

    >>> print u'abc'
    abc

    >>> print u'\xe9'.encode('utf-8')
    ?

Will fail.

    
The reason for this is that when "resetting" the doctest output only a truncate(0) is done, so the buf variable will continue to be unicode. I include tests + a patch that will set self.buf to '' if empty when trunkated. Other options are also possible, like changing the .truncate(0) to a .buf = '' but that's ugly, or adding a reset() method on SpoofOUt.

----------
components: Extension Modules, Tests
files: doctest_unicode.patch
keywords: patch
messages: 103728
nosy: lregebro
severity: normal
status: open
title: Unicode returns in doctest can make subsequent tests fail
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17007/doctest_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8471>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:44:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 20 Apr 2010 15:44:24 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1271778264.06.0.0902599162681.issue5243@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2 -Distutils
versions: +Python 2.5, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:52:27 2010
From: report at bugs.python.org (Alexandre Conrad)
Date: Tue, 20 Apr 2010 15:52:27 +0000
Subject: [issue8274] test_run failing
In-Reply-To: <1270044707.08.0.0364512730756.issue8274@psf.upfronthosting.co.za>
Message-ID: <1271778747.73.0.0307695741474.issue8274@psf.upfronthosting.co.za>


Alexandre Conrad <alexandre.conrad at gmail.com> added the comment:

worksforme:

test_run (distutils2.tests.test_build_clib.BuildCLibTestCase) ... ok

Python 2.6.2 on Ubuntu 9.04

----------
nosy: +aconrad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8274>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:54:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 20 Apr 2010 15:54:21 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1271778861.34.0.194307366532.issue5302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Tarek, could you briefly explain the arguments that convinced you?

If MANIFEST.in is removed, perhaps we could use convention instead of configuration to categorize files, like what DistutilsExtra does: http://bazaar.launchpad.net/~python-distutils-extra-hackers/python-distutils-extra/debian/annotate/head%3A/doc/README#L42

(Changing component and versions since Distutils is frozen)

Regards

----------
components: +Distutils2 -Distutils
nosy: +merwok
versions: +Python 2.5, Python 2.6, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Tue Apr 20 17:54:28 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 20 Apr 2010 15:54:28 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271778868.69.0.253141207561.issue8437@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 18:02:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 16:02:19 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1271779339.37.0.603568725323.issue1100942@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am +1 for adding these features and I have only one comment on the code:

It is documented in time.strptime() documentation that
"""
The default values used to fill in any missing data when more accurate values cannot be inferred are (1900, 1, 1, 0, 0, 0, 0, 1, -1). 
""" http://docs.python.org/dev/py3k/library/time.html#time.strptime

and "datetime.strptime(date_string, format) is equivalent to datetime(*(time.strptime(date_string, format)[0:6]))." according to datetime module documentation.

Thus, datetime.strptime("", "") returning datetime.datetime(1900, 1, 1, 0, 0) is not an implementation detail and there is no need to compute it in time_strptime.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Tue Apr 20 18:12:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 16:12:38 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1271779958.55.0.0592610644508.issue1100942@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

BTW, it does not bother me that "date.strptime() 
seems a bit odd, given that it cannot accept a time part."  To me "time" in strptime means time specification that may include date, time or even just month.  If parsed specification does not fit in date (includes time component), date.strptime fails.  There is nothing wrong with it.  An alternative would be to make {date,time}.strptime() promiscuous and just drop unneeded components, but that would make these functions less useful because such behavior is simply datetime.strptime(..).{date,time}().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Tue Apr 20 18:37:36 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Tue, 20 Apr 2010 16:37:36 +0000
Subject: [issue8472] itertools.filterfalse() function missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

The documentation (eg at http://docs.python.org/release/2.6.5/library/functions.html#filter) tells that there should be an itertools.filterfalse() function complementary to builtin filter() function, that returns the list of elements (instead of the iterator over them, as ifilterfalse() does), for which the condition is failed. This function is absent from Python 2.x branch (though obviously is present in 3.x, as all the i* functions are renamed to their non-i* counterparts).

----------
messages: 103733
nosy: honeyman
severity: normal
status: open
title: itertools.filterfalse() function missing
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8472>
_______________________________________

From report at bugs.python.org  Tue Apr 20 18:37:42 2010
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 20 Apr 2010 16:37:42 +0000
Subject: [issue4079] new urllib2.Request 'timeout' attribute needs to have a
	default
In-Reply-To: <1223490599.12.0.198174561396.issue4079@psf.upfronthosting.co.za>
Message-ID: <1271781462.59.0.101269562923.issue4079@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I'm ok with the proposed changes from Sidnei (yes, a patch is needed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4079>
_______________________________________

From report at bugs.python.org  Tue Apr 20 18:40:18 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 20 Apr 2010 16:40:18 +0000
Subject: [issue8473] doctest fails if you have inconsistent lineendings
In-Reply-To: <1271781617.9.0.374951389596.issue8473@psf.upfronthosting.co.za>
Message-ID: <1271781617.9.0.374951389596.issue8473@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

If the doctest file has both Windows and unix lineendings you get an error. Yeah, I know, it's not a serious bug, but it's also easy to fix.

Attached patch with test. Seems to not be an issue on Python 3.

----------
components: Extension Modules, Tests
files: doctest_lineendings.patch
keywords: patch
messages: 103735
nosy: lregebro
severity: normal
status: open
title: doctest fails if you have inconsistent lineendings
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17008/doctest_lineendings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8473>
_______________________________________

From report at bugs.python.org  Tue Apr 20 18:42:52 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Tue, 20 Apr 2010 16:42:52 +0000
Subject: [issue8472] itertools.filterfalse() function missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1271781772.03.0.232052653372.issue8472@psf.upfronthosting.co.za>


Changes by Alexander Myodov <amyodov at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8472>
_______________________________________

From report at bugs.python.org  Tue Apr 20 18:43:08 2010
From: report at bugs.python.org (Andres Moreira)
Date: Tue, 20 Apr 2010 16:43:08 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1271781788.38.0.91210125711.issue7946@psf.upfronthosting.co.za>


Changes by Andres Moreira <elkpichico at gmail.com>:


----------
nosy: +andrix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 20 19:06:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Apr 2010 17:06:15 +0000
Subject: [issue8472] itertools.filterfalse() function missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1271783175.64.0.287499587527.issue8472@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That line has been added first on py3k where the function is called 'itertools.filterfalse' and then ported to 2.x. Most likely the 'i' has been forgotten.
A new filterfalse function can't be added to 2.7 because it's already in beta.
I fixed the link to point to itertools.ifilterfalse() in r80270 and r80271.
Raymond, if you think that sentence should be rephrased, feel free to change it or reopen the issue.

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +ezio.melotti, georg.brandl, rhettinger
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8472>
_______________________________________

From report at bugs.python.org  Tue Apr 20 19:06:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 17:06:19 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271783179.63.0.625156825762.issue8437@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16997/add-conditions-for-gdb.Frame.select-to-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 19:06:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 17:06:23 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271783183.69.0.901357858604.issue8437@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16998/test_gdb-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 19:11:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 20 Apr 2010 17:11:50 +0000
Subject: [issue4843] make distutils use shutil
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1271783510.2.0.312921507829.issue4843@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This has been done in Distutils2, see  http://hg.python.org/distutils2/rev/18dc3dba4075 and http://hg.python.org/distutils2/rev/98b70f92bf0a

Changing component and closing the bug, please reopen if I?m wrong :)

Regards

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.5, Python 2.6, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Tue Apr 20 19:26:45 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Tue, 20 Apr 2010 17:26:45 +0000
Subject: [issue8472] itertools.filterfalse() function missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1271784405.84.0.28814428784.issue8472@psf.upfronthosting.co.za>


Alexander Myodov <amyodov at gmail.com> added the comment:

In this case, I'd suggest to rephrase it to "See :func:`itertools.ifilterfalse` for the complementary function that returns the iterator over the elements of *iterable* for which *function* returns false.", or even remove this line at all (because, ifilterfalse() is a complement to ifilter() rather than to filter()). But please don't leave this as it is now, as this is still confusing and misleading (filter returns a list, but ifilter and ifilterfalse return an iterator!).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8472>
_______________________________________

From report at bugs.python.org  Tue Apr 20 19:58:40 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 20 Apr 2010 17:58:40 +0000
Subject: [issue8474] Duplicate tests in email test suite
In-Reply-To: <1271786320.05.0.85623215859.issue8474@psf.upfronthosting.co.za>
Message-ID: <1271786320.05.0.85623215859.issue8474@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

In trunk/Lib/email/test/test_email.py, test_default_cte() is repeated twice, one being the subset of other. Attached patch resolve the duplicity.

----------
components: Library (Lib)
files: test_email.patch
keywords: patch
messages: 103739
nosy: barry, l0nwlf, r.david.murray
severity: normal
status: open
title: Duplicate tests in email test suite
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17009/test_email.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8474>
_______________________________________

From report at bugs.python.org  Tue Apr 20 20:26:40 2010
From: report at bugs.python.org (Noufal)
Date: Tue, 20 Apr 2010 18:26:40 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1271788000.75.0.777579985583.issue3132@psf.upfronthosting.co.za>


Changes by Noufal <noufal at nibrahim.net.in>:


----------
nosy: +noufal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Tue Apr 20 21:21:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Apr 2010 19:21:09 +0000
Subject: [issue8472] itertools.filterfalse() function missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1271791269.98.0.186588746094.issue8472@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Suggestion for Py2.x:

See :func:`itertools.ifilter` and :func:`itertools.ifilterfalse`
for iterator versions of this function, including a variation that filters for elements where the *function* returns *False*).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8472>
_______________________________________

From report at bugs.python.org  Tue Apr 20 21:36:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 19:36:44 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271792204.31.0.0637165902808.issue8092@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Apr 20 21:38:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 19:38:49 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271792329.1.0.52560935148.issue8092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version without the hardcoded limit: don't use goto encodeUCS4;, chain if to limit indentation depth: it only costs one copy of the UCS4 (5 lines are duplicated).

The buffer is now reallocated each time a surrogate escape is longer than 4 bytes.

I don't know if "nallocated += repsize - 4;" can overflow or not. If yes, how can I detect the overflow? I added: /* FIXME: check integer overflow? */

----------
Added file: http://bugs.python.org/file17010/utf8_surrogate_error-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:02:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 20:02:01 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271793721.75.0.259414014963.issue8437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm attaching the full output. It's the same as the one in the original report (msg103442) still.

----------
Added file: http://bugs.python.org/file17011/test_gdb.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:09:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:09:02 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1271794142.09.0.625655447653.issue5103@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Bill, I think we should move forward with this. Do you agree that removing the timeout dance is the right solution?

----------
nosy: +pitrou
priority:  -> high
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:18:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:18:07 +0000
Subject: [issue3597] Allow application developers to select ciphers,
	and default to strong in ssl lib
In-Reply-To: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>
Message-ID: <1271794687.75.0.128310079332.issue3597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I had never seen this issue but committed almost exactly the same feature in r80151. The parameters is named "ciphers" rather than "cipher_list" and allows you to override the allowed ciphers when creating an SSL object. It will be available in Python 2.7 and 3.2.

(note that OpenSSL itself defaults to what it considers strong ciphers, at least in the most recent versions)

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3597>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:19:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 20:19:49 +0000
Subject: [issue8393] subprocess: support undecodable current working directory
	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271794789.81.0.618428533939.issue8393@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Amaury, I fail to see how the error you get on Windows is related to this issue. AFAICT, neither the issue nor the patch affects Windows at all.

Closing the issue as fixed.

If you think there is also an issue on Windows, please submit a new bug report. However, I don't think the error you get is a bug: what you see is correct behavior.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8393>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:20:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 20:20:26 +0000
Subject: [issue8394] ctypes.dlopen() doesn't support surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271794826.0.0.479896026832.issue8394@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Amaury, I'm closing this for the same reason I explained in msg103745

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8394>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:31:55 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 20 Apr 2010 20:31:55 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1271795515.28.0.502866679459.issue8263@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Confirmed on FreeBSD-6.4/py3k. Threading causes the problem, the skip
works here, too.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:34:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:34:32 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1271795672.85.0.970600701256.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Too late for 2.7 now, but looks like a good idea.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> patch review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:40:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:40:51 +0000
Subject: [issue3596] Provide a way to disable SSLv2 (or better yet,
	disable by default)
In-Reply-To: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
Message-ID: <1271796051.91.0.26227225719.issue3596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The new "ciphers" argument in trunk and py3k should do the trick, shouldn't it?
Do note that starting with OpenSSL 1.0.0, SSLv2 is disabled by default when using the "SSLv23" client method (you can re-enable it by specifying "ALL" for the cipher list).

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> pending
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3596>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:45:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:45:56 +0000
Subject: [issue7927] SSL socket is not closed properly
In-Reply-To: <1266146726.16.0.222413736354.issue7927@psf.upfronthosting.co.za>
Message-ID: <1271796356.33.0.185702083289.issue7927@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Probably a duplicate of issue5238.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> ssl makefile never closes socket

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7927>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:46:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:46:50 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1271796410.37.0.4018531361.issue5238@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:47:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:47:52 +0000
Subject: [issue8109] Support for TLS Server Name Indication extension
In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za>
Message-ID: <1271796472.53.0.143436171228.issue8109@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Duplicate of issue5639.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> Support TLS SNI extension in ssl module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8109>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:48:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:48:46 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1271796526.16.0.99876764267.issue1926@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9298/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:48:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:48:49 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1271796529.53.0.493730205058.issue1926@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9309/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:51:35 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 20:51:35 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1271796695.82.0.159818707862.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch (for the trunk) fixes this issue on my machine.

The patch also fixes issue 8444.

I wouldn't mind some review of the patch, it does affect core bits of setup.py.

----------
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17012/issue7724.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:51:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 20 Apr 2010 20:51:39 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1271796699.04.0.226117972069.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I added an additional invalid test which David pointed out and made changes to invalid url checking code. I moved it more higher level.

- The reason for doing this is, invalid url test code (which is very specific for '[' enclosed ']' ipv6 url is concentrated at a single place). We can deal with parsing separately from check.

Now, other forms of Invalid URLs are possible as David points out (and possibly more too), but leaving it is better as it would unnecessarily add syntax-checks at various different places (instead of a single place), without much of value add.  Dealing with Valid URLs and a parse logic checking should be fine.

commits: trunk - r80277 and py3k - r80278

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:51:51 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 20:51:51 +0000
Subject: [issue8444] openssl version detection doesn't work properly when
	using OSX SDK
In-Reply-To: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>
Message-ID: <1271796711.16.0.655213572514.issue8444@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a patch that fixes this issue to issue 7724.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8444>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:52:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:52:20 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1271796740.21.0.150540254033.issue4870@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: accepted -> 
versions: +Python 3.2 -Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:54:06 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 20:54:06 +0000
Subject: [issue8461] PythonLauncher universal build fails due to missing -arch
	and -sysroot
In-Reply-To: <1271684622.87.0.695093789846.issue8461@psf.upfronthosting.co.za>
Message-ID: <1271796846.57.0.769006334049.issue8461@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've fixed this issue in all branches and can now do clean builds.

BTW. Builds with the 10.4u SDK on OSX fail at the moment for 2.7 and 3.2, that's due to issue 7724, I've attached a patch to that issue that should fix it (for the trunk, porting it to 3.2 should be trivial).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8461>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:54:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:54:48 +0000
Subject: [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1271796888.85.0.403418751319.issue4470@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:55:56 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 20:55:56 +0000
Subject: [issue8447] buildbot: test_httpservers failure (No module named
	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1271796956.51.0.799389523277.issue8447@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The test passes just fine on my machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8447>
_______________________________________

From report at bugs.python.org  Tue Apr 20 22:57:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 20:57:33 +0000
Subject: [issue967275] Better SSL support in socket module
Message-ID: <1271797053.82.0.901310885884.issue967275@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Too vague and probably outdated, closing.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue967275>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:00:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 21:00:58 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271797258.52.0.74008860156.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> in any case, I can report that it doesn't fix *this* issue

Did you applied the patch version 3? The first version didn't fixed is_evalframeex(), but the version 3 does.

Could you retry with the last patch (version 3)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:01:53 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 21:01:53 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1271797313.7.0.660943836842.issue7852@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree that the DTD should be changed.

Fixed in r80279 (trunk) and r80280 (3.2). 

I won't backport to 2.6 and 3.1 because this is a mostly cosmetic issue and I do not want to risk breaking existing scripts.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7852>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:03:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Apr 2010 21:03:06 +0000
Subject: [issue8459] buildbot: test_select failure
	(test_returned_list_identity) on Python 2.6, Windows
In-Reply-To: <1271679875.89.0.922749709725.issue8459@psf.upfronthosting.co.za>
Message-ID: <1271797386.84.0.714682865534.issue8459@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80281.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8459>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:04:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 21:04:56 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1271797496.55.0.851595612792.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

This is in a way more similar to issue1083 than to issue2706.  I am -1 on this RFE for the same reason as I am opposing allowing true division of timedelta by an int.  The timedelta type is fundamentally an integer type.  A type delta is just a certain number of microseconds.  A timedelta divided by a number or multiplied by a float is logically a fractional number of microseconds and python does not have a type to represent it.

Daniel's use case of passing timedeltas to a statistical packages is neatly addressed by issue2706's timedelta / timedelta (true) division.  Just strip the dimensionality from your data by dividing each time delta by a chosen unit interval (depending on the problem, a second, a microsecond or even a day may be appropriate).  The result will be a set of floats that your number crunching package will be happy to process.

Another advantage of this approach is that floats can be processed more efficiently than timedeltas with FP arithmetics and intermediate results will be more accurate in most cases.

I recommend accepting issue2706 and rejecting this issue together with issue2706.

----------
nosy: +Alexander.Belopolsky
type:  -> feature request
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:05:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 21:05:09 +0000
Subject: [issue8447] buildbot: test_httpservers failure (No module named
	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1271797509.54.0.635395030489.issue8447@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's probably something wrong in the way test_httpservers sets up its own environment (can it impact the import mechanism?). The operator module exists and imports correctly in other conditions, e.g. test_operator passes on that buildbot.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8447>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:05:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 21:05:51 +0000
Subject: [issue8444] openssl version detection doesn't work properly when
	using OSX SDK
In-Reply-To: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>
Message-ID: <1271797551.13.0.45296641382.issue8444@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like you forgot your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8444>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:06:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Apr 2010 21:06:26 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1271797586.75.0.874190818541.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I meant rejecting issue1083, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:08:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 21:08:37 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271797717.19.0.547681674811.issue8092@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16503/utf8_surrogate_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:08:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 21:08:52 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271797732.2.0.244280693392.issue8437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Yes, I did try with version 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:09:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 21:09:54 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271797794.58.0.927187826817.issue8092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't know if "nallocated += repsize - 4;" can overflow or not.
> If yes, how can I detect the overflow?

Sure, if they are both Py_ssize_t, just use:

if (nallocated > PY_SSIZE_T_MAX - repsize + 4) {
  /* handle overflow ... */
}

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:11:00 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 21:11:00 +0000
Subject: [issue8444] openssl version detection doesn't work properly when
	using OSX SDK
In-Reply-To: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>
Message-ID: <1271797860.84.0.357660410389.issue8444@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The patch is attached to issue 7724. As that issue notes the current version of setup.py ignores OSX SDKs during builds, the patch in that issue makes sure that setup.py looks in the SDK when looking for files (The patch also modifies distutils.unixccompiler to do the same when looking for library files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8444>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:13:57 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 20 Apr 2010 21:13:57 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1271798037.44.0.527384772875.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As a short explanation of OSX SDKs: those are basicly directories containing header files and stub libraries with the same directory structure as a real system. 

As an example, /Developer/SDKs/MacOSX10.4u.sdk contains the 10.4u SDK, that tree contains /Developer/SDKs/MacOSX10.4u.sdk/usr/include containing the header files that would have been in /usr/include on a canonical 10.4 system.

The SDK root is passed to the compiler using the '-isysroot' argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:14:50 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 20 Apr 2010 21:14:50 +0000
Subject: [issue4142] smtplib doesn't clear helo/ehlo flags on quit
In-Reply-To: <1224273762.79.0.0391835714009.issue4142@psf.upfronthosting.co.za>
Message-ID: <1271798090.76.0.562585718681.issue4142@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4142>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:19:56 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 20 Apr 2010 21:19:56 +0000
Subject: [issue3596] Provide a way to disable SSLv2 (or better yet,
	disable by default)
In-Reply-To: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
Message-ID: <1271798396.31.0.564628906329.issue3596@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3596>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:22:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 21:22:19 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1271798539.38.0.165445871815.issue7724@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a bunch of debug stuff in that patch ("if 1", commented out lines...).
Also, the patch should not change behaviour on non-OS X platforms, which is not obvious right now.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:26:33 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 20 Apr 2010 21:26:33 +0000
Subject: [issue3596] Provide a way to disable SSLv2 (or better yet,
	disable by default)
In-Reply-To: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
Message-ID: <1271798793.91.0.806128331386.issue3596@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3596>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:36:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 21:36:34 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1271799394.14.0.813793687703.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The timedelta type is fundamentally an integer type.

I disagree strongly with this, and find this a bizarre point of view.  Regardless of how the timedelta is stored internally, it's used to represent physical times.  I doubt there are many applications that care about the fact that each timedelta is an integral number of microseconds.

Multiplication or division of a time by a float or int makes perfect sense  physically, and I think it should be a legal operation here.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:37:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 21:37:48 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1271799468.17.0.361930270809.issue1083@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think it's fine to do the division and round the result to the nearest whole number of microseconds.  I don't see any good reason for disallowing timedelta / int (or even timedelta / float).

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:38:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 21:38:56 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1271799536.1.0.602376721627.issue1083@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
type: behavior -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:41:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 21:41:53 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1271799713.5.0.963134484082.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Not sure why this is marked for 3.3.

----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:44:04 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Apr 2010 21:44:04 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271799844.54.0.279130681384.issue8437@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The patch does make a slight difference for me - I go from 14 failures down to 8 failures and 6 skipped.

The post-patch failures appear to be the same ones Martin is getting: "test_gdb.get_stack_trace" is regularly failing due to the lack of "gdb.Frame.function".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:44:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 21:44:42 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1271799882.02.0.215667188726.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll take a look at Skip's patch.

----------
assignee:  -> skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:45:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 21:45:03 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1271799903.15.0.209012269443.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops.  I meant to assign this to me, not Skip.

----------
assignee: skip.montanaro -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:48:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 21:48:55 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271800135.21.0.610744000914.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand because after applying the patch, there is not occurence of ".function" in Tools/gdb/libpython.py nor Lib/test/test_gdb.py.

Do you have an old python-gdb.py file in your Python root directory? I noticed that I had such file in my python trunk checkout and py3k checkout. This file was maybe renamed to Tools/gdb/libpython.py?

What is your OS and gdb versions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:50:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 21:50:26 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271800226.0.0.00791793966477.issue8092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh no :-( I realized that I removed the first message of this issue! msg100687. Copy/paste of the message:
---
This issue is a regression introduced by r72208 to fix the issue #3672.

Attached patch fixes PyUnicode_EncodeUTF8() if unicode_encode_call_errorhandler() returns an unicode string (eg. backslackreplace error handler). I don't know unicodeobject.c code (very well), and my patch should be far from being perfect.

I suppose that the maximum length of an escaped characters is 8 bytes (xmlcharrefreplace error error for U+DFFFF). When the first lone surrogate is found, reallocate the buffer to size*8 bytes. The escaped character have to be an ASCII character or an UnicodeEncodeError is raised.

Note: unicode_encode_ucs1() doesn't have hardcoded for the maximum length ot escaped string. Its code might be reused in PyUnicode_EncodeUTF8() to remove the hardcoded limits.
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:52:11 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 20 Apr 2010 21:52:11 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1271799468.17.0.361930270809.issue1083@psf.upfronthosting.co.za>
Message-ID: <19406.8710.206059.190058@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Mark> I think it's fine to do the division and round the result to the
    Mark> nearest whole number of microseconds.

Right.  Just think of a timedelta as a floating point number of seconds with
very limited precision (1e-6 seconds).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Tue Apr 20 23:59:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 21:59:52 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271800792.71.0.418742518298.issue8092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I forgot the remove the reallocation in the unicode case in the patch version 2.

Patch version 3:
 - micro-optimization: group both surrogates cases in the same if to avoid checking 0xD800 <= ch twice
 - check for integer overflow
 - (remove the duplication reallocation introduced by version 2)

I think that PyUnicode_EncodeUTF8() is more readable after my patch: there maximum if depth is 2 instead of 3, and I removed the goto.

It shouldn't change anything about performances for chacters < 0x800 (ASCII and Latin-1), and I expect similar performances for characters >= 0x800.

----------
Added file: http://bugs.python.org/file17013/utf8_surrogate_error-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:02:37 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Apr 2010 22:02:37 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271800135.21.0.610744000914.issue8437@psf.upfronthosting.co.za>
Message-ID: <4BCE247A.2040105@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Do you have an old python-gdb.py file in your Python root directory?

Ah, ok. That was the problem indeed. The patch actually works fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:09:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Apr 2010 22:09:26 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271801366.65.0.587780604722.issue8437@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, yep - "rm python-gdb.py", "make" cleared up those remaining ".function" failures. The makefile could probably use a Modules/Setup.dist vs Modules/Setup style warning when libpython.py is newer than python-gdb.py to help prevent anyone else getting caught by that.

I still get one failure after that, even after a "make clean", "make", "./python -m test.regrtest -v test_gdb". Given the "unable to read Python frame information" embedded in the result on my machine (64-bit Kubuntu 9.10), it is probably related to the current issue.

The remaining failure:
======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)                    
Verify that the "py-bt" command works                                 
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 638, in test_basic_command                                                                      
    ''')                                                                        
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 158, in assertMultilineMatches                                                                  
    msg='%r did not match %r' % (actual, pattern))                              
AssertionError: 'Breakpoint 1 at 0x453510: file Objects/object.c, line 330.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7532780, flags=1)\n    at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#3 Frame 0x808680, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n    print(42)\n#7 (unable to read python frame information)\n#10 Frame 0x81a220, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, c=3)\n    baz(a, b, c)\n#13 Frame 0x807f00, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, c=3)\n    bar(a, b, c)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n    baz\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo \\(a=1, b=2, c=3\\)\n    bar\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in <module> \\(\\)\nfoo\\(1, 2, 3\\)\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:09:29 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 20 Apr 2010 22:09:29 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271801369.06.0.184084212556.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Sorry Martin, I meant issue 8410.
I have so many of these going on :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:20:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 22:20:33 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1271802033.76.0.785512191655.issue7852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r80279 and r80280 caused many buildbot to fail:

 i386 Ubuntu 3.x
 AMD64 Ubuntu trunk 
 AMD64 Ubuntu wide trunk 
 x86 Ubuntu trunk
 x86 XP-4 trunk 
 x86 XP-5 trunk 

======================================================================
FAIL: test_appleformatting (test.test_plistlib.TestPlistlib)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/test/test_plistlib.py", line 142, in test_appleformatting
    "generated data was not identical to Apple's output")
AssertionError: generated data was not identical to Apple's output

----------------------------------------------------------------------

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7852>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:22:01 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 20 Apr 2010 22:22:01 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271802121.95.0.156593438923.issue8437@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

In msg103780 Martin v. L?wis wrote:
> Ah, ok. That was the problem indeed. The patch actually works fine.
Good to hear.  Thanks for tracking this down and clarifying it.

As I understand it, the current status of this bug is that file17000 fixes the reported issue, but hasn't yet been applied to trunk.

In msg103781 Nick Coghlan wrote:
> I still get one failure after that, even after a "make clean", "make", 
> "./python -m test.regrtest -v test_gdb". Given the "unable to read 
> Python frame information" embedded in the result on my machine (64-bit 
> Kubuntu 9.10), it is probably related to the current issue.
I believe this is a different issue; please can you open a separate bug about this.  Reading the frame information seems to be highly sensitive to the optimization level and the exact version of gcc for the build, and the exact version of gdb, alas.  I've been tracking a failure like the one you describe, seen on 64-bit with Fedora in our downstream tracker here:
https://bugzilla.redhat.com/show_bug.cgi?id=556975

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:33:24 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 20 Apr 2010 22:33:24 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271802804.64.0.934502374871.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

It is interesting to see, David, the difference in the behaviour of the semaphore based and condition variable based lock on linux.  It is clear that the semaphore and the condition varable have different queuing characteristics.  I wouldn't be surprised if the semaphore were "fair" on average, but that it somehow colludes with the scheduler allow the current  thread to cut in early based on, perhaps, timeslices or something.  The condition variable seems to be much more FIFO.

It is odd to me that you don't seem to be able to shake the performance hit even with a checkinterval of 10000.  In the end, the performance hit is because of successful switches during the GIL yield in ceval.c.  You ought to be able to raise the  checkinterval up to the same level as the 'effective' one with the unfair condition variable approach and have the same sort of behaviour (inclusive IO latency).  I'll do some modifcations locally to gather stats on successful yields vs unsuccessful ones.

As for this being academic, yes it is.  As I stated early on, I never intended this to be checked in as is.  My aim was to take a step back from the radical GIL rewrite in 3.x.  Provide a simple platform for GIL experiments in the know and trusted 2.x series.  See if we could achieve the desired features without the added unknowns of the new GIL.

And in fact, I also didn't want to expend this amount of ammunition on the "ROUNDROBIN_GIL" implementation.  It was included merely as an example of one thing that was wrong with the old one and why it was so unpredictable.  What I really wanted to look at was to combine the benefit of a large checkinterval (100000, say) with a priority based mechanism giving us a low IO latency.  I've gotten so sidetracked with this whole fair/unfair business that I have neglected to provide useful performance benchmark of the PRIORITY_GIL implementation.

The fact that I had to expend so much effort explaining exactly how the gil on mac (LEGACY_GIL) was not fair, also shows how tricky working with synchronization primitives and threads can be, even using such relatively modern primitives as mutexes and condition variables.  There are many pitfalls for the unwary, and in my experience, only a lot of exposure will bend your brain into taking all those pesky race conditions into acccount.  This is why I think it is important to _understand_ the problem completely before trying to fix it, and why fixing it stepwise, with a full understanding of each step along the way, is necessary for robust behaviour.

As for missing the boat on 2.7, well, there is always 2.8 isn't there :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:34:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 22:34:54 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271802894.73.0.187786266112.issue8437@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed: r80289 (trunk), r80290 (py3k). I will check the buildbots :-)

Nick: Can you open a new issue for your last issue?

I will open a new issue for my suggestions. I also realized that gdb is missing in the documentation!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:44:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 22:44:54 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271803494.94.0.77986560376.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stealing from Tennessee...

Patch committed to py3k in r80290, r80291, with some minor tweaks and fixes:

 - rename delta_remailder to delta_remainder
 - fix memory leak in delta_remainder
 - add whatsnew entry for docs
 - note that timedelta // timedelta returns an integer in docs
 - add tests for raising ZeroDivisionError, and remove uses of
   lambda in favour of using the operator module

Thanks, Alexander!

----------
assignee: tleeuwenburg at gmail.com -> mark.dickinson
components: +Extension Modules
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:45:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Apr 2010 22:45:58 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271803558.92.0.512175244409.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Grr.  s/whatsnew/versionadded/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:52:12 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 20 Apr 2010 22:52:12 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271803932.93.0.470756831322.issue8437@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> Fixed: r80289 (trunk), r80290 (py3k). I will check the buildbots :-)
Please forgive my pedantry, but these appear to be off-by-one; the commits appear to have been:
r80288 (trunk), r80289 (py3k)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:53:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 22:53:04 +0000
Subject: [issue8439] test_linecache failing in py3k r80169
In-Reply-To: <4BCADCEA.2060609@timgolden.me.uk>
Message-ID: <1271803984.07.0.446183643512.issue8439@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8439>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:53:24 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 20 Apr 2010 22:53:24 +0000
Subject: [issue8475] build-installer fix for doc building on OSX 10.4
In-Reply-To: <1271804004.62.0.250618279224.issue8475@psf.upfronthosting.co.za>
Message-ID: <1271804004.62.0.250618279224.issue8475@psf.upfronthosting.co.za>


New submission from David Bolen <db3l.net at gmail.com>:

The attached suggested patch changes build-installer to pass along the same Python executable that it itself is running under to the documentation Makefile.  This fixes an issue on OSX where pruning the PATH reverts to the system python (2.3.5) which is too old for Sphinx.  

This does now mean that build-installer itself needs to be run under 2.5+ which contradicts its initial usage comments.  I suspect we should just give up supporting it under 2.3, since an underlying tool no longer supports that, but have not changed those comments in this patch

----------
assignee: ronaldoussoren
components: Macintosh
files: build-installer.diff
keywords: patch
messages: 103790
nosy: db3l, ronaldoussoren
severity: normal
status: open
title: build-installer fix for doc building on OSX 10.4
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17014/build-installer.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8475>
_______________________________________

From report at bugs.python.org  Wed Apr 21 00:57:42 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 20 Apr 2010 22:57:42 +0000
Subject: [issue8476] build-installer fix for setIcon when no script path
	specified
In-Reply-To: <1271804262.14.0.282161229164.issue8476@psf.upfronthosting.co.za>
Message-ID: <1271804262.14.0.282161229164.issue8476@psf.upfronthosting.co.za>


New submission from David Bolen <db3l.net at gmail.com>:

The attached suggested patch fixes a small bug where if you execute the build-installer script without an explicit path (e.g., "python build-installer.py") the setIcon compilation will fail since dirname(__file__) is an empty string, so it ends up looking for files beneath "/".

It also normalizes the function slightly, since part of the previous code explicitly used dirname(__file__) whereas part of the code just assumed the output directory was relative to the current directory.

----------
assignee: ronaldoussoren
components: Macintosh
files: build-installer.diff
keywords: patch
messages: 103791
nosy: db3l, ronaldoussoren
severity: normal
status: open
title: build-installer fix for setIcon when no script path specified
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17015/build-installer.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8476>
_______________________________________

From report at bugs.python.org  Wed Apr 21 01:28:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 23:28:12 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1271806092.33.0.0965755642072.issue4870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an adapted patch for py3k. It also adds a couple of test cases.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file17016/sslopts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Wed Apr 21 01:38:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 23:38:38 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

_ssl.sslwrap() has 3 filename arguments: key_file, cert_file and cacerts_file. It uses "z" format to parse them.

Attached patch uses PyUnicode_FSConverter() to support surrogates, bytes and bytearray. It fixes also test_decode_certificate() function.

----------
components: Library (Lib), Unicode
files: ssl_surrogates.patch
keywords: patch
messages: 103793
nosy: haypo
severity: normal
status: open
title: _ssl: support surrogates in filenames, and bytes/bytearray filenames
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17017/ssl_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8477>
_______________________________________

From report at bugs.python.org  Wed Apr 21 01:38:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 23:38:51 +0000
Subject: [issue8242] Improve support of PEP 383 (surrogates) in Python3:
	meta-issue
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1271806731.01.0.921208952234.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +_ssl: support surrogates in filenames, and bytes/bytearray filenames

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Wed Apr 21 01:45:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Apr 2010 23:45:39 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1271807139.9.0.378140861036.issue8477@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some comments:
- your ssl_convert_filename() function has a strange signature
- using PyByteArray_AsString() is wrong, we release the GIL later and the buffer could be reallocated, leading to a crash; the right approach is to use PyObject_GetBuffer() and later PyBuffer_Release()
- as such, your function could simply return the bytes/bytearray PyObject *, and not fill the char * pointer
- adding tests for both the bytes and unicode cases would be nice

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8477>
_______________________________________

From report at bugs.python.org  Wed Apr 21 01:46:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 23:46:26 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1271807186.83.0.648598568268.issue3631@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Gdb7 now supports Python as a script language, and Python trunk/py3k has a gdb library to debug Python programs. It's much better than the old Misc/gdbinit script.

Close this issue as "out of date".

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Wed Apr 21 01:51:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 23:51:18 +0000
Subject: [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1271807478.4.0.0502472060525.issue4036@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

subprocess accepts byte string in program arguments in py3k, so the issue can be closed.

I opened other issues for the other arguments:
 - current working directory: #8393
 - environment variables: #8391
 - error message: #8467

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4036>
_______________________________________

From report at bugs.python.org  Wed Apr 21 01:51:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 23:51:31 +0000
Subject: [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1271807491.27.0.558265237266.issue4036@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4036>
_______________________________________

From report at bugs.python.org  Wed Apr 21 02:21:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 21 Apr 2010 00:21:09 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271809269.08.0.398036519306.issue8413@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think the right way to handle this is to modify the test:

if (Py_TYPE(args)->tp_as_mapping && !PyTuple_Check(args) &&
    !PyObject_TypeCheck(args, &PyBaseString_Type))

to also exclude PyStructSequence's, but since they're all distinct types I don't see how to do that. I don't really think listing all of the PyStructSequence types would be acceptable.

This is the test that's trying to figure out if %-formatting should use mapping or tuple expansion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Wed Apr 21 04:14:54 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Wed, 21 Apr 2010 02:14:54 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271816094.72.0.679538121416.issue8451@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Ok, so I left the argument style in the docs as it was.

*** NOTE ***: Sean: Change this for the 3 trunk commit.

Setting the "python" string is outside of the argv function because we want to use "python" on any of the many places where the return is done.

As far as using the C argv[0], I decided to specifically use "python" as a fallback.  We could easily just let openlog pick it, which is what the old behavior was, but in that case it's dependent on the implementation.

I can't answer about sys.argv being unicode.

>From my looking at the code, SEP will vary depending on the platform, and is just what os.path.sep is -- I was going to use os.path.sep, but found it just returns SEP.

Thanks for the great review, I've attached a new version.

----------
Added file: http://bugs.python.org/file17018/syslog-kwargs4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Wed Apr 21 04:18:32 2010
From: report at bugs.python.org (rb)
Date: Wed, 21 Apr 2010 02:18:32 +0000
Subject: [issue8478] tokenize.untokenize first token missing failure case
In-Reply-To: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za>
Message-ID: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za>


New submission from rb <rb-oss-2 at justgohome.co.uk>:

When altering tokens and thus not providing token location information, tokenize.untokenize sometimes misses out the first token. Failure case below.

Expected output: 'import foo ,bar\n'
Actual output: 'foo ,bar\n'

$ python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO, tokenize
>>> 
>>> def strip(iterable):
...     for t_type, t_str, (srow, scol), (erow, ecol), line in iterable:
...         yield t_type, t_str
... 
>>> source = StringIO.StringIO('import foo, bar\n')
>>> print repr(tokenize.untokenize(strip(tokenize.generate_tokens(source.readline))))
'foo ,bar \n'
>>> source.seek(0)
>>> print repr(tokenize.untokenize(tokenize.generate_tokens(source.readline)))
'import foo, bar\n'
>>>

----------
components: Library (Lib)
messages: 103799
nosy: rb
severity: normal
status: open
title: tokenize.untokenize first token missing failure case
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8478>
_______________________________________

From report at bugs.python.org  Wed Apr 21 05:23:06 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Wed, 21 Apr 2010 03:23:06 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1271820186.61.0.848293319345.issue8188@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I've spent some time working through the new hash function by re-implementing it for gmpy. Very elegant design.

I like _PyHASH_MODULUS better, too.

Regarding a hash function for complex types, I think documenting the existing behavior for PyComplex is sufficient. The magic number 1000003 could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER. The same constant, but a different algorithm, is also used when hashing a tuple.

I think hash(m/P) should preserve sign. It just seems more symmetrical. :)

----------
nosy: +casevh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Wed Apr 21 06:19:43 2010
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 21 Apr 2010 04:19:43 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271823583.88.0.529351971156.issue4256@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Thanks for the patch! One concern I have is that adding --help-options by default has the potential to break existing code, e.g. if someone using optparse or argparse was already defining their own --help-options flag. The backward compatible solution is to have --help-options disabled by default, and ask people to enable it with add_interface=True.

Comments on the argparse patch: I think it's probably overkill to create InterfaceFormatter - just do the appropriate formatting in the _InterfaceAction. I also wouldn't add format_interface or print_interface until someone requests them. Last nit: don't add the takes_value method, just inline your "self.nargs != 0" check in the one place you need it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 08:17:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 06:17:07 +0000
Subject: [issue8479] test_gdb: No stack
In-Reply-To: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>
Message-ID: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

test_gdb currently fails on 3k; some tests with a "No stack" message. I'll attach the full output, but would like this issue to focus on the "No stack" failures.

----------
files: test_gdb.txt
messages: 103802
nosy: loewis
severity: normal
status: open
title: test_gdb: No stack
versions: Python 3.2
Added file: http://bugs.python.org/file17019/test_gdb.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8479>
_______________________________________

From report at bugs.python.org  Wed Apr 21 08:17:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 06:17:20 +0000
Subject: [issue8479] test_gdb: No stack
In-Reply-To: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>
Message-ID: <1271830640.7.0.415167667516.issue8479@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> dmalcolm
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8479>
_______________________________________

From report at bugs.python.org  Wed Apr 21 08:19:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 06:19:14 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

test_gdb fails on 3k; some tests with a message "Error occurred in Python command: No frame is currently selected."

A separate problem was reported as #8479; I'm attaching the full test_gdb output.

----------
assignee: dmalcolm
files: test_gdb.txt
messages: 103803
nosy: dmalcolm, loewis
severity: normal
status: open
title: test_gdb: No frame is currently selected.
versions: Python 3.2
Added file: http://bugs.python.org/file17020/test_gdb.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 09:17:07 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Apr 2010 07:17:07 +0000
Subject: [issue8481] doc: ctypes no need to explicitly allocate writable
	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

ctypes docs should mention that Structures can be passed with byref() to functions expecting pointer to mutable memory without explicit allocation of mutable memory block with create_string_buffer() or similar function.

----------
assignee: georg.brandl
components: Documentation
messages: 103804
nosy: georg.brandl, techtonik
severity: normal
status: open
title: doc: ctypes no need to explicitly allocate writable memory with Structure
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8481>
_______________________________________

From report at bugs.python.org  Wed Apr 21 09:36:40 2010
From: report at bugs.python.org (Andy Buckley)
Date: Wed, 21 Apr 2010 07:36:40 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271835400.07.0.449582426122.issue4256@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

> The backward compatible solution is to have --help-options disabled by default, and ask people to enable it with add_interface=True.

Or to add the option just before arg parsing, if it has not already been defined?

Thanks for the patches, Filip!

Andy

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 10:05:10 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Wed, 21 Apr 2010 08:05:10 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1271837110.9.0.225407035194.issue8469@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

The more times I read the documentation and your comments I can see that the implementation is OK and the documentation is "complete" and can be read correctly. Please take this as constructive feedback to improving the documentation to make it easier to understand and harder to read incorrectly.

Yes, adding a "Standard size" column would have been very helpful. (I had missed the section on "standard" sizes.)

"Standard" is a very general term. And slightly confusing that standard isn't the default. Could the term "platform independent" (or "fixed"?) be added as an explanation of "standard" - or perhaps used instead?

Programming skills and platform knowledge at C level should not be a requirement to understand and use struct, so perhaps the references to C should be less high-profile, and perhaps something like this could be added:
"All sizes except trivial 1-byte entries (whatever that means) are platform dependent - use calcsize to get the size on your platform."

Perhaps the sections explaining 's', 'p', 'ILqQ', 'P' and '?' could be changed to (foot)notes to the table to make it easier to see where they belongs and if they can be skipped.

Perhaps "@" in the byte order table could be replaced with "@ (default)"? (And perhaps drop "If the first character is not one of these, '@' is assumed.")

The byte order character must come first in the format string and is a key to understand the other format characters, so perhaps everything related to that should come first?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Wed Apr 21 10:23:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 08:23:04 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1271838184.15.0.824578058412.issue8469@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the doc suggestions.

Actually, the current docs were revised recently;  this issue is a helpful reminder to me that those doc revisions need to be backported. :)  If you want to see the current docs, look at:

http://docs.python.org/dev/library/struct.html

I'm +0 on adding the standard sizes to the table of format codes.

I also agree it might make sense to swap the 'Format Character' section and the 'Byte Order, Size and Alignment' section.

That's all for now;  I'll look at this properly sometime soon.

The standard/native terminology is fairly ingrained;  I'm not sure whether it's really worth changing it, but we can look at the explanations and make sure that they're clear.

> Programming skills and platform knowledge at C level should not be a 
> requirement to understand and use struct, so perhaps the references to > C should be less high-profile,

Agreed, though I think the references to C should certainly be there, since they will help some users, and since part of the struct module's raison d'etre is to allow communication with data written/read by C programs.

The note about ILqQ returning Python longs might be better omitted;  the difference between int and long should be irrelevant to most users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:12:49 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 10:12:49 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Remaining failure after resolution of issue8437:
======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)                    
Verify that the "py-bt" command works                                 
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 638, in test_basic_command                                                                      
    ''')                                                                        
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 158, in assertMultilineMatches                                                                  
    msg='%r did not match %r' % (actual, pattern))                              
AssertionError: 'Breakpoint 1 at 0x453510: file Objects/object.c, line 330.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7532780, flags=1)\n    at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#3 Frame 0x808680, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n    print(42)\n#7 (unable to read python frame information)\n#10 Frame 0x81a220, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, c=3)\n    baz(a, b, c)\n#13 Frame 0x807f00, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, c=3)\n    bar(a, b, c)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n    baz\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo \\(a=1, b=2, c=3\\)\n    bar\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in <module> \\(\\)\nfoo\\(1, 2, 3\\)\n'

----------
components: Library (Lib), Tests
keywords: 64bit
messages: 103808
nosy: dmalcolm, haypo, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb - "(unable to read python frame information)" mismatch
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:13:20 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 10:13:20 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271844800.79.0.604791560725.issue8482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And Dave's comment from the other issue:

Reading the frame information seems to be highly sensitive to the optimization level and the exact version of gcc for the build, and the exact version of gdb, alas.  I've been tracking a failure like the one you describe, seen on 64-bit with Fedora in our downstream tracker here:
https://bugzilla.redhat.com/show_bug.cgi?id=556975

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:17:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 10:17:10 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271845030.06.0.929276670987.issue8482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Potentially relevant gcc and gdb version info:

~$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~$ gdb --version
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Python build is currently just a straight unmodified call to "make". I'll see if I still get the error if I tell ./configure to set up for a debug build of Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:18:14 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 10:18:14 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271845094.58.0.779564285065.issue8437@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Remaining problem recorded as issue 8482

----------
components: +Library (Lib), Tests
keywords: +64bit -patch
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:19:13 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 21 Apr 2010 10:19:13 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271845153.2.0.122214980574.issue7332@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> And that report shows only a single thread, so I have to assume that the
8MB figure applies there.

> Nevertheless, we can remove the stack buffer since it's probably
useless. It just seems unlikely to me to be the root cause of the stack
overflow.

If we really have an 8MB stack, yes, it's unlikely. But max stack size is inherited by child processes, and see for example streamtuner (one of the reports):
http://bugs.gentoo.org/274056

--- src/streamtuner/st-thread.c
+++ src/streamtuner/st-thread.c
@@ -108,1 +108,1 @@
-			     0x18000, /* 96k, big enough for libcurl */
+			     0x40000, /* change from 96k to 256k */

So if we start with this stack size, we can run out of stack space really easily: I counted around 20 bufs allocation in some backtraces, and with MAXPATHLEN to 4K, it's 20 * 4 + 16 = 96K used.

There might be another reason. I think that Ubuntu's using gcc SSP feature by default, to prevent buffer overflows and friends, so maybe there's something going on with this. That would explain why it's only reported on Ubuntu (well, they also have more users, but let's assume there's really something specific on Ubuntu).

> I'm also getting segfaults in PyMarshal_ReadLastObjectFromFile in Python 2.6.2 (on Ubuntu Jaunty).  It's very sporadic, I've been reproducing it by running a minimal script 100,000 times, and getting a few core dumps.

I've had a look at your backtraces, and when it segfaults, the stack size is _really_ far from 8M. So there's realy somthing fishy going on here. Are you getting an error message printed beside the usual segmentation fault ? Could you try to reproduce with your test script with a python compiled with -fno-stack-protector and -U_FORTIFY_SOURCE ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:23:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 10:23:53 +0000
Subject: [issue6600] MemoryError in AiX 64-bit - PyMem_MALLOC fails in
	open/fdopen
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1271845433.03.0.101763433418.issue6600@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, closing then.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:24:14 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 10:24:14 +0000
Subject: [issue8437] test_gdb: gdb.Frame has no attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271845454.42.0.787379543452.issue8437@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Oops, thought I had reverted those accidental edits by reloading the page. I guess not)

----------
keywords: +patch -64bit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8437>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:26:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 10:26:57 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271845617.99.0.647080657302.issue8482@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Readable version of the error message (with newlines):
---------
AssertionError: 'Breakpoint 1 at 0x453510: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x7ffff7532780, flags=1)
    at Objects/object.c:330
330             return internal_print(op, fp, flags, 0);
#3 Frame 0x808680, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))
    print(42)
#7 (unable to read python frame information)
#10 Frame 0x81a220, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, c=3)
    baz(a, b, c)
#13 Frame 0x807f00, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, c=3)
    bar(a, b, c)
' did not match '^.*
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \(a=1, b=2, c=3\)
    baz\(a, b, c\)
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo \(a=1, b=2, c=3\)
    bar\(a, b, c\)
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in <module> \(\)
foo\(1, 2, 3\)
'
---------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:55:25 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 21 Apr 2010 10:55:25 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

This is rather confusing:

Python 2.6.4 (r264:75706, Mar  8 2010, 08:41:55)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, asyncore
>>> class T:
...     pass
...
>>> t = T()
>>> print t
<__main__.T instance at 0x18237a0>
>>> print repr(t)
<__main__.T instance at 0x18237a0>
>>> class A(asyncore.dispatcher):
...     pass
...
>>> a = A()
>>> print a
None
>>> print repr(a)
<__main__.A at 0x179c0e0>
>>> class B(asyncore.dispatcher):
...     def __init__(self, *args):
...             asyncore.dispatcher.__init__(self, *args)
...
>>> sock = socket.socket()
>>> b = B(sock)
>>> print b
<socket._socketobject object at 0x7fcef226e8a0>
>>> print repr(b)
<__main__.B at 0x179c0e0>

Here's dispatcher's __repr__:

    def __repr__(self):
        status = [self.__class__.__module__+"."+self.__class__.__name__]
        if self.accepting and self.addr:
            status.append('listening')
        elif self.connected:
            status.append('connected')
        if self.addr is not None:
            try:
                status.append('%s:%d' % self.addr)
            except TypeError:
                status.append(repr(self.addr))
        return '<%s at %#x>' % (' '.join(status), id(self))

Which doesn't seem excessively complex...

----------
components: Library (Lib)
messages: 103816
nosy: djc
severity: normal
status: open
title: asyncore.dispatcher.__repr__() is weird
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:57:39 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 21 Apr 2010 10:57:39 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271847459.13.0.280918066328.issue7332@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> That would explain why it's only reported on Ubuntu

the original report is from the rPath distribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Wed Apr 21 12:59:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 10:59:39 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271847579.28.0.296510524474.issue8482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks Victor.

The test actually runs fine under "./configure --with-pydebug", but reverting to a plain "./configure" and rebuilding means I get the error again.

Definitely sounds like it could be due to the compiler failing to make some relevant info available to the debugger.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 13:02:50 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 21 Apr 2010 11:02:50 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271847770.61.0.379488071793.issue8483@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +josiah.carlson, josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 13:22:49 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 21 Apr 2010 11:22:49 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271848969.4.0.506825606015.issue7332@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> the original report is from the rPath distribution.

Never heard of this one, but http://wiki.rpath.com/wiki/rPath_Linux:rPath_Linux_2 states:

Compile with --fstack-protectorand FORTIFY_SOURCE=2 (override in your recipes by modifying the securityflags Conary macro), link with GNU hash and -O1, and use -fPIE for some key executables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Wed Apr 21 13:26:47 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 21 Apr 2010 11:26:47 +0000
Subject: [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271849207.81.0.198486678861.issue8410@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I know that multicore processors are all the rage right now, but one thing that concerns me about this patch is its effect on single-core systems.  If you apply this on a single-CPU, are threads just going to sit there and thrash as they rapidly context switch? (Something that does not occur now).

Also, I've done a few experiments and on a single-core Windows-XP machine, the GIL does not appear to have any kind of fairness to it (as previously claimed here).   Yet, if I run the same experiments on a dual-core PC, the GIL is suddenly fair.  So, somewhere in that lock implementation, it seems to adapt to the environment.  Do we have to try an emulate that behavior in Unix?   If so, how do you do it without it turning into a huge coding mess? 

I'll just mention that the extra context-switching introduced by fair-locking has a rather pronounced effect on performance that should be considered even on multicore.  I posted some benchmarks in Issue 8299 for Linux and OS-X.  In those benchmarks, the introduction of fair GIL locking makes CPU-bound threads run about 2-5 times slower than before on Linux and OS-X.

----------
nosy: +dabeaz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________

From report at bugs.python.org  Wed Apr 21 13:33:56 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 21 Apr 2010 11:33:56 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271849636.07.0.417997617402.issue8483@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Current guess for this behavior: dispatcher doesn't have __str__, so __getattr__ escalates to _socket.socket.__str__, which gets redirected to _socket.socket.__repr__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 13:36:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 11:36:02 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271849762.58.0.472546068469.issue8451@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

One argument in favor of letting openlog pick it (assuming it uses argv[0]) is that for a while at least we will have many systems running both python2 and python3, and it might be useful to have that distinction show up in the log if the fallback is used.  I'm not sure this is a strong argument :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Wed Apr 21 13:56:22 2010
From: report at bugs.python.org (Beda Kosata)
Date: Wed, 21 Apr 2010 11:56:22 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>


New submission from Beda Kosata <beda at zirael.org>:

When trying a secure connection to an HTTPS server with server certificate verification, I get very strange behaviour when the digest used in the signing certificate is SHA-256 (+RSA).
On Windows with Python 2.6.4 or 2.6.5, I consistently get the following error:

ssl.SSLError: [Errno 1] _ssl.c:480: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm

When I tried to reproduce this on Ubuntu Linux, I found that it either failed with the same error or succeeded in case the hashlib was imported before the actual code. I got the same behaviour on Gentoo Linux with Python 2.6.4 and Fedora 11 and Debian unstable with other versions of Python 2.6.
On Windows, importing hashlib prior to the code does not fix it as is does on Linux.

Using openssl s_client (openssl s_client -connect sha256.tbs-internet.com:443 -CAfile chain.pem) give no error, so the problem is not directly with openssl.
It seems that the Python ssl (_ssl) library does not load properly the corresponding hash modules from openssl or something like this.

I attach a sample script with the hashlib import commented out. I also add a pem file with certificates needed for the code to check the server certificate.

P.S.- I was able to reproduce the same behaviour with another site using SHA-256 base digests.

----------
components: Library (Lib)
files: ssl_check.py
messages: 103823
nosy: beda
severity: normal
status: open
title: ssl socket with certificate verification fails on SHA256 digest algorithm
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17021/ssl_check.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 13:57:11 2010
From: report at bugs.python.org (Beda Kosata)
Date: Wed, 21 Apr 2010 11:57:11 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271851031.74.0.77328171273.issue8484@psf.upfronthosting.co.za>


Changes by Beda Kosata <beda at zirael.org>:


Added file: http://bugs.python.org/file17022/chain.pem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:01:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 12:01:56 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271851316.87.0.731932371297.issue8482@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The test actually runs fine under "./configure --with-pydebug" (...)

I changed configure to disable all compiler optimisations if --with-pydebug is used. Retry with ./configure CFLAGS="-O0".

A variable may be optimized (use a register instead a variable allocated on the stack) and gdb is unable to get its value. If we are able to isole the variable, you could try to ask gcc to not optimize it... but only if it doesn't change Python performances too much.

Another simple approach is to disable the test if Python was compiled with compiler optimisation. To detect optimization, we should use a gdb batch script trying to read the optimized (or not) variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:02:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 12:02:02 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271851322.42.0.00609976579392.issue8484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola, janssen, pitrou
priority:  -> normal
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:12:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 12:12:19 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271851939.95.0.262406605951.issue4256@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I prefer an approach that allows this option to be defined by default, since if it is not defined by default it defeats part of the purpose of having the option.  The program author may not be concerned with completions (or even know about them), but if the option is defined by default then even the programs of those authors can be auto-completed by the generic script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:13:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 12:13:10 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271851990.53.0.675104016534.issue4256@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Removing 2.7 since it is now in feature freeze.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:13:28 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 21 Apr 2010 12:13:28 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271852008.07.0.369900265262.issue8483@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:14:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 12:14:05 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271852045.58.0.877085005981.issue8484@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Changing OpenSSL initialization to the following seems to fix the issue (with OpenSSL 0.9.8k and 1.0.0):

        /* Init OpenSSL */
        SSL_load_error_strings();
        SSL_library_init();
#ifdef WITH_THREAD
        /* note that this will start threading if not already started */
        if (!_setup_ssl_threads()) {
                return;
        }
#endif
        OpenSSL_add_all_algorithms();


_hashopenssl.c might need that code too, therefore I'm adding gps to the nosy list.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:16:23 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Apr 2010 12:16:23 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271852183.06.0.983297123308.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Jeroen, thanks for the idea. I asked Thomas Dickey and he said that
one should not load both libncurses.so and libncursesw.so.

I think this means that if libreadline.so is already linked against
libncurses.so, we are stuck with libncurses.so for the curses module.


If this affects users who want the wide character version, they could
file a bug report with their distro:

Thomas Dickey pointed out that there are two ways for a distro to
deal with this problem:

  1) Link libreadline against ncursesw.

  2) Split out the termcap interface (which readline uses) as
     libtinfo. This is a configure option for ncurses and SuSE
     and Redhat are doing this.


I'm attaching a new patch against py3k that makes sure that the
readline and curses modules use the same curses library.

(This does not apply to Darwin, but I don't want to touch that logic.)
  

I'm going to test the patch on py3k-cdecimal to see if it works on
the buildbots.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17023/issue7384-3-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:23:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 12:23:37 +0000
Subject: [issue8485] Don't accept bytearray as filenames, or simplify the API
In-Reply-To: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>
Message-ID: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

r72313 (PEP 383) created the PyUnicode_FSConverter() function: encode an object to a byte string using the default file system encoding. PyBytes and PyByteArray are leaved unchanged (just increment the reference counter), PyUnicode is encoded to PyBytes (if the encoder produces something else, an error is raised).

In my opinion, a file name is a character string (Windows) or a byte string (POSIX) and a bytearray object is unexpected. Only few function support this type: no function of os.path accept them. In the Python test suite, no function use bytearray for filenames.

It's already complex to support 2 types (bytes and str) for filenames in os.path, I think that a third type is too much and has no real world use case (the module manipuling filenames is os.path and it doesn't support bytearray and nobody noticed that).

Suppport bytearray is complex because we need to acquire a lock (using PyObject_GetBuffer()) and release the lock (o->ob_type->tp_as_buffer->bf_releasebuffer(o, 0)... that's not really intuitive...). posixmodule.c uses functions bytes2str() and realease_bytes() to handle bytearray easily. But these functions are static and other modules have to reimplement them.

I propose the reject bytearray in PyUnicode_FSConverter(), or to simplify the API and fix Python to accept bytearray filename everywhere especially in os.path.

***

Reject bytearray in PyUnicode_FSConverter() is trivial only there is only one test that have to be changed in the whole Python3 test suite: test_empty_bytearray in test_bytes.py. This function shows that bytearray is complex and introduce subtle bugs (the lock/GIL issue). All code using PyUnicode_FSConverter() would become simpler.

Example:

----
/* Release the lock, decref the object. */
static void
release_bytes(PyObject* o)
{
        if (PyByteArray_Check(o))
                o->ob_type->tp_as_buffer->bf_releasebuffer(o, 0);
        Py_DECREF(o);
}

...
realease_byte(path);
----

becomes "Py_DECREF(path);" and release_bytes() can be removed.

And
------------
static char*
bytes2str(PyObject* o, int lock)
{
        if(PyBytes_Check(o))
                return PyBytes_AsString(o);
        else if(PyByteArray_Check(o)) {
                if (lock && PyObject_GetBuffer(o, NULL, 0) < 0)
                        /* On a bytearray, this should not fail. */
                        PyErr_BadInternalCall();
                return PyByteArray_AsString(o);
        } else {
                /* The FS converter should have verified that this
                   is either bytes or bytearray. */
                Py_FatalError("bad object passed to bytes2str");
                /* not reached. */
                return "";
        }
}

...
path = bytes2str(opath);
------------

becomes "path = PyBytes_AS_STRING(opath);" (or maybe "path = PyBytes_AsString(opath);" if you don't trust PyUnicode_FSConverter)  and bytes2str() can be removed.

***

Simplify the API means that bytes2str() and release_bytes() should become protected functions (not static, but prefixed by "_Py_") or maybe public ("Py_" prefix).

But the most complex part is to modify os.path to support bytearray, and this task would not be funny :-)

----------
components: Interpreter Core, Library (Lib), Unicode
messages: 103829
nosy: haypo
severity: normal
status: open
title: Don't accept bytearray as filenames, or simplify the API
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8485>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:24:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 12:24:32 +0000
Subject: [issue8485] Don't accept bytearray as filenames, or simplify the API
In-Reply-To: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>
Message-ID: <1271852673.0.0.72069418469.issue8485@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8485>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:25:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 12:25:32 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271852732.25.0.75576993266.issue8480@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I may be related to #8482 (compiler optimization level?).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:25:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 12:25:35 +0000
Subject: [issue8479] test_gdb: No stack
In-Reply-To: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>
Message-ID: <1271852735.8.0.0486366458914.issue8479@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I may be related to #8482 (compiler optimization level?).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8479>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:28:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 12:28:21 +0000
Subject: [issue8485] Don't accept bytearray as filenames, or simplify the API
In-Reply-To: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>
Message-ID: <1271852901.03.0.729819947538.issue8485@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch removing bytearray filename support: it mostly removes code.

----------
keywords: +patch
Added file: http://bugs.python.org/file17024/no_bytearray_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8485>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:28:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 12:28:57 +0000
Subject: [issue8485] Don't accept bytearray as filenames, or simplify the API
In-Reply-To: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>
Message-ID: <1271852937.17.0.825806652857.issue8485@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Or perhaps the bytearray can be converted to a bytes object. This is not optimal performance-wise but is unlikely to make a difference in real-world code (if you are passing a filename to an external API, chances are some IO will occur which will dwarf the cost of creating a separate bytes object).

But I agree that supporting bytearrays in filename-taking functions, while "nice" from a consistency point of view, isn't really useful in practice. So I would be ok to remove that support if it simplifies (or avoids complexifying) the logic for those functions.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8485>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:40:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 12:40:29 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271853629.46.0.437785925978.issue8483@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not clear on what you are finding weird, here.  Your issue title talks about __repr__, but your last post talks about __str__.

----------
nosy: +r.david.murray
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:49:28 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Wed, 21 Apr 2010 12:49:28 +0000
Subject: [issue8486] [PATCH] threading.Event()
In-Reply-To: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

Hi,

I'm suggesting to declare a __bool__() function as an alias for is_set() in Event class from threading package. So Event objects could be used like booleans.

Ex:

I thought 'while(not event): do_something()' is much intuitive than 'while(not event.is_set()): do_something()'

----------
components: Library (Lib)
messages: 103835
nosy: Kain94
severity: normal
status: open
title: [PATCH] threading.Event()
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/issue8486>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:56:21 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 21 Apr 2010 12:56:21 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271854581.79.0.270205580254.issue8483@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

David, just have a look at the interpreter transcript, in particular the results of the print statements. I'm not sure why it happens, in my previous message I just stated a hypothesis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 14:57:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 12:57:48 +0000
Subject: [issue8486] [PATCH] threading.Event()
In-Reply-To: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271854668.75.0.315370930265.issue8486@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Due to the nature of an Event, you should in most situations wait() on it, rather than test its value. Also, changing the boolean value of an Event would break existing code. I therefore think this should be rejected.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8486>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:08:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 13:08:49 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271855329.99.0.578757228759.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This patch looks good to me, assuming that the buildbots are happy.  I agree that this seems like a sensible solution for now, even if it means limiting users to ncurses rather than ncursesw.

I was initially a bit surprised that it works on OS X, since OS X doesn't have 'ldd';  but in that case the os.system call simply outputs "sh: ldd: command not found" to stderr and (presumably) nothing to stdout;  no Python exception is raised, so it's all okay.  It might be worth adding code to avoid the os.system('ldd ...') call on OS X, just to avoid the unnecessary error message on the console.  Apart from this, I say +1 to applying the patch.

Many thanks for all the detective work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:09:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 13:09:10 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271855350.54.0.334657156448.issue8482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll weight for Dave to weigh in before I dig any further - the problem I am seeing seems to have a lot in common with the issue he reported on 64-bit Fedora, but I only followed about half of that bug discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:09:22 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 13:09:22 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271855362.83.0.76585250593.issue8482@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:09:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 13:09:32 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271855372.74.0.93375026153.issue8482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll wait for Dave to weigh in before I dig any further - the problem I am seeing seems to have a lot in common with the issue he reported on 64-bit Fedora, but I only followed about half of that bug discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:18:29 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Wed, 21 Apr 2010 13:18:29 +0000
Subject: [issue8486] [PATCH] threading.Event()
In-Reply-To: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271855909.39.0.823419998516.issue8486@psf.upfronthosting.co.za>


Benjamin VENELLE <kain94 at gmail.com> added the comment:

Yes, I agree when Event objects are used to sync threads. But in my case, I'm using them like signals to terminate some server's thread through a proper way.

This is a just a "cosmetic" stuff to enhance readability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8486>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:27:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 13:27:28 +0000
Subject: [issue8486] [PATCH] threading.Event()
In-Reply-To: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271856448.12.0.232035342224.issue8486@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, I agree when Event objects are used to sync threads. But in my
> case, I'm using them like signals to terminate some server's thread
> through a proper way.

In this case, you don't have to use an Event. A boolean attribute on one
of your objects is enough.
(similarly, you would use a "volatile" variable in C)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8486>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:47:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 13:47:38 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1271857658.31.0.217589954276.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Regarding a hash function for complex types, I think documenting the 
> existing behavior for PyComplex is sufficient. The magic number 1000003 > could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER. 

Seems reasonable;  I'm tempted to call the constant it hash_info.imaginary and _PyHASH_IMAGINARY, though.  :)  

There's also an implicit parameter in this algorithm, namely the size of a C long;  I think this should go into sys.hash_info, too.

complex_hash does need fixing in one respect:  it currently depends on signed overflow wrapping modulo 2**BIT_IN_LONG, but that's undefined behaviour;  it should use unsigned arithmetic instead.

> I think hash(m/P) should preserve sign. It just seems more symmetrical. :)

Agreed.  Along similar lines, I think I'm also going to get rid of _PyHASH_NINF and just use -PyHASH_INF instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:52:45 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Wed, 21 Apr 2010 13:52:45 +0000
Subject: [issue8486] [PATCH] threading.Event()
In-Reply-To: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271857965.51.0.00702373681995.issue8486@psf.upfronthosting.co.za>


Benjamin VENELLE <kain94 at gmail.com> added the comment:

> In this case, you don't have to use an Event. A boolean attribute on one
> of your objects is enough.
> (similarly, you would use a "volatile" variable in C)

This is already the case with Event. Look at threading.py @line ~355 Event class has a kinda private attribute _flags which is set/unset right before notifying. Using a boolean would look almostly the same so why to reinvent the wheel ? :)

If you look also at is_set(), it has the same meanings than __bool__() (ie returning True or False according to object's status). My suggest is only to had the following two lines:

def __bool__(self):
  return self.is_set()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8486>
_______________________________________

From report at bugs.python.org  Wed Apr 21 15:55:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 13:55:41 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271858141.29.0.465763295165.issue8480@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

libpython.py had a type "PyStringObjectPtr" referencing "PyStringObject" type, whereas Python3 uses "PybytesObject". That's why you got this error. It should be fixed by r80311 (and r80312).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 16:00:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 14:00:42 +0000
Subject: [issue8479] test_gdb in Python3: No stack
In-Reply-To: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>
Message-ID: <1271858442.77.0.407323027474.issue8479@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is that test_gdb is not compatible with Python3.

test_gdb uses "print x" syntax instead of "print(x)", and "except XXX, xxx:" instead of "except XXX as xxx:". Note: "print range(1000)" => "print(list(range(1000)))".

DebuggerOutput.run_gdb() should also convert the output to unicode, maybe using out = out.decode("ascii"); err = err.decode("ascii");.

----------
title: test_gdb: No stack -> test_gdb in Python3: No stack

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8479>
_______________________________________

From report at bugs.python.org  Wed Apr 21 16:07:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 14:07:25 +0000
Subject: [issue8486] threading.Event()
In-Reply-To: <1271857965.51.0.00702373681995.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271858973.3394.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Using a boolean would look almostly the same so why to reinvent the
> wheel ? :)

Hmm, /you/ are reinventing the wheel by suggesting to use an Event
instead of a simple boolean. Just loop like this:

while not self.stop_me:
   # etc.

and set the stop_me attribute to True when you want to stop your thread.

----------
title: [PATCH] threading.Event() -> threading.Event()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8486>
_______________________________________

From report at bugs.python.org  Wed Apr 21 16:10:46 2010
From: report at bugs.python.org (VanL)
Date: Wed, 21 Apr 2010 14:10:46 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1271859046.68.0.626574707044.issue7755@psf.upfronthosting.co.za>


VanL <van at python.org> added the comment:

However, a 3 second clip used for testing purposes in an open source programming language appears to meet the guidelines for fair use in the United States. In particular, no one is going to use the test clip as a substitute for any part of the Monty Python skit. There is no trading on the content of the clip to capture any value whatsoever; it could be a test beep and it would serve the same purpose. In short, I think this could go on under fair use principles until there was some sort of complaint. 

That said, the content of the sound file really doesn't matter in this instance. It could be replaced by a clip of Barry saying "My hovercraft is full of eels" and the same functionality would be preserved.

----------
nosy: +VanL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Wed Apr 21 16:17:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 14:17:02 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1271859422.21.0.989957849415.issue7755@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Shouldn't "My hovercraft is full of eels" be considered an original creation of the Monty Python, and as such copyrighted?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Wed Apr 21 16:55:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 21 Apr 2010 14:55:22 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1271861722.35.0.00998786678661.issue7755@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Note that guido.au is just him saying some crazy sh*t and I'm fairly certain couldn't be construed as copyrighted material (unless Guido is going to assert copyright over it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:12:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 15:12:33 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271862753.31.0.0486016087704.issue8484@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. I'm not really happy about the test because it relies on an external test site, and the certificate apparently expires in 2011.

----------
keywords: +patch
Added file: http://bugs.python.org/file17025/algos.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:23:12 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 21 Apr 2010 15:23:12 +0000
Subject: [issue8479] test_gdb in Python3: No stack
In-Reply-To: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>
Message-ID: <1271863392.01.0.911570525585.issue8479@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Issue 8380 contains a port of the code and tests to python 3; it's awaiting review.

----------
superseder:  -> Port of the gdb7 debugging hooks to the "py3k" branch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8479>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:23:31 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 21 Apr 2010 15:23:31 +0000
Subject: [issue8479] test_gdb in Python3: No stack
In-Reply-To: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>
Message-ID: <1271863411.78.0.523831263107.issue8479@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8479>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:26:08 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 21 Apr 2010 15:26:08 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271863568.27.0.681508296769.issue8480@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

There was a patch for this attached to issue 8380, and you've fixed things in a different way.  Should I regenerate a patch against what's now in SVN, or should we use my patch?

----------
assignee: dmalcolm -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:27:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Apr 2010 15:27:36 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1271863656.49.0.358668257819.issue5516@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

There is another inconsistency that this patch does not seem to cure.  With patch applied and D and DT defined as in OP,

>>> D(1900,1,1) > DT(1900,1,1)
True

but

>>> DT(1900,1,1) < D(1900,1,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D

and

>>> date(1900,1,1) < datetime(1900,1,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare datetime.datetime to datetime.date

Note that without the patch,

>>> D(1900,1,1) > DT(1900,1,1)
False

but both behaviors seem to be wrong.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:27:40 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 21 Apr 2010 15:27:40 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271863660.87.0.300461840441.issue8380@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Looking at issue 8480, it looks like this a partial fix was applied, which will mean this patch will no longer apply.  Should I regenerate a patch against what's now in SVN, or should we use my patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:28:31 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 21 Apr 2010 15:28:31 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271863711.56.0.0510357445325.issue8380@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:30:00 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 21 Apr 2010 15:30:00 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271863800.23.0.385160395602.issue8451@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I have the same reasoning as David, although I was thinking about python vs. pythonw. But it's not a big deal.

I think you should check it in as-is, and we can worry about modifying it later, if need be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:31:05 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 21 Apr 2010 15:31:05 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271863865.13.0.723107194419.issue8483@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I think the problem relies in here:

    # cheap inheritance, used to pass all other attribute
    # references to the underlying socket object.
    def __getattr__(self, attr):
        return getattr(self.socket, attr)

I wonder why this has been added in the first place.
It also causes confusing error messages when accessing undefined attributes:

>>> class B(asyncore.dispatcher):
...     def __init__(self, *args):
...             asyncore.dispatcher.__init__(self, *args)
...
>>> b = B()
>>> b.blabla
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/asyncore.py", line 394, in __getattr__
    return getattr(self.socket, attr)
AttributeError: '_socketobject' object has no attribute 'blabla'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:35:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 15:35:31 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271864131.76.0.135062188532.issue8380@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Looking at issue 8480, it looks like this a partial fix was applied,

Martin fixed calls to assertListing(). I renamed PyStringObjectStr to PyBytesStringPtr and used a breakpoint on textiowrapper_write() instead of PyObject_Dump(). Your patch uses a breakpoint on builtin_id(): I don't know what's best, I only tried to fix tests.

Sorry, I didn't knew this issue.

> which will mean this patch will no longer apply.  Should I regenerate
> a patch against what's now in SVN, or should we use my patch?

I think that I would be easier to update your patch to SVN (py3k).

--

I don't understand why the tests contain long type "L" suffix and unicode "u" prefix (eg. "1L"). Is it because gdb is linked to Python2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:53:56 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 21 Apr 2010 15:53:56 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271865236.65.0.799675585211.issue8380@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks; I'm working on a newer version of the patch based on what's in SVN.  

I prefer your choice of breakpoint, and I've changed my mind about the python2 vs python3 proxyval handling.  Hope to have a fresh patch later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Wed Apr 21 17:57:20 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 21 Apr 2010 15:57:20 +0000
Subject: [issue8487] os.mknod() fails on NFS mounted directories
In-Reply-To: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>
Message-ID: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

$ cat test.py
#!/usr/bin/env python
import os
import stat
dbfile = './testfile.test'
with open(dbfile, 'w') as fh:
    print('Opened file for writing')
os.unlink(dbfile)
os.mknod(dbfile, stat.S_IRUSR | stat.S_IWUSR | stat.S_IFREG)
print('Mknod\'ed file')

[cliff at ih ~]$ cd tmp              <-- nfs mounted on a 64bit Fedora box
[cliff at ih tmp]$ ~/tmp/test.py
Opened file for writing
Traceback (most recent call last):
  File "/home/cliff/tmp/test.py", line 9, in <module>
    os.mknod(dbfile, stat.S_IRUSR | stat.S_IWUSR | stat.S_IFREG)
OSError: [Errno 2] No such file or directory

[cliff at ih tmp]$ cd /tmp           <-- locally mounted on a HD
[cliff at ih tmp]$ ~/tmp/test.py
Opened file for writing
Mknod'ed file


I think the mknod() call really shouldn't fail if it tries to create an ordinary file that can be created with open() with problems.

----------
components: IO
messages: 103860
nosy: Nikratio
severity: normal
status: open
title: os.mknod() fails on NFS mounted directories
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8487>
_______________________________________

From report at bugs.python.org  Wed Apr 21 18:20:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 16:20:33 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271866833.41.0.153065623807.issue8483@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I somehow missed the fact that B was a dispatcher subclass.  Too early in my morning, I guess.

So, I think the title of this issue should be "asyncore.dispatcher's __repr__ not being used as fallback for __str__", and your speculation looks likely to be on target, as Giampaolo says.

Unfortunately, even if forwarding everything to the socket is questionable, it would probably be a really bad idea to change it, since there is likely code in the field depending on this behavior.

The specific case of __str__ could be fixed by adding an __str__ to dispatcher, and that would be a lot less likely to break anything other than perhaps the odd doctest here and there (but that would mean it still shouldn't be changed in 2.6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 18:26:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 16:26:16 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271867176.48.0.254087784897.issue8484@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After several attempts, I've failed generating a self-signed certificate that would reproduce the issue without relying on an external server. Perhaps there's something else than simply the hashing algorithm. In any case I think I'm simply gonna keep the current patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 18:27:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 16:27:53 +0000
Subject: [issue8486] threading.Event()
In-Reply-To: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271867273.33.0.605584781877.issue8486@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of #5998, which was rejected.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Add __bool__ to threading.Event and multiprocessing.Event

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8486>
_______________________________________

From report at bugs.python.org  Wed Apr 21 18:51:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Apr 2010 16:51:29 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1271868689.2.0.642475616138.issue5516@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Upon further reflection I am -1 on this patch.  First, as implemented this patch changes behavior of an explicit invocation of date.__eq__.  The patch proposes to remove the following tests:

-        # Neverthelss, comparison should work with the base-class (date)
-        # projection if use of a date method is forced.
-        self.assert_(as_date.__eq__(as_datetime))
-        different_day = (as_date.day + 1) % 20 + 1
-        self.assert_(not as_date.__eq__(as_datetime.replace(day=
-                                                     different_day)))

Second, the patch introduces dependence of the baseclass method (date_richcompare) on a particular subclass (PyDateTime_Check).  This is against OOP principles.

I am not sure how the "equality not symmetric" issue can be fixed.  In my opinion current datetime implementation is fighting OOP and violating the substitution principle in an attempt to prevent date to datetime comparison.  I would prefer seeing one of two things: either datetime not inheriting from date or making datetime to date comparison compare date part alone.  Once you stop fighting OOP principles, symmetry of equality for subclasses will follow from that for the base class automatically.

Given that either of these solutions means a major change, I think it is best to leave the things as they are now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed Apr 21 18:53:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 16:53:54 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1271868834.25.0.265336502411.issue5516@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed Apr 21 18:58:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 16:58:35 +0000
Subject: [issue8487] os.mknod() fails on NFS mounted directories
In-Reply-To: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>
Message-ID: <1271869115.08.0.0275613252848.issue8487@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, this looks like a filesystem problem more than a Python problem.
The error (errno 2) comes from the mknod() system call itself.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8487>
_______________________________________

From report at bugs.python.org  Wed Apr 21 18:58:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 16:58:40 +0000
Subject: [issue8487] os.mknod() fails on NFS mounted directories
In-Reply-To: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>
Message-ID: <1271869120.75.0.244376099769.issue8487@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8487>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:34:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 21 Apr 2010 17:34:31 +0000
Subject: [issue8483] asyncore.dispatcher.__repr__() is weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271871271.87.0.814350852465.issue8483@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Unfortunately, even if forwarding everything to the socket is 
> questionable, it would probably be a really bad idea to change it, 
> since there is likely code in the field depending on this behavior.

I agree, even if it would break a code which is fundamentally *already* wrong. Maybe we can do this in 2.7 and 3.2 only?
The AttributeError message is *very* confusing.
Actually I've seen it a lot of times through the years and never figured out it had to do with that weird __getattr__ statement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:36:41 2010
From: report at bugs.python.org (rb)
Date: Wed, 21 Apr 2010 17:36:41 +0000
Subject: [issue8478] tokenize.untokenize first token missing failure case
In-Reply-To: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za>
Message-ID: <1271871401.05.0.364080797122.issue8478@psf.upfronthosting.co.za>


Changes by rb <rb-oss-2 at justgohome.co.uk>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8478>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:42:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Apr 2010 17:42:19 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271871739.24.0.0375270757572.issue2706@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Can someone (Mark?) add an acknowledgment for Victor Stinner to the NEWS file?  My py3k patch was 90% code from Victor's trunk patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:49:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Apr 2010 17:49:04 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1271872144.33.0.308040505317.issue1673409@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

With issue2706 accepted, I think this issue can now be rejected because proposed td.tosecs() can now be spelled simply as td/timedelta(seconds=1).

The other RFE for a totimestamp() method is a duplicate of issue2736.

----------
nosy: +Alexander.Belopolsky, mark.dickinson -belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:50:38 2010
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 21 Apr 2010 17:50:38 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1271835400.07.0.449582426122.issue4256@psf.upfronthosting.co.za>
Message-ID: <i2jd11dcfba1004211050l8d3f3c09i71809a55a010f5d1@mail.gmail.com>


Steven Bethard <steven.bethard at gmail.com> added the comment:

On Wed, Apr 21, 2010 at 12:36 AM, Andy Buckley <report at bugs.python.org> wrote:
> Or to add the option just before arg parsing, if it has not already been defined?

Something like this was suggested before and it doesn't really work
out well. It means the first time you call .parse_args(), your options
get modified. So if you do anything with the parser before
.parse_args() -- for example, calling .print_help() -- then you don't
get the right options.

On Wed, Apr 21, 2010 at 5:12 AM, R. David Murray <report at bugs.python.org> wrote:
> I prefer an approach that allows this option to be defined by default

I agree that it would be best if all command line utilities supported
this by default[1]. I'm just not sure how to do it in a backwards
compatible way. The fact that the most recent patch against argparse
has to modify so many test cases suggests that it's going to have
unexpected consequences for a bunch of users.

[1] Though I'd feel more confident in that belief if someone could
point me to what the output of other programs that do this looks like
so that I could see we were following a standard somewhere.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:51:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 17:51:26 +0000
Subject: [issue8483] asyncore.dispatcher's __getattr__ method produces
	confusing effects
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271872286.19.0.0998746166933.issue8483@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the attribute error message could be fixed, too, by enclosing the forwarding getattr in a try/except and generating the "correct" attribute error text.

Changing the forwarding behavior itself is the kind of issue that would need to be discussed on python-dev, and we'd need to make sure that the various asyncore constiuencies got a chance to chime in (remember the previous breakage of asyncore monkey-patching in 2.6 and the rancor it caused).  My guess is that we can't change it, though.  Certainly not in 2.7.

I'm changing the title of the issue to more accurately reflect the discussion.

----------
priority: low -> normal
title: asyncore.dispatcher.__repr__() is weird -> asyncore.dispatcher's __getattr__ method produces confusing effects

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:52:39 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 21 Apr 2010 17:52:39 +0000
Subject: [issue8487] os.mknod() fails on NFS mounted directories
In-Reply-To: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>
Message-ID: <1271872359.7.0.882193667768.issue8487@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Well, this looks like a filesystem problem more than a Python problem.
The error (errno 2) comes from the mknod() system call itself.

Definitely.

@Nikratio
Just to be sure, could you provide the result of:
- strace ~/tmp/test.py from NFS-mounted directory
- the relevant line of "mount" output
- "nfsstat -a" on client (and maybe server)

But you should know that mknod is disabled on some NFS servers for security reasons, and see man mknod:
"       POSIX.1-2001 says: "The only portable use of mknod() is to create a FIFO-
       special file.  If mode is not S_IFIFO or dev is not 0, the behavior of mknod()
       is unspecified."  However, nowadays one should never use mknod() for this
       purpose; one should use mkfifo(3), a function especially defined for this
       purpose.

       Under Linux, this call cannot be used to create directories.  One should make
       directories with mkdir(2).

       There are many infelicities in the protocol underlying NFS.  Some of these
       affect mknod()."

So try to avoid mknod over NFS...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8487>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:54:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 17:54:09 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1271872449.25.0.453336142768.issue2706@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, yes.  Sorry, Victor!  There's actually no acknowledgement in Misc/NEWS:  it's not *that* common to put acknowledgements there, and I'm not sure it's necessary here, but I've fixed the commit message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Wed Apr 21 19:57:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 17:57:17 +0000
Subject: [issue8483] asyncore.dispatcher's __getattr__ method produces
	confusing effects
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271872637.83.0.35931361575.issue8483@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By the way, the __getattr_ was in the very first version of the code checked in to the repository.  I think the chances of removing it are pretty much zero :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:03:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 18:03:32 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1271873012.14.0.429035678284.issue1673409@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this as a duplicate of issue 2736, as suggested.  I'll combine the nosy lists.

(BTW, as well as the newly introduced division methods, td.tosecs already exists, except that it's spelt td.total_seconds.)

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> datetime needs an "epoch" method

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:05:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 18:05:47 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1271873147.11.0.253636327525.issue2736@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Close issue 1673409 as a duplicate of this one;  combining nosy lists.

----------
nosy: +catlee, erik.stephens, guettli, jribbens, mark.dickinson, pitrou, skip.montanaro, srittau, steve.roberts, tim_one, tomster

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:06:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 18:06:03 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271873163.34.0.0108711204216.issue4256@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Here?s another approach, which has to be used explicitly but provides much more flexible completion: http://pypi.python.org/pypi/optcomplete

I ask the author some time ago if he?d adapt it to argparse; he answered he wouldn?t have time but it shouldn?t be too hard. It?s 221 lines of code (according to sloccount), perhaps worth merging into argparse.

Regards

----------
nosy: +merwok
title: optparse: provide a simple way to get a programmatically useful list of options -> optparse/argparse: provide a simple way to get a programmatically useful list of options

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:07:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 18:07:06 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1271873227.0.0.458322849931.issue2736@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:13:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 21 Apr 2010 18:13:20 +0000
Subject: [issue8487] os.mknod() fails on NFS mounted directories
In-Reply-To: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>
Message-ID: <1271873600.66.0.898829632891.issue8487@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing this, as it is not an issue with Python.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8487>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:18:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Apr 2010 18:18:04 +0000
Subject: [issue1673409] datetime module missing some important methods
In-Reply-To: <1271873012.14.0.429035678284.issue1673409@psf.upfronthosting.co.za>
Message-ID: <x2nd38f5331004211118ie0dcfd59pe0e22863b513bcf8@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Wed, Apr 21, 2010 at 2:03 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> (BTW, as well as the newly introduced division methods, td.tosecs already exists, except that it's spelt td.total_seconds.)

Aggrrr!  How did that slip in? :-)

86399999913600.0

Shouldn't td.total_seconds() return Decimal?  Maybe in py4k ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:18:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 21 Apr 2010 18:18:30 +0000
Subject: [issue8478] tokenize.untokenize first token missing failure case
In-Reply-To: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za>
Message-ID: <1271873910.26.0.358143348687.issue8478@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8478>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:24:53 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 21 Apr 2010 18:24:53 +0000
Subject: [issue8483] asyncore.dispatcher's __getattr__ method produces
	confusing effects
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271874293.3.0.346285902242.issue8483@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

You're absolutely right.
Patch in attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file17026/asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:25:10 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Wed, 21 Apr 2010 18:25:10 +0000
Subject: [issue8488] Docstrings of non-data descriptors "ignored"
In-Reply-To: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>
Message-ID: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

[I would assign priority minor to this, but the tracker won't let me]

I really like the online documentation features of python. However, I wonder about the output of the following simple example:

class Descriptor(object):
    """Doc of a non-data descriptor."""
    def __get__(self, instance, owner):
        return 42 if instance else self

class GetSetDescriptor(Descriptor):
    """Doc of a data-descriptor."""
    def __set__(self, instance, value):
        pass

class Demo(object):
    non_data = Descriptor()
    data = GetSetDescriptor()

help(Demo)


This results in

Help on class Demo in module __main__:

class Demo(builtins.object)
 |  Methods defined here:
 |  
 |  non_data = <__main__.Descriptor object>
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  __dict__
 |      dictionary for instance variables (if defined)
 |  
 |  __weakref__
 |      list of weak references to the object (if defined)
 |  
 |  data
 |      Doc of a data-descriptor.


I think the behaviour of pydoc wrt. the non_data descriptor is a bit out of line. I would have expected to find the docstring in the output here.

----------
components: Library (Lib)
files: doc.py
messages: 103880
nosy: torsten
severity: normal
status: open
title: Docstrings of non-data descriptors "ignored"
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17027/doc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8488>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:33:50 2010
From: report at bugs.python.org (Jess Austin)
Date: Wed, 21 Apr 2010 18:33:50 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1271874830.95.0.64288973065.issue5516@psf.upfronthosting.co.za>


Jess Austin <jess.austin at gmail.com> added the comment:

To be systematic, without the patch:

>>> D(1900, 1, 1) > DT(1900, 1, 1)
False
>>> D(1900, 1, 1) < DT(1900, 1, 1)
False
>>> DT(1900, 1, 1) > D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D
>>> DT(1900, 1, 1) < D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D


with the patch:

>>> D(1900, 1, 1) > DT(1900, 1, 1)
True
>>> D(1900, 1, 1) < DT(1900, 1, 1)
False
>>> DT(1900, 1, 1) > D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D
>>> DT(1900, 1, 1) < D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D


It might seem like the latter behavior is marginally better, but really this is just a mess, since a date-datetime comparison TypeErrors in all directions.  I appreciate Alexander's more experienced perspective, but it's not obvious to me that this problem is insoluble simply due to OOP algebra.  I'm going to keep tinkering with this to see if there isn't a way to satisfy his concerns AND fix these bugs WITHOUT breaking the established (and admittedly anti-OOP) behavior that dates are not equal to datetimes.

(Incidentally, the test I removed still seems to be an arbitrary ad-hoc requirement that subclasses of date behave differently than date itself.  I don't see how one could rely on this given the other inconsistencies with date subclasses, and so violating this in order to fix more serious problems seems acceptable.)

I'm reminded of the set and frozenset situation, which seems almost dual to this one.  set and frozenset don't inherit from each other, but they do compare.  This seems to bite you only when you try to redefine comparison in subclasses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:36:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 18:36:04 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271874964.87.0.880042242765.issue8482@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:40:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 18:40:17 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271875217.43.0.601058415395.issue8484@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That patch makes no sense. According to SSL_library_init(3SSL),

"OpenSSL_add_ssl_algorithms() and SSLeay_add_ssl_algorithms() are synonyms for SSL_library_init()"

So it shouldn't really matter which of these you call, and it should be sufficient to call only one of them (or the documentation is incorrect).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:43:19 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 18:43:19 +0000
Subject: [issue8485] Don't accept bytearray as filenames, or simplify the API
In-Reply-To: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>
Message-ID: <1271875399.65.0.00606522086284.issue8485@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm in favor of removing that support, too, but please check with python-dev whether anybody thinks a proper deprecation cycle (deprecated in 3.2, removed in 3.3) is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8485>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:43:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 18:43:46 +0000
Subject: [issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1271875426.71.0.903347326526.issue8314@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I was going to say that I think that this issue can be closed now...

... but the src/sparc/v8.S file still looks wrong to me:  Martin fixed one missing FFI_TYPE_UINT64 case, but it looks to me as though there's another one, in ffi_call_v8.  The code starting at line 68 in that file looks like:

	cmp	%i3, FFI_TYPE_INT
	be,a	done
	st	%o0, [%i4]	! (delay)

	cmp	%i3, FFI_TYPE_FLOAT
	be,a	done
	st	%f0, [%i4+0]	! (delay)

	cmp	%i3, FFI_TYPE_DOUBLE
	be,a	double
	st	%f0, [%i4+0]	! (delay)

	cmp	%i3, FFI_TYPE_SINT8
	be,a	sint8
	sll	%o0, 24, %o0	! (delay)

	cmp	%i3, FFI_TYPE_UINT8
	be,a	uint8
	sll	%o0, 24, %o0	! (delay)

	cmp	%i3, FFI_TYPE_SINT16
	be,a	sint16
	sll	%o0, 16, %o0	! (delay)

	cmp	%i3, FFI_TYPE_UINT16
	be,a	uint16
	sll	%o0, 16, %o0	! (delay)

	cmp	%i3, FFI_TYPE_SINT64
	be,a	longlong
	st	%o0, [%i4+0]	! (delay)
done:
	ret
	restore

Shouldn't there should be another block here for FFI_TYPE_UINT64, essentially identical to the FFI_TYPE_SINT64 block?  Or am I missing something?

I don't know why this omission doesn't cause buildbot failures; perhaps it's because the compiled test function (e.g., tf_Q in _ctypes_test.c) just happens to already have placed the correct values in the right locations ([%i4 + 0] and [%i4 + 4]) already, before transferring them to o0 and o1.

I've asked about this on the libffi-discuss mailing list, as a follow-up to Victor's report there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8314>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:43:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 21 Apr 2010 18:43:55 +0000
Subject: [issue8465] Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271875435.96.0.485625078682.issue8465@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:44:07 2010
From: report at bugs.python.org (Kees Cook)
Date: Wed, 21 Apr 2010 18:44:07 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271875447.87.0.0340295956804.issue7332@psf.upfronthosting.co.za>


Kees Cook <kees at ubuntu.com> added the comment:

The stack protector will add 8 (aligned, so possibly padded) bytes to each stack frame of functions with arrays of 8 or greater bytes.  So if things are marginal, this could make the difference between Pythons compiled with/without -fstack-protector.

N.B. if rPath is compiled with -D_FORTIFY_SOURCE=2 and -O1, then -D_FORTIFY_SOURCE=2 has no effect (it is only activated at -O2 or higher).

Details on Ubuntu's compiler flag defaults:
https://wiki.ubuntu.com/CompilerFlags

Putting MAXPATH on the stack certainly seems like a big waste of space, though.  :)

----------
nosy: +keescook

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:45:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 18:45:42 +0000
Subject: [issue8465] re: Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271875542.7.0.666228243722.issue8465@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Backreferences vs. escapes: a silent failure solved -> re: Backreferences vs. escapes: a silent failure solved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:46:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Apr 2010 18:46:26 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1271874830.95.0.64288973065.issue5516@psf.upfronthosting.co.za>
Message-ID: <n2id38f5331004211146l6444f3f7k486f40b1e2090acf@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Wed, Apr 21, 2010 at 2:33 PM, Jess Austin <report at bugs.python.org> wrote:
..
> It might seem like the latter behavior is marginally better, but really this is just a mess, since a date-datetime comparison TypeErrors in all
> directions. ?I appreciate Alexander's more experienced perspective, but it's not obvious to me that this problem is insoluble simply due to OOP
> algebra. ?I'm going to keep tinkering with this to see if there isn't a way to satisfy his concerns AND fix these bugs WITHOUT breaking the
> established (and admittedly anti-OOP) behavior that dates are not equal to datetimes.
>

I certainly don't have a proof that this is impossible, so best of
luck.  Note, however that the problematic behavior is due to D/DT
classes implementor's choice not to derive DT from D.  Whether
resulting violation of the symmetry of equality is a bug in python or
D/DT implementation is at least an open question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:50:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 18:50:47 +0000
Subject: [issue8484] ssl socket with certificate verification fails on SHA256
	digest algorithm
In-Reply-To: <1271875217.43.0.601058415395.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271875976.3394.13.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> "OpenSSL_add_ssl_algorithms() and SSLeay_add_ssl_algorithms() are
> synonyms for SSL_library_init()"

The patch calls OpenSSL_add_all_algorithms(), though.
(yes, it's a different one :-))
http://www.openssl.org/docs/crypto/OpenSSL_add_all_algorithms.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:52:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Apr 2010 18:52:39 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1271875959.86.0.13943154606.issue1673409@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Aggrrr!  How did that slip in? :-)

Blame Antoine.  :)  (See issue 5788 and revision 76529.)

> Shouldn't td.total_seconds() return Decimal?  Maybe in py4k ...

Yes, that would have been nice.

I'm not sure that the Decimal type is well-established enough yet that it's okay to return Decimal instances from random unrelated modules, though.  Maybe someday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Wed Apr 21 20:53:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 18:53:41 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271876021.9.0.106166197888.issue8480@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Victor's patch look fine to me (at least, I can't see a problem with it). If so, we should keep it.

In any case, it does fix the problem reported here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:17:50 2010
From: report at bugs.python.org (Domen)
Date: Wed, 21 Apr 2010 19:17:50 +0000
Subject: [issue8489] smtplib.SMTP.login() breaks with unicode input
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>


New submission from Domen <ielectric at gmail.com>:

Module smtplib, line 574, in login
  Module smtplib, line 538, in encode_cram_md5
  Module hmac, line 72, in __init__
TypeError: character mapping must return integer, None or unicode

Following traceback occurs when doing connection.login(u'foobar at domain.com', 'justdoit') to issue an ESMTP.

Python 2.6.4 (r264:75706, Mar 11 2010, 18:33:18)

----------
components: Unicode
messages: 103890
nosy: iElectric
severity: normal
status: open
title: smtplib.SMTP.login() breaks with unicode input
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8489>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:18:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 19:18:38 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1271877518.14.0.547860503922.issue5103@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch, with tests. I also had to rework the asyncore-based test server in test_ssl, and fixed an omission in _ssl.c's do_handshake method.

(works with OpenSSL 0.9.8k and 1.0.0)

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file17028/ssltimeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:20:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 19:20:20 +0000
Subject: [issue8484] ssl socket with certificate verification fails on
	SHA256	digest algorithm
In-Reply-To: <1271875976.3394.13.camel@localhost>
Message-ID: <4BCF4FF1.3090504@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The patch calls OpenSSL_add_all_algorithms(), though.

Ah, ok. The patch looks fine to me, then.

----------
title: ssl socket with certificate verification fails on SHA256 digest algorithm -> ssl socket with certificate verification fails on SHA256	digest algorithm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:24:20 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 21 Apr 2010 19:24:20 +0000
Subject: [issue8489] smtplib.SMTP.login() breaks with unicode input
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1271877860.23.0.943541494799.issue8489@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

SMTP (RFC 2821) doesn't support non-ASCII envelope addresses.  A better behavior here would be for connection.login to raise a ValueError or a TypeError whenever a non-str is passed in.

RFC 5336, though, adds the UTF8SMTP extension, which adds support for UTF-8 encoded unicode mailboxes.  If the server advertises the UTF8SMTP capability, then smtplib could encode unicode using UTF-8 and pass it on.

This is really a feature request (RFC 5336 support), not a bug.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8489>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:29:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 19:29:12 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271878152.59.0.148437657148.issue4256@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see why --help-options would need to be listed in help.  We could pick a more obscure name, too.  The point of this option is to support tools, not users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:29:53 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Wed, 21 Apr 2010 19:29:53 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271878193.2.0.986992462612.issue4256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I'll be happy to both fix things pointed by Steven and try some other approach, if that's required, but I would rather do it after a consesus is reached, so I don't have to do the same stuff several times (changing argparse tests requires some work - it's really awesome test suite).

What about optparse? Maybe there we can add this option without much thinking, by checking if help-options is used at the end of parsing? If not, we face the same problem as with argparse.

I don't really understand, why can't we just check if help-options is provided by the user and add our own, if it is not? Even if options are parsed several times (when doing some debugging I have seen my messages printed multiple times in help formatter), we should be able to inspect options in raw form and determine, whether --help-options is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:34:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 21 Apr 2010 19:34:01 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

The patch in attachment provides actual tests for asyncore.dispatcher class API, including all handle_* callback methods.

----------
assignee: josiahcarlson
files: asyncore.patch
keywords: patch, patch
messages: 103896
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson, michael.foord, r.david.murray
severity: normal
status: open
title: asyncore test suite
Added file: http://bugs.python.org/file17029/asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:38:16 2010
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 21 Apr 2010 19:38:16 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1271878193.2.0.986992462612.issue4256@psf.upfronthosting.co.za>
Message-ID: <m2wd11dcfba1004211238u12a3a19ey6f8d059dba572488@mail.gmail.com>


Steven Bethard <steven.bethard at gmail.com> added the comment:

2010/4/21 Filip Gruszczy?ski <report at bugs.python.org>:
> I don't really understand, why can't we just check if
> help-options is provided by the user and add our own,
> if it is not?

I'm sure it would be possible to do it this way. The question is
whether it makes sense to from the perspectives of code
maintainability and explaining awkward corner cases to users.

On Wed, Apr 21, 2010 at 12:29 PM, R. David Murray wrote:
> I don't see why --help-options would need to be listed in help.

Right. For argparse, suppressing the printing of --help-options in the
help message is as simple as setting help=SUPPRESS.

>  We could pick a more obscure name, too.

I think this is probably the best way forward. What is the format
that's being printed out? Is this a standard somewhere? Can we name
the flag something like "--print-parser-options-in-XXX-format"?

Steve

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:45:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 19:45:16 +0000
Subject: [issue8488] Docstrings of non-data descriptors "ignored"
In-Reply-To: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>
Message-ID: <1271879116.54.0.177140750238.issue8488@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There is either an issue or a python-dev (or maybe even python-ideas) discussion about this subject somewhere.  It's a much deeper issue than it appears on the surface.

----------
nosy: +r.david.murray
versions:  -Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8488>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:45:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 19:45:26 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1271879126.84.0.739866115304.issue4256@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

An obscure name reusing terms like ?compword? that can be found easily in Python docs and Bash completion docs would be best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:52:25 2010
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 21 Apr 2010 19:52:25 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1271879126.84.0.739866115304.issue4256@psf.upfronthosting.co.za>
Message-ID: <q2kd11dcfba1004211252uac4fa9d8u5307a89717f90aca@mail.gmail.com>


Steven Bethard <steven.bethard at gmail.com> added the comment:

On Wed, Apr 21, 2010 at 12:45 PM, ?ric Araujo <report at bugs.python.org> wrote:
> An obscure name reusing terms like ?compword? that can be found easily in Python docs and Bash completion docs would be best.

Seems sensible. Does anyone know if zsh uses the same or a different
mechanism? If possible, we should be producing output that either of
these could use.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:56:44 2010
From: report at bugs.python.org (Domen)
Date: Wed, 21 Apr 2010 19:56:44 +0000
Subject: [issue8489] smtplib.SMTP.login() breaks with unicode input
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1271879804.78.0.99598091175.issue8489@psf.upfronthosting.co.za>


Domen <ielectric at gmail.com> added the comment:

Plone currently just passes unicode data around, maybe additional documentation note will do for avoiding such trobules.

Thanks for quick response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8489>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:58:34 2010
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 21 Apr 2010 19:58:34 +0000
Subject: [issue8491] Need readline command and keybinding information
In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za>
Message-ID: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of the readline module refers to readline initialization files, but does not give any information about their format or the available commands. I realize that this is a standard part of environments that support readline, not anything specific to Python, but as long as the module documentations mentions the init file it should give a link to documentation about it.

----------
assignee: georg.brandl
components: Documentation
messages: 103902
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Need readline command and keybinding information
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8491>
_______________________________________

From report at bugs.python.org  Wed Apr 21 21:59:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 19:59:41 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271879981.92.0.1678519854.issue8480@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Martin: What is your OS? In msg103442 you wrote that you have gdb 7.0.1. Did you try to remove python-gdb.py? (test_gdb should remove and/or update this file!)

I tested test_gdb of py3k on Debian Sid (gdb 7.1) and Ubuntu 9.10 (gdb 7.0): I got a lot of errors but I see the gdb backtrace, so the "No frame is currently selected" error is fixed.

You should reopen the issue if it's not fixed on your host.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:01:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 20:01:43 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271880103.38.0.449375269127.issue8480@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

See msg103889. I said it's fixed, so I'm not sure what problem you are still trying to solve.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:02:07 2010
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 21 Apr 2010 20:02:07 +0000
Subject: [issue8492] Addition to readline module to get dictionary of
	keystrokes and commands
In-Reply-To: <1271880127.18.0.454462638892.issue8492@psf.upfronthosting.co.za>
Message-ID: <1271880127.18.0.454462638892.issue8492@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Requesting a function to be added to the readline module that produces a dictionary of the current keystroke bindings Also, one to write it to a file in readline init file format. This would be a big help for people interested in customizing the behavior of readline inside Python.

----------
components: Library (Lib)
messages: 103905
nosy: MLModel
severity: normal
status: open
title: Addition to readline module to get dictionary of keystrokes and commands
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8492>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:05:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 20:05:28 +0000
Subject: [issue8492] Addition to readline module to get dictionary of
	keystrokes and commands
In-Reply-To: <1271880127.18.0.454462638892.issue8492@psf.upfronthosting.co.za>
Message-ID: <1271880328.76.0.275814140396.issue8492@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8492>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:23:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 20:23:33 +0000
Subject: [issue8480] test_gdb: No frame is currently selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271881413.77.0.0777407329205.issue8480@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I read "it doesn't fix", sorry :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8480>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:25:10 2010
From: report at bugs.python.org (David Bolen)
Date: Wed, 21 Apr 2010 20:25:10 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271881510.31.0.676215647221.issue8455@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

For what it's worth, I added a few debugging statements to a local trunk checkout, and it looks like the port is getting lost somewhere along the way to setup the proxy... So the refused error is accurate and because it's trying the default port 80.  Note also that I think all the Proxy tests fail, even those saying they're ok, because the refused error shows up as a URLError which is what the test expects, but for other reasons.

Oh, and small item I noted while doing the test - the urllib2_localnet module doesn't clean up properly during the tests - all the local servers are left listening on their ports until all the tests are done.  Adding a call to self.httpd.server_close() at the end of run() in LoopbackHttpServerThread appears to fix that.

Here's a sample of one test... 

test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... Init done
Serving HTTP on localhost port 55161
Thread running
Calling handle request
proxy_url: http://localhost:55161
proxy_open: http None None localhost:55161
httplib _set_hostport(localhost,None)
httplib _set_hostport done host=localhost port=80
httplib.connect: Connecting to ('localhost', 80)
back from handle request

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:41:09 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Wed, 21 Apr 2010 20:41:09 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>


New submission from Matthew Cowles <mdcowles at users.sourceforge.net>:

[From a question first posted to python-help]

A socket's send function may return 0 if no bytes have been sent. Under at least OS X 10.6.2, it may also raise errno 35 (resource temporarily unavailable) if no network buffers are available. If a Python coder is using socket.send() that's no problem. They can catch the exception and try again. but it makes socket.sendall() (which is implemented as calls to send() ) not very useful. I expect that it would be fairly easy to have it check for that error number in addition to checking for an incomplete send.

As far as I'm aware, it's only OS X that ever does that.

----------
components: Library (Lib)
messages: 103908
nosy: mdcowles
severity: normal
status: open
title: socket's send can raise errno 35 under OS X, which causes problems in sendall
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:41:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 20:41:09 +0000
Subject: [issue8484] ssl socket with certificate verification fails on
	SHA256	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271882469.88.0.447612965947.issue8484@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r80314 (trunk), r80316 (2.6), r80317 (py3k), r80318 (3.1). Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:44:55 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 21 Apr 2010 20:44:55 +0000
Subject: [issue8485] Don't accept bytearray as filenames, or simplify the API
In-Reply-To: <1271852937.17.0.825806652857.issue8485@psf.upfronthosting.co.za>
Message-ID: <4BCF63F9.8050701@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Or perhaps the bytearray can be converted to a bytes object. This is not optimal performance-wise but is unlikely to make a difference in real-world code (if you are passing a filename to an external API, chances are some IO will occur which will dwarf the cost of creating a separate bytes object).
> 
> But I agree that supporting bytearrays in filename-taking functions, while "nice" from a consistency point of view, isn't really useful in practice. So I would be ok to remove that support if it simplifies (or avoids complexifying) the logic for those functions.

+1

bytearrays are basically the remains of the attempt to use mutable
byte string objects in Python 3.x. They may gain some usefulness
in the future, but I doubt that this will be in the area of filenames.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8485>
_______________________________________

From report at bugs.python.org  Wed Apr 21 22:50:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 21 Apr 2010 20:50:32 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1271883032.81.0.338201530607.issue7863@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Any thoughts on this last bit about using the registry to identify between workstation and server?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Wed Apr 21 23:17:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 21:17:10 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271884630.6.0.707296629059.issue7332@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a short shell script to reproduce the stack overflow:
 - create 100 Python modules: stack1 imports stack2, stack2 imports stack3, ...., and stack100 prints "hello"
 - each module calls os.system("cat /proc/%s/maps|grep stack" % os.getpid()) to display the stack map
 - set the max stack size to 128 KB

The stack starts with 86016 bytes and it crashs at import depth 6.

I don't know if my script is realistic (128 KB stack), but at least it shows a crash.

I think that most programs crash with small stack.

----------
Added file: http://bugs.python.org/file17030/import_stackoverflow.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Wed Apr 21 23:29:11 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 21 Apr 2010 21:29:11 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271885351.11.0.310328165413.issue8380@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm attaching a new version of the patch, for the py3k branch.

I changed my mind back about the breakpoint, using "id" and "builtin_id" as in my original patch.  I prefer it since it has a single argument, which makes it very convenient to work with in the various tests - textiowrapper_write takes an args tuple, which makes things like corrupting the pointer slightly more tricky.

The big change here is that I've changed the output format throughout to try to emulate Python 3 literals: a PyLongObject instance is now printed as digits, without a trailing "L".  I feel that the fact that gdb is running python 2 is really just an implementation detail, and that the pretty-printer ought to print in a format reflecting the language being debugged.

This also removes the 'u' prefix from strings, and I've added tests for 'bytes' (which get a "b" prefix).  I've also (I believe) correctly implemented the Python 3's literal representation for empty and non-empty sets and frozensets ( e.g. "{1, 2, 3}", as opposed to Python 2's "set([1, 2, 3])" )

More controversially, a PyUnicodeObject instance is printed using an emulation of Python 3's unicode_repr algorithm, which means that gdb prints unicode to sys.stdout, so that gdb will potentially print non-ASCII characters, using the encoding of sys.stdout.  This will only work if gdb's encoding is set to something that can cope with said characters:

Python 3.2a0 (py3k:80312M, Apr 21 2010, 17:00:02) 
[GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> id('????')

Breakpoint 1, builtin_id (self=<module at remote 0x7ffff7fd7df8>, v='????') at Python/bltinmodule.c:912
912		return PyLong_FromVoidPtr(v);

Note the unicode characters in the rendering of "v" in the breakpoint.

I suspect that this is a change too far (for example, I'm assuming a UTF-8 locale).

Any suggestions on what the output should look like for the unicode case?  

Would it be better if I coerce everything back to an escaped literal syntax that's encodable as ASCII?  That would probably avoid encoding and locale issues, but lose immediate readability for people able to read non-ASCII scripts.

All tests pass with both UCS2 and UCS4 builds on this Fedora 12 x86_64 box, building with --with-pydebug in both cases.

----------
Added file: http://bugs.python.org/file17031/port-gdb7-hooks-to-py3k-002.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Wed Apr 21 23:30:16 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 21 Apr 2010 21:30:16 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1271883032.81.0.338201530607.issue7863@psf.upfronthosting.co.za>
Message-ID: <4BCF6E99.7010002@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brian Curtin wrote:
> 
> Brian Curtin <curtin at acm.org> added the comment:
> 
> Any thoughts on this last bit about using the registry to identify between workstation and server?

I can't comment on that since I don't know anything much
about the MS registry and the entries used for the various
versions. Isn't there some page page on MSDN that explains
these ?

I do have one nit with your patch, though: could you please
remove the inline function check_registry() and instead use
a regular if-then-else for this ?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Wed Apr 21 23:37:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 21:37:13 +0000
Subject: [issue8491] Need readline command and keybinding information
In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za>
Message-ID: <1271885833.18.0.878040682057.issue8491@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8491>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:05:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 22:05:57 +0000
Subject: [issue8295] add unpack_archive to shutil
In-Reply-To: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>
Message-ID: <1271887557.87.0.175272686875.issue8295@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8295>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:08:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 22:08:22 +0000
Subject: [issue8295] add unpack_archive to shutil
In-Reply-To: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>
Message-ID: <1271887702.14.0.299031342536.issue8295@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8295>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:09:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 22:09:31 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1271887771.66.0.797065086159.issue8319@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8319>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:14:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 22:14:30 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1271888070.06.0.927021598297.issue8325@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello.

I reviewed the patch and it looks good to me apart from two minor things.

There?s one typo, ?argumets?, and one nitpick: I?ve seen a number of programs with more than one usage line, none of them numbers the lines. So remove ?1.? and ?2.?.

Thanks for the patch.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:23:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Apr 2010 22:23:06 +0000
Subject: [issue8295] add unpack_archive to shutil
In-Reply-To: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>
Message-ID: <1271888586.73.0.106425615821.issue8295@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8295>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:30:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 21 Apr 2010 22:30:26 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1271889026.24.0.850908247594.issue7863@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16371/issue7863.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:32:12 2010
From: report at bugs.python.org (Kees Cook)
Date: Wed, 21 Apr 2010 22:32:12 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271889132.21.0.63002587675.issue7332@psf.upfronthosting.co.za>


Kees Cook <kees at ubuntu.com> added the comment:

So, digging a little further, I think this is a now-fixed kernel bug with stack growth.  There were known issues prior to Sep 2009 with 64bit stack growth with ASLR, which is enabled by default.  Upstream fix:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=80938332d8cf652f6b16e0788cf0ca136befe0b5

This was fixed in stable releases of the Ubuntu kernels on Mar 16, 2010 (though the fix was included in Ubuntu 9.10 when it was released Oct 29, 2009).

The Launchpad bugs 432546 and 393022 were both filed prior to these kernel fixes, and show an un-maximized stack segment that has bumped up against the next-lower segment, which is how this kernel bug was manifesting.  (See their attached ProcMaps.txt files.)

I don't believe this is a Python bug, and I think the issue is solved for any distro that contains the above kernel fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:39:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 21 Apr 2010 22:39:57 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1271889597.66.0.33494404923.issue7863@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Updated patch to remove the function.

MSDN says nothing about available registry keys or their information, at least from what I could tell. I guess it is possible that future versions might not have the value we are looking for, but I kind of doubt that, plus the fallback value is what we've been doing all along. I realize that isn't strong reasoning, so I could remove that registry check if you aren't comfortable with it.

----------
Added file: http://bugs.python.org/file17032/issue7863.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:40:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 22:40:48 +0000
Subject: [issue8380] Port of the gdb7 debugging hooks to the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271889648.4.0.33092741405.issue8380@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch; applied as r80324. As it is an improvement over the status quo, I've applied it; I'll also be closing this issue.

I still get test failures which I report as a separate bug report.

As for displaying strings: I think it should do what gdb normally does in such cases, although I didn't investigate what that actually is.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8380>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:42:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 22:42:43 +0000
Subject: [issue8494] test_gdb assertEndsWith failing
In-Reply-To: <1271889763.37.0.542639938729.issue8494@psf.upfronthosting.co.za>
Message-ID: <1271889763.37.0.542639938729.issue8494@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

test_gdb fails on 3k, with the attached output.

----------
assignee: dmalcolm
files: test_gdb.txt
messages: 103919
nosy: dmalcolm, loewis
severity: normal
status: open
title: test_gdb assertEndsWith failing
versions: Python 3.2
Added file: http://bugs.python.org/file17033/test_gdb.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8494>
_______________________________________

From report at bugs.python.org  Thu Apr 22 00:48:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 22:48:20 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271890100.31.0.574177111808.issue7332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you Kees, this sounds quite likely. I will still commit the patch to remove the stack buffer, and then close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:01:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Apr 2010 23:01:18 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271890878.51.0.388824228949.issue7332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in trunk (r80325) and py3k (r80326). I won't backport it to 2.6/3.1 since it's not likely to fix anything in practice -- it's just a nice simplification. Thanks everyone for comments and patches.

----------
resolution:  -> works for me
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:10:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 23:10:25 +0000
Subject: [issue8494] test_gdb assertEndsWith failing
In-Reply-To: <1271889763.37.0.542639938729.issue8494@psf.upfronthosting.co.za>
Message-ID: <1271891425.72.0.660664932596.issue8494@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8494>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:22:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 21 Apr 2010 23:22:06 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271892126.6.0.336904776906.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

David, trying to get some more realistic IO benchmarks I did some more tests.  The idea is to have a threaded socket server, serving requests that take different amounts of time to process, and see how io response measures up for two classes of requests being serviced simultaneously.

Please see the evalsrv.rar for the client and server scripts.  The client uses multiprocessing to distance itself from the GIL issue.  The results on my dual core windows box are as follows (LEGACY_GIL is the mac, unfair GIL, ROUNDROBIN_GIL is the same with the fairness fix.  "with affinity" means that the server process is restricted to running on one core.

label        time                avg time             std.dev 

serial
((30, 500), (2.7145072907310848, 0.09047581466359553, 0.0041867466462554535))
((300, 10), (0.46542703053041656, 0.0015481250643121787, 0.0002282114778449236))

3.36s (3.18s) (total time, sum of individual classes)
simultaneous
((30, 500), (2.8820070707310563, 0.09605833283280416, 0.004430198440914231))
((300, 10), (3.2082978423235358, 0.010690429928943495, 0.014415958519681225))
3.21s (6.09s)

(for each test, you get the indvidual timing for each request class, and then a sum of total time and sum of individual times.)
Please don't read too much into small differences, this is a roughly one-off test here and likely contains noise.
A few things become apparent:
1) with LEGACY_GIL, affinity appears not to matter.  The 300 fast requests take longer to complete than the 30 slow requests if done in parallel, even though their serial execution time is roughly 1/5th.
2) With ROUNDROBIN_GIL, serial performance appears not to be affected, but simultaneous performance is much better:  end-to-end time is the same, but the sum of individual classes is lower.  That means that the client had to wait less for their IO results.
3) With ROUNDROBIN_GIL, if we put affinity on, we get the same kind of performance as with the LEGACY_GIL.


The most important points here are the two last ones, I think.  The fact that the sum of the individual request waits goes down is significant, and it is by no small amount that it drops.  But equally perplexing is the fact that forcing the server to one cpu, removes the "fairness" again.  It would appear that the behaviour of the synchronization object (an windows Semaphore in this case) changes depending on the number of cores, just as you had previously mentioned.  This is, however, a windows only effect, I think.  I must try to find out what is going on.

----------
Added file: http://bugs.python.org/file17034/evalsrv.rar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:25:26 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 21 Apr 2010 23:25:26 +0000
Subject: [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1271892326.86.0.632743523681.issue8299@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Sorry, all the benchmarks were missing from my last comment.  Here they are:
                     total time          avg time/request     stddev
LEGACY_GIL
	serial
	((30, 500), (2.6908777512225717, 0.08968708313486773, 0.0015164644061278888))
	((300, 10), (0.4470272758129874, 0.0014862882945551276, 0.00024585959927491124))
	3.30s (3.14s)  [end-to-end time, ( sum of total times)
	simultaneous
	((30, 500), (2.876280574765787, 0.09586895587753937, 0.0011848842024515473))
	((300, 10), (3.2645357161315194, 0.010877886016239504, 0.027372366395914234))
	3.27s (6.14s)

LEGACY_GIL, affinity on
	serial
	((30, 500), (2.8003825905247735, 0.09333925587376796, 0.013360667457052446))
	((300, 10), (0.45636945477707364, 0.001517769716542185, 0.00020067298808990378))
	3.43s (3.26s)
	simultaneous
	((30, 500), (2.8963266281049687, 0.09653735553913509, 0.0096323348697044))
	((300, 10), (3.212417639672081, 0.010703065845891957, 0.014433573531885001))
	3.21s (6.11s)

ROUNDROBIN_GIL
	serial
	((30, 500), (2.703059536896449, 0.09009326837163198, 0.0020036630273102198))
	((300, 10), (0.4539455433581643, 0.0015096094615377107, 0.00041274624690973134))
	3.32s (3.16s)
	simultaneous
	((30, 500), (3.2613636649350686, 0.10870530565570016, 0.02613516235517462))
	((300, 10), (1.4737764855589188, 0.004908413639163637, 0.002818028070766402))
	3.26s (4.74s)

ROUNDROBIN_GIL, affinity on
	serial
	((30, 500), (2.7145072907310848, 0.09047581466359553, 0.0041867466462554535))
	((300, 10), (0.46542703053041656, 0.0015481250643121787, 0.0002282114778449236))

	3.36s (3.18s)
	simultaneous
	((30, 500), (2.8820070707310563, 0.09605833283280416, 0.004430198440914231))
	((300, 10), (3.2082978423235358, 0.010690429928943495, 0.014415958519681225))
	3.21s (6.09s)
	
ROUNDROBIN_GIL, USE_FIFO_COND
	serial
	((30, 500), (2.7050386292112547, 0.09016071176643957, 0.0017078174777967025))
	((300, 10), (0.4478294727402505, 0.001488698051474884, 0.00012887034661806298))
	3.31s (3.15s)
	simultaneous
	((30, 500), (3.262343957123042, 0.10873750248518549, 0.02640198429431565))
	((300, 10), (1.5242242379967286, 0.005076519036171731, 0.0033917786033315026))
	3.26s (4.79s)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8299>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:41:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Apr 2010 23:41:29 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1271893289.17.0.591239589703.issue3864@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Skips ported to 2.6 in r80295, py3k in r80296, and 3.1 in r80297.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:56:32 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Wed, 21 Apr 2010 23:56:32 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1271894192.91.0.320106096516.issue8414@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

I've uploaded new versions of the patch.

__debug__: I removed the "if __debug__" clause and switched to skipUnless.

Exception args: I replaced str(e) with e.args. Thanks for pointing that out! I had thought args was going to be deprecated but I guess it's not (Issue6777).

----------
Added file: http://bugs.python.org/file17035/test_grammar.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8414>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:56:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 21 Apr 2010 23:56:52 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1271894212.37.0.0604627984481.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Ported to py3k in r80329.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:56:54 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Wed, 21 Apr 2010 23:56:54 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1271894214.48.0.163506394838.issue8414@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file17036/test_grammar.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8414>
_______________________________________

From report at bugs.python.org  Thu Apr 22 01:59:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 23:59:38 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271894378.18.0.458016423725.issue7332@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried to limit memory allocated on the stack while importing modules. Number of bytes allocated on the stack:
 - without my patch: 13792 bytes per import
 - with my patch: 1632 bytes per import
(using import_stackoverflow.sh, import a short Python module)

I guess that it will not fix the issue, only report the crash to another function.

I'm attaching the patch to this issue only to keep a copy of it. The patch is complex and there is no good reason to commit it since the problem doesn't come from Python.

The patch allocates filename buffers on the heap in import.c, zipimport.c and marshal.c.

----------
Added file: http://bugs.python.org/file17037/import_nostack_alloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:03:59 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 22 Apr 2010 00:03:59 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1271894639.49.0.487597912366.issue6085@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

There is a simple workaround to bypass the hostname resolution mechanism, so that the server can respond faster.

# This is a hack to patch slow socket.getfqdn calls that
# BaseHTTPServer (and its subclasses) make.
# See: http://bugs.python.org/issue6085
# See: http://www.answermysearches.com/xmlrpc-server-slow-in-python-how-to-fix/2140/

import BaseHTTPServer

def _bare_address_string(self):
    host, port = self.client_address[:2]
    return '%s' % host

BaseHTTPServer.BaseHTTPRequestHandler.address_string = \
        _bare_address_string

# End hack.

----------
nosy: +Santoso.Wijaya

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:43:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 00:43:07 +0000
Subject: [issue8495] test_gdb: use utf8+surrogateescape charset?
In-Reply-To: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>
Message-ID: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Because of a strange bug, gdb writes random bytes to stdout. test_gdb decodes output as utf8, but these random bytes cause a UnicodeDecodeError:

ERROR: test_int (__main__.PrettyPrintTests)
Verify the pretty-printing of various "int"/long values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_gdb.py", line 188, in test_int
    self.assertGdbRepr(1000000000000)
  File "Lib/test/test_gdb.py", line 176, in assertGdbRepr
    cmds_after_breakpoint)
  File "Lib/test/test_gdb.py", line 144, in get_gdb_repr
    import_site=import_site)
  File "Lib/test/test_gdb.py", line 120, in get_stack_trace
    out, err = self.run_gdb(*args)
  File "Lib/test/test_gdb.py", line 62, in run_gdb
    return out.decode('utf-8'), err.decode('utf-8')
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1882-1887: unsupported Unicode code range

surrogateescape should be used the invalid sequence using surrogates.

---

See attached file for the strange gdb bug.

command is the byte string "id(1000000000000)\n\0" (19 bytes, strlen=18), but gdb prints bytes after the \0. Stranger: print (*command)@15 does also prints these random bytes, whereas print (*command)@14 doesn't.

----------
components: Tests
files: gdb_bug.txt
messages: 103929
nosy: haypo
severity: normal
status: open
title: test_gdb: use utf8+surrogateescape charset?
versions: Python 3.2
Added file: http://bugs.python.org/file17038/gdb_bug.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8495>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:44:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 00:44:06 +0000
Subject: [issue8495] test_gdb: use utf8+surrogateescape charset?
In-Reply-To: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>
Message-ID: <1271897046.75.0.371051923126.issue8495@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17039/test_gdb_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8495>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:45:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 00:45:54 +0000
Subject: [issue8495] test_gdb: use utf8+surrogateescape charset?
In-Reply-To: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>
Message-ID: <1271897154.3.0.560775855357.issue8495@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

py3k tests pass on Debian Sid (gdb 7.1) without the patch, and pass on Ubuntu 9.10 (gdb 7.0) with the patch.

----------
nosy: +dmalcolm, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8495>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:47:53 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 22 Apr 2010 00:47:53 +0000
Subject: [issue8496] mailcap.lookup() returns filter iterator rather than list
	if key is given
In-Reply-To: <1271897273.03.0.77391363509.issue8496@psf.upfronthosting.co.za>
Message-ID: <1271897273.03.0.77391363509.issue8496@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

The lookup method in the Python 3.2 mailcap module still uses filter as if it will return a list, like it did in Python 2. If a value for the "key" argument is passed to the method, the method will return a filter iterator rather than a list.

I discovered this while running a test I created for mailcap. It's not checked in yet. See Issue6484.

This is probably low priority because mailcap.lookup() is an internal method. It is used by mailcap.findmatch(), which actually handles the filter iterator gracefully. Nevertheless, I don't think it should return a different type based on whether the key argument is passed. The fix is simple enough.

----------
components: Library (Lib)
files: mailcap.v3.patch
keywords: patch
messages: 103931
nosy: gnofi
severity: normal
status: open
title: mailcap.lookup() returns filter iterator rather than list if key is given
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17040/mailcap.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8496>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:49:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 00:49:14 +0000
Subject: [issue8494] test_gdb assertEndsWith failing: Unable to read
	information on python frame
In-Reply-To: <1271889763.37.0.542639938729.issue8494@psf.upfronthosting.co.za>
Message-ID: <1271897354.93.0.0273147074057.issue8494@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Looks to be a duplicate of #8482 ("unable to read python frame information").

----------
title: test_gdb assertEndsWith failing -> test_gdb assertEndsWith failing: Unable to read information on python frame

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8494>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:50:36 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 22 Apr 2010 00:50:36 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1271897436.2.0.408407582257.issue6484@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

Submitting Python 3 version of test. Note that it currently fails due to Issue8496.

It should use the same .mailcap file I submitted earlier.

----------
Added file: http://bugs.python.org/file17041/test_mailcap.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:53:32 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 22 Apr 2010 00:53:32 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1271897612.56.0.438259064449.issue6484@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file17042/test_mailcap.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:53:39 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 22 Apr 2010 00:53:39 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1271897619.2.0.718164291925.issue6484@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Removed file: http://bugs.python.org/file17041/test_mailcap.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:55:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 00:55:35 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271897735.41.0.751015381082.issue8482@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_gdb of py3k now pass with ./configure --with-pydebug (no optimization <=> -O0), but fail (Unable to read information on python frame) with ./configure (-O3). The test does also fail with -O1.

Recompile only ceval.c with -O0 is enough to fix this issue:
----
$ rm ./Python/ceval.o
$ vim Makefile
# replace -O3 by -O0
$ make && ./python Lib/test/regrtest.py -v test_gdb
# success
----

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Thu Apr 22 02:58:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Apr 2010 00:58:52 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1271897932.2.0.0617266181545.issue8263@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Skip committed to py3k in r80331.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Thu Apr 22 03:20:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Apr 2010 01:20:56 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1271899256.07.0.293233752766.issue8490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for writing these.

The patch looks good to me (caveat: I only have a passing familiarity with asyncore).  A couple of English nits:

   A server which listen on an address and dispatches the 

should be 'listens'

    # EADDRINUSE indicates the socket was correctly binded

should be 'bound'

And one style nit: I'd perfer to see a 'BaseTestAPI' that has no base class, and two TestCase subclasses that use BaseTestAPI as a mixin, one for use_poll=True and one for use_poll=False.  It's not a big deal, though; what you have is fine if you don't feel like changing it.

As discussed on #python-dev, it would be best to make a branch in which to apply this so you can run it on all the buildbots.  This is especially true since you have one test your comments indicate you are pretty sure is not going to work on all platforms, and it would be nice to add skips for those platforms before checking it in to trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Thu Apr 22 04:38:09 2010
From: report at bugs.python.org (reynaldo)
Date: Thu, 22 Apr 2010 02:38:09 +0000
Subject: [issue8497] Technology and Licensing Related Query
In-Reply-To: <4C13B9D0-9CF0-48E2-AE72-830EFBF202C2@w3.org>
Message-ID: <m2ka4f83ee11004211938sec62cc48w2e2de289ff9b2847@mail.gmail.com>


New submission from reynaldo <renben77 at gmail.com>:

Ok

---------- Forwarded message ----------
From: "Ian Jacobs" <ij at w3.org>
Date: Apr 21, 2010 5:14 AM
Subject: Re: Technology and Licensing Related Query
To: "Hila Pilcer" <hilap at meitar.com>

On 19 Apr 2010, at 3:32 PM, Hila Pilcer wrote:

Hello Hila,

W3C specifications may be used at no charge and without license; you may
create WSDL documents freely.

 _ Ian

----------
files: unnamed
messages: 103937
nosy: renben
severity: normal
status: open
title: Technology and Licensing Related Query
Added file: http://bugs.python.org/file17043/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8497>
_______________________________________
-------------- next part --------------
<p>Ok</p>
<p><blockquote type="cite">---------- Forwarded message ----------<br>From: &quot;Ian Jacobs&quot; &lt;<a href="mailto:ij at w3.org">ij at w3.org</a>&gt;<br>Date: Apr 21, 2010 5:14 AM<br>Subject: Re: Technology and Licensing Related Query<br>
To: &quot;Hila Pilcer&quot; &lt;<a href="mailto:hilap at meitar.com">hilap at meitar.com</a>&gt;<br><br><p><font color="#500050"><br>On 19 Apr 2010, at 3:32 PM, Hila Pilcer wrote:<br><br>&gt; To whom it may concern,<br>&gt;<br>
&gt; We write to you on be...</font></p>
Hello Hila,<br>
<br>
W3C specifications may be used at no charge and without license; you may create WSDL documents freely.<br>
<br>
??_ Ian<p><font color="#500050"><br><br>&gt; Many thanks<br>&gt;<br>&gt; Best regards<br>&gt;<br>&gt; Hila Pilcer, Adv.<br>&gt; Meitar Liquornik Geva &amp; Leshem Brandwein, L...</font></p><font color="#888888">
--<br>
Ian Jacobs (<a href="mailto:ij at w3.org" target="_blank">ij at w3.org</a>) ?? ??<a href="http://www.w3.org/People/Jacobs/" target="_blank">http://www.w3.org/People/Jacobs/</a><br>
Tel: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??+1 718 260 9447<br>
<br>
<br>
</font></blockquote></p>

From report at bugs.python.org  Thu Apr 22 04:39:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 22 Apr 2010 02:39:38 +0000
Subject: [issue8497] Technology and Licensing Related Query
In-Reply-To: <m2ka4f83ee11004211938sec62cc48w2e2de289ff9b2847@mail.gmail.com>
Message-ID: <1271903978.19.0.115890796396.issue8497@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8497>
_______________________________________

From report at bugs.python.org  Thu Apr 22 07:20:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 22 Apr 2010 05:20:09 +0000
Subject: [issue8495] test_gdb: use utf8+surrogateescape charset?
In-Reply-To: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>
Message-ID: <1271913609.73.0.713696223613.issue8495@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the "replace" handler would be more appropriate here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8495>
_______________________________________

From report at bugs.python.org  Thu Apr 22 08:04:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 22 Apr 2010 06:04:46 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1271916286.79.0.623429572881.issue5650@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Updated in the r80336 through r80339. Thanks for the note, Ezio.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Thu Apr 22 09:32:22 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 22 Apr 2010 07:32:22 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1271921542.41.0.546152815631.issue6085@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Yes, performing a DNS resolution every time we log something is definitely sub-optimal. We should perform it only once, and cache the result.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Thu Apr 22 10:24:27 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 22 Apr 2010 08:24:27 +0000
Subject: [issue8483] asyncore.dispatcher's __getattr__ method produces
	confusing effects
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271924667.6.0.590596594101.issue8483@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

I definitely like the patch, but ideally we would also have a patch adding a __str__ on dispatcher, right? Which would just return the repr(self) result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:02:53 2010
From: report at bugs.python.org (Daniel Evers)
Date: Thu, 22 Apr 2010 10:02:53 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>


New submission from Daniel Evers <dermojo at googlemail.com>:

I'm trying to rewrite a server application in python that accepts exactly 1 connection. I have a previous version written in C that can call listen() on a socket with a backlog of 0 connections, but this is not possible in python. In Modules/socketmodule.c (function socket_listen) the backlog is reset to at least "1".

----------
components: Extension Modules
messages: 103942
nosy: Daniel.Evers
severity: normal
status: open
title: Cannot use backlog = 0 for sockets
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:26:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 10:26:00 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271931960.7.0.337274411193.issue8092@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17010/utf8_surrogate_error-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:31:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Apr 2010 10:31:07 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <1238602458.06.0.807356829134.issue5650@psf.upfronthosting.co.za>
Message-ID: <1271932267.82.0.417170021618.issue5650@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

You?ve added references to current RFCs without removing obsolete ones. Why not remove mention of obsoleted RFCs?

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:33:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 10:33:18 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271932398.43.0.80187447064.issue8498@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:35:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 10:35:32 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1271932531.96.0.963925328969.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15863/thread_py_decref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:35:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 10:35:37 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1271932537.45.0.109526346858.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15880/_curses_panel_py_decref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:35:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 22 Apr 2010 10:35:59 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <1271932267.82.0.417170021618.issue5650@psf.upfronthosting.co.za>
Message-ID: <20100422103541.GG14671@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

It was intentional as not to remove the old RFC references because
certain parsing behaviours follow them compatibility purposes. If you
look at test_urlparse.py you might get the specifics of parsing
corresponding a RFC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:48:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 10:48:19 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1271933299.94.0.905413766683.issue8490@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some remarks:
- I agree with RDM's comment regarding inheritance
- you don't use use_poll in loop_waiting_for_flag()
- calling time.sleep() in loop_waiting_for_flag() looks wrong to me
- test_handle_error should check that the exception state is the expected one (ZeroDivisionError), if at all possible
- in test_set_reuse_addr, if SO_REUSEADDR fails I would suggest skipping the test with self.skip(...), rather than passing silently
- in test_set_reuse_addr, sock.close() rather than sock.close
- does asyncore support IPv6? test_create_socket checks only AF_INET
- do you plan to also test UDP? :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Thu Apr 22 12:59:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 10:59:21 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1271933961.56.0.98813483086.issue8124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch fixes this issue: PyFile_WriteObject() doesn't call PyObject_Str() to avoid PyErr_CheckSignals(). I'm not sure that it's the right approch because it may change the behaviour of existing code when getting a signal.

----------
keywords: +patch
Added file: http://bugs.python.org/file17044/pyfile_writeobject_nosignal.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:08:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Apr 2010 11:08:01 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <20100422103541.GG14671@remy>
Message-ID: <4BD02E0B.7010202@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the explanation. Would it make sense to have either different
functions or a switch to existing ones to tell if we want legacy or
modern parsing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:11:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 11:11:44 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1271934704.35.0.552890862257.issue8124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, forget my pyfile_writeobject_nosignal.patch, it's not the right approach.

New patch: mywrite() uses its own implementation PyFile_WriteString(), sys_pyfile_write(), which doesn't call PyErr_CheckSignals():


/* Implementation of PyFile_WriteString() no calling PyErr_CheckSignals():
 * mywrite() should not execute any Python signal handler to avoid raising an
 * error because mywrite() ignores all errors */

----------
Added file: http://bugs.python.org/file17045/mywrite_nosignal.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:12:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 11:12:02 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1271934722.04.0.993700801359.issue8124@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17044/pyfile_writeobject_nosignal.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:14:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 11:14:45 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1271934885.96.0.32444493.issue8124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The goal is this issue is also to catch SIGINT when starting Python. It now works in Python trunk and py3k, but not in verbose mode because mywrite() eats errors (especially the KeyboardInterrupt raised by the default SIGINT handler) and calls indirectly Python signal handlers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:15:04 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 22 Apr 2010 11:15:04 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <4BD02E0B.7010202@netwok.org>
Message-ID: <20100422111451.GH14671@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Thu, Apr 22, 2010 at 11:08:01AM +0000, ?ric Araujo wrote:
> Thanks for the explanation. Would it make sense to have either different
> functions or a switch to existing ones to tell if we want legacy or
> modern parsing?

Hard at the moment, or is it a bleeding requirement? I doubt. 
But what is worth is full compliance on all scales with STD 66.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:25:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 11:25:37 +0000
Subject: [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: <1271935537.74.0.7605312557.issue8195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r80349 (py3k), r80351 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8195>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:30:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 11:30:18 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1271935818.95.0.0561436942529.issue8211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #8366 was caused by a fix of issue #1628484 (and ok, indirectly by my change). Issue #8366 is now fixed. Can I close this issue again or do you think that there is still something to do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:31:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 11:31:59 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1271935919.9.0.678729791644.issue8305@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +benjamin.peterson, georg.brandl, gvanrossum, pitrou, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8305>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:32:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Apr 2010 11:32:45 +0000
Subject: [issue8474] Duplicate tests in email test suite
In-Reply-To: <1271786320.05.0.85623215859.issue8474@psf.upfronthosting.co.za>
Message-ID: <1271935965.44.0.0788421552917.issue8474@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r80350 (trunk), r80352 (release26-maint), r80353 (py3k) and r80354 (release31-maint), thanks for the patch!

----------
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8474>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:35:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 22 Apr 2010 11:35:09 +0000
Subject: [issue8475] build-installer fix for doc building on OSX 10.4
In-Reply-To: <1271804004.62.0.250618279224.issue8475@psf.upfronthosting.co.za>
Message-ID: <1271936109.84.0.16168067413.issue8475@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r80355-

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8475>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:36:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Apr 2010 11:36:21 +0000
Subject: [issue5650] Obsolete RFCs should be removed from doc of
	urllib.urlparse
In-Reply-To: <20100422111451.GH14671@remy>
Message-ID: <4BD034A0.3060000@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

(Not sure I understand ?bleeding requirement?, but I get the gist.)

Full compliance with STD 66 is indeed the most desirable goal, thanks
for your work in that direction! I just thought that some corner cases
were not compliant because of backwards compat (hence the disabled tests
in test_urlparse).

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5650>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:39:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 11:39:01 +0000
Subject: [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: <1271936341.01.0.743486131212.issue8215@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +barry, benjamin.peterson, brett.cannon, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8215>
_______________________________________

From report at bugs.python.org  Thu Apr 22 13:39:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 11:39:10 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1271936350.23.0.121146313523.issue8305@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'll leave this to our numpy experts. I don't even know how to unit test this without installing numpy.

----------
assignee:  -> teoliphant
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8305>
_______________________________________

From report at bugs.python.org  Thu Apr 22 14:00:31 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 22 Apr 2010 12:00:31 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271937631.54.0.476813065765.issue8498@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

That's a non-portable user of listen()'s backlog, see http://www.opengroup.org/onlinepubs/009695399/functions/listen.html:
A backlog argument of 0 may allow the socket to accept connections, in which case the length of the listen queue may be set to an implementation-defined minimum value.

Furthermore, python's socket documentation makes it clear:
Enable a server to accept connections.  The backlog argument must be at least 1; it specifies the number of unaccepted connection that the system will allow before refusing new connections.

If you really want to only accept 1 connection (I'm talking of sending back a SYN-ACK, not an accept() call), you can just close the server socket as soon as you've done the accept, and re-open it when you're ready to process another request. Or you could accept new connections and close them immediately (but then you'd send back a SYN-ACK then a FIN).

So I'd say it's not a python bug.

----------
assignee:  -> tarek
components: +Distutils -Extension Modules
nosy: +neologix, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Thu Apr 22 14:11:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 12:11:18 +0000
Subject: [issue8485] Don't accept bytearray as filenames, or simplify the API
In-Reply-To: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>
Message-ID: <1271938278.63.0.237138707427.issue8485@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MvL, MaL and Antoine Pitrou agreed to drop support of bytearray filenames in Python. I choosed to remove it directly in Python 3.2 because it wasn't really used, open() and os.path never supported bytearray filenames, and I will simplify the other issues related to surrogates in filenames.

Fixed: r80361 (py3k), don't backport to 3.1.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8485>
_______________________________________

From report at bugs.python.org  Thu Apr 22 14:28:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 12:28:53 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1271939333.5.0.912223094508.issue6484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ezio.melotti
priority: low -> normal
stage: unit test needed -> patch review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Thu Apr 22 14:30:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 12:30:33 +0000
Subject: [issue8496] mailcap.lookup() returns filter iterator rather than list
	if key is given
In-Reply-To: <1271897273.03.0.77391363509.issue8496@psf.upfronthosting.co.za>
Message-ID: <1271939433.52.0.680556129457.issue8496@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks goot to me.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> patch review
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8496>
_______________________________________

From report at bugs.python.org  Thu Apr 22 14:31:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 12:31:02 +0000
Subject: [issue8496] mailcap.lookup() returns filter iterator rather than list
	if key is given
In-Reply-To: <1271897273.03.0.77391363509.issue8496@psf.upfronthosting.co.za>
Message-ID: <1271939462.85.0.542508867533.issue8496@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Good, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8496>
_______________________________________

From report at bugs.python.org  Thu Apr 22 14:31:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 12:31:10 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1271939470.91.0.715315855164.issue6484@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:12:47 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 22 Apr 2010 13:12:47 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271941967.66.0.351386653677.issue8498@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> Furthermore, python's socket documentation makes it clear:

Why does CPython go out of its way to make it impossible to pass 0 to the platform listen() API?  The part of the specification you quoted makes it very clear that 0 is a valid value for this argument.  And 0 seems to have a very different meaning than 1, but for some reason CPython thinks that 1 is a better thing for 0 to mean.

Perhaps there is a real reason someone thought to add this check in sock_listen, but if not, I think it's worth considering removing this check.

Unfortunately the commit message for the revision which added this check (r3880) is not informative:

sock_listen: ensure backlog argument is at least1

> If you really want to only accept 1 connection (I'm talking of sending back a SYN-ACK, not an accept() call), you can just close the server socket

This makes perfect sense, though, and is good advice in general.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:17:59 2010
From: report at bugs.python.org (resc)
Date: Thu, 22 Apr 2010 13:17:59 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1271889132.21.0.63002587675.issue7332@psf.upfronthosting.co.za>
Message-ID: <u2hcfb5a3d21004220617ud36d7bbcjd3951145d3e19bf5@mail.gmail.com>


resc <thomathom at gmail.com> added the comment:

> This was fixed in stable releases of the Ubuntu
> kernels on Mar 16, 2010 (though the fix was
> included in Ubuntu 9.10 when it was released
> Oct 29, 2009).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:18:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 22 Apr 2010 13:18:29 +0000
Subject: [issue8475] build-installer fix for doc building on OSX 10.4
In-Reply-To: <1271804004.62.0.250618279224.issue8475@psf.upfronthosting.co.za>
Message-ID: <1271942309.76.0.174462709418.issue8475@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It seems to work fine, so merged as r80365, r80366, r80367.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8475>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:21:51 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 22 Apr 2010 13:21:51 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271942511.07.0.351228259848.issue8482@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

See https://bugzilla.redhat.com/show_bug.cgi?id=556975#c21

I'll try to summarize: as I understand things, the issue is that on 64-bit gcc builds with enough optimization, the argument "PyFrameObject *f" is passed as a register, and that gets clobbered at various locations within the implementation of PyEval_EvalFrameEx.

The DWARF debug data contains a mapping between ranges of program counter values and methods for calculating the values of variables, and in many locations within PyEval_EvalFrameEx, it doesn't have enough information to figure out what the value of "f" is.

It works on i386: the calling conventions are different, and it's fairly easy for gdb to walk up the stack and find "f".

I believe my RH colleagues who hack on gcc and gdb are working on improving this so that DWARF can handle such cases (where "f" doesn't change during the function call), but Jakub describes that as "at least a year from now"

In the meantime there are some options.

(i) A dirty hack is that in some places in the function on x86_64 I've seen that the value of "f" is stored in the $rbp register.  We could use something like this as a fallback for when directly querying gdb for "f" fails:
  _type_PyFrameObjectPtr = gdb.lookup_type('PyFrameObject').pointer()
  f = gdb.parse_and_eval('$rbp').cast(_type_PyFrameObjectPtr)
and then see if the value looks sane (e.g. does it have a meaningful ob_type?  does 0 ==strcmp($rbp->ob_type->tp_name, "frame"); if so, then that's probably the value of "f", and use it.

Obviously that would be highly fragile; it may be something I'm seeing on my particular version of gcc, but might not work for other people's gcc.  Also I suspect that it will give misleading results when traversing the stack of C-level frames.

Another approach would be to simply accept that it isn't going to work on x86_64 with gcc with optimizations turned on until a later version of gcc.

We could handle this:
(ii) by trying to detect this situation during test_gdb.py, and to skip the affected tests.
(iii) by generalizing the tests so that they can handle the case where arbitrary frames aren't readable.

Approach (iii) seems most promising to me, and I'll try to cook up a patch (though I want to try approach (i), as it would be nice to get visibility into these frames)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:21:59 2010
From: report at bugs.python.org (resc)
Date: Thu, 22 Apr 2010 13:21:59 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1271942519.67.0.631678582565.issue7332@psf.upfronthosting.co.za>


resc <thomathom at gmail.com> added the comment:

Argh, that e-mail didn't work.  Anyway, I just wanted to say that the kernel explanation is consistent with my experience, I had a crash every week up until recently, when I upgraded, but in the past few days I haven't been able to reproduce it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:22:25 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 22 Apr 2010 13:22:25 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271942545.09.0.296933458003.issue8498@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee: tarek -> 
components: +Library (Lib) -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:25:13 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 22 Apr 2010 13:25:13 +0000
Subject: [issue8494] test_gdb assertEndsWith failing: Unable to read
	information on python frame
In-Reply-To: <1271889763.37.0.542639938729.issue8494@psf.upfronthosting.co.za>
Message-ID: <1271942713.13.0.719933463898.issue8494@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks - yes, this does indeed look like a dup of issue 8482; resolving it as such.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_gdb - "(unable to read python frame information)" mismatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8494>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:30:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 13:30:31 +0000
Subject: [issue8496] mailcap.lookup() returns filter iterator rather than list
	if key is given
In-Reply-To: <1271897273.03.0.77391363509.issue8496@psf.upfronthosting.co.za>
Message-ID: <1271943031.83.0.68142807037.issue8496@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r80369. Thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8496>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:46:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Apr 2010 13:46:30 +0000
Subject: [issue8482] test_gdb - "(unable to read python frame information)"
	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271943990.08.0.929321471337.issue8482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks, I understood your summary significantly better than I did the bug discussion :)

Any of your 3 options sounds reasonable to me (although i. sounds potentially fragile in the face of different versions of gcc, so iii. might be necessary anyway).

The quick and dirty approach would be a variant of ii. that just skipped the offending test for GCC on x86_64 machines. The platform library would make that fairly straightforward:

>>> platform.python_compiler()
'GCC 4.4.1'
>>> platform.machine()
'x86_64'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Thu Apr 22 15:57:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 13:57:30 +0000
Subject: [issue8482] test_gdb,
	gdb/libpython.py: Unable to read information on python frame
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271944650.67.0.655493407914.issue8482@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> the issue is that on 64-bit gcc builds with enough optimization, 
> the argument "PyFrameObject *f" is passed as a register, 
> and that gets clobbered at various locations within the
> implementation of PyEval_EvalFrameEx.

test_gdb fails (Unable to read information on python frame) on my i386 computer (32 bits) with -O1 (but it doesn't with -O0). I'm using Debian Sid: gcc 4.4.3 and gdb 7.1.

----------
title: test_gdb - "(unable to read python frame information)" mismatch -> test_gdb, gdb/libpython.py: Unable to read information on python frame

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8482>
_______________________________________

From report at bugs.python.org  Thu Apr 22 16:07:35 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 22 Apr 2010 14:07:35 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1271945255.51.0.593081219859.issue7865@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Patch and test to stop swallowing exceptions on stream close(), for python SVN trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file17046/release_io_close_exceptions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Thu Apr 22 16:11:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 14:11:43 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1271945503.12.0.847221421432.issue7865@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Thu Apr 22 16:56:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 14:56:12 +0000
Subject: [issue8499] Set a timeout in test_urllibnet
In-Reply-To: <1271948172.1.0.95585075241.issue8499@psf.upfronthosting.co.za>
Message-ID: <1271948172.1.0.95585075241.issue8499@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

As #8460 (test_urllib2net), test_urllibnet fails if a website doesn't answer. Today, it was www.python.org during few minutes:

http://www.python.org/dev/buildbot/all/builders/amd64 gentoo 3.1/builds/482/steps/test/logs/stdio
---
test_urllibnet
test test_urllibnet failed -- multiple errors occurred; run in verbose mode for details
---
(the test was executed again, but www.python.org was back)

test_urllib should use a timeout, as done for test_urllib2: see #8460.

----------
components: Library (Lib), Tests
messages: 103971
nosy: haypo, orsenthil
severity: normal
status: open
title: Set a timeout in test_urllibnet
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8499>
_______________________________________

From report at bugs.python.org  Thu Apr 22 18:14:16 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 22 Apr 2010 16:14:16 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1271952856.91.0.300215103482.issue8490@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> should be 'listens'
[...]
> should be 'bound'

done

> I'd prefer to see a 'BaseTestAPI' that has no base class, and two 
> TestCase subclasses that use BaseTestAPI as a mixin, one for 
> use_poll=True and one for use_poll=False.

done

> - you don't use use_poll in loop_waiting_for_flag()

whoops! thanks

> - calling time.sleep() in loop_waiting_for_flag() looks wrong to me

time.sleep() in that loop grants that the condition is retried for at least 1 second before failing the test. By removing time.sleep() a test which is supposed to fail will fail almost immediately.

> - test_handle_error should check that the exception state is the 
> expected one (ZeroDivisionError), if at all possible

Good advice, done.

> - in test_set_reuse_addr, if SO_REUSEADDR fails I would suggest skipping the test with self.skip(...),

done

> in test_set_reuse_addr, sock.close() rather than sock.close

whoops =)

> does asyncore support IPv6? test_create_socket checks only AF_INET

I don't think it would worth it. create_socket() is just a thin wrapper around socket.socket(). Actually I wasn't even sure to add that test or not.

> - do you plan to also test UDP? :)

Unfortunately asyncore does not support UDP.
At a first look it would seems so, since create_socket() accepts two parameters, family and *type*:

    def create_socket(self, family, type):
        sock = socket.socket(family, type)

...but actually we can only use SOCK_STREAM, as the API just takes care of wrapping send() and recv() calls, not recvfrom() and sendto().

----------
Added file: http://bugs.python.org/file17047/asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Thu Apr 22 19:42:43 2010
From: report at bugs.python.org (Zach Lym)
Date: Thu, 22 Apr 2010 17:42:43 +0000
Subject: [issue8500] Erroneous Invalid Syntax Error
In-Reply-To: <1271958163.54.0.165869378642.issue8500@psf.upfronthosting.co.za>
Message-ID: <1271958163.54.0.165869378642.issue8500@psf.upfronthosting.co.za>


New submission from Zach Lym <zachlym at indolering.com>:

>>> I love you python
  File "<stdin>", line 1
    I love you python
         ^
SyntaxError: invalid syntax
>>>

There is nothing invalid about that!

----------
components: None
messages: 103973
nosy: indolering
severity: normal
status: open
title: Erroneous Invalid Syntax Error
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8500>
_______________________________________

From report at bugs.python.org  Thu Apr 22 19:44:24 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 22 Apr 2010 17:44:24 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1271958264.01.0.497422235322.issue8493@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

The problem is that if you run out of "network buffers" (I guess it's equivalent to Unix socket buffers), what do you do ?
If the network or the receiving host is congested, spinning around the send call trying to resend the data isn't going to improve things, you should probably wait a little before retrying. Furthermore, if you get this type of error, it's probably because you're using non-blocking sockets. And if it's the case, you should be prepared to this type of transient error, and use socket.send instead (so that you can sleep, retry, etc if necesssary).

----------
nosy: +exarkun, neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Thu Apr 22 19:45:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Apr 2010 17:45:42 +0000
Subject: [issue8500] Erroneous Invalid Syntax Error
In-Reply-To: <1271958163.54.0.165869378642.issue8500@psf.upfronthosting.co.za>
Message-ID: <1271958342.58.0.0459540194987.issue8500@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Except the report :)

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8500>
_______________________________________

From report at bugs.python.org  Thu Apr 22 19:46:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 17:46:31 +0000
Subject: [issue8500] Erroneous Invalid Syntax Error
In-Reply-To: <1271958163.54.0.165869378642.issue8500@psf.upfronthosting.co.za>
Message-ID: <1271958391.39.0.484662064537.issue8500@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Surely you forgot to capitalize Python, not to mention the lack of punctuation.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8500>
_______________________________________

From report at bugs.python.org  Thu Apr 22 20:52:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 18:52:37 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1271962357.56.0.392159484358.issue6085@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
priority:  -> normal
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Thu Apr 22 21:41:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 19:41:22 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1271965282.7.0.107913161042.issue8092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed: r80382 (py3k), r80383 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Thu Apr 22 22:02:04 2010
From: report at bugs.python.org (Daniel Evers)
Date: Thu, 22 Apr 2010 20:02:04 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271966524.61.0.5942977062.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

Thanks for your help. I'll close the listen socket.

Nevertheless I'd like to understand the check in sock_listen. The commit message is not very helpful, I agree, that's why I wrote this issue. 0 is a valid value, and I'd suggest two ways to handle this situation:
1. Always set backlog at least to 1 (like now), but make this explicit in the documentation (docs.python.org says "should be at least 1" which is not the same as "will be at least 1")
2. Allow backlog = 0 and make a note in the docs that the exact behaviour will be implementation/OS-specific.

In case (1) the hint to close the listen socket should also be added to the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Thu Apr 22 23:35:45 2010
From: report at bugs.python.org (Jim Fulton)
Date: Thu, 22 Apr 2010 21:35:45 +0000
Subject: [issue8501] --dry-run option doesn't work
In-Reply-To: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>
Message-ID: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

The --dry-run option is ignored by the install command.
It leads to an error when used as a global option.

It should be fixed or removed.  I vote for removal, but don't really care. Removal seems easier. :)

To reproduce, create the simple project:

  http://docs.python.org/distutils/introduction.html#a-simple-example

and then try the option.

See also:

  http://mail.python.org/pipermail/distutils-sig/2010-April/016000.html

----------
assignee: tarek
components: Distutils
messages: 103979
nosy: j1m, tarek
severity: normal
status: open
title: --dry-run option doesn't work
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8501>
_______________________________________

From report at bugs.python.org  Thu Apr 22 23:37:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 22 Apr 2010 21:37:01 +0000
Subject: [issue8501] --dry-run option doesn't work
In-Reply-To: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>
Message-ID: <1271972221.08.0.252323843651.issue8501@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8501>
_______________________________________

From report at bugs.python.org  Thu Apr 22 23:42:30 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 22 Apr 2010 21:42:30 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1271972550.22.0.290265036041.issue7384@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Instead to test in setup.py we could use result from configure script - just uncomment line and use it

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Thu Apr 22 23:48:10 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 22 Apr 2010 21:48:10 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1271972890.75.0.122619249287.issue8211@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I think the issue can be closed again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Apr 22 23:49:36 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 22 Apr 2010 21:49:36 +0000
Subject: [issue8484] ssl socket with certificate verification fails on
	SHA256	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271972976.03.0.586927467304.issue8484@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Probably test case will fail is sha256 module is not loaded - openssl versions before 0.9.8

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Thu Apr 22 23:54:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 21:54:50 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1271973290.06.0.880203942266.issue8211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Even if this issue doesn't fix all the configure "complete mess", I think that it improves it a little bit. Open new issues if you would like to fix other parts of the configure script.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Fri Apr 23 00:13:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 22:13:32 +0000
Subject: [issue8484] ssl socket with certificate verification fails on
	SHA256	digest algorithm
In-Reply-To: <1271972976.03.0.586927467304.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271974541.3473.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Probably test case will fail is sha256 module is not loaded - openssl versions before 0.9.8

Yes, this has been fixed in r80375.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8484>
_______________________________________

From report at bugs.python.org  Fri Apr 23 00:25:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Apr 2010 22:25:14 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1271975114.68.0.807557563154.issue4768@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Fri Apr 23 00:44:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 22:44:53 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1271976293.85.0.79665631183.issue4768@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> high
stage:  -> patch review
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Fri Apr 23 00:47:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 22:47:44 +0000
Subject: [issue8465] re: Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271976464.36.0.800120562352.issue8465@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not sure why this was assigned to me.

----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Fri Apr 23 00:47:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 22:47:56 +0000
Subject: [issue8465] re: Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271976476.04.0.291242783855.issue8465@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Fri Apr 23 01:16:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 23:16:21 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271978181.98.0.821133742227.issue8498@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The request to allow 0 looks reasonable to me. Now if someone wants to propose a patch (+ tests if there's any way of testing for this).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Fri Apr 23 01:16:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Apr 2010 23:16:37 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271978197.04.0.97915488874.issue8498@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> low
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Fri Apr 23 02:18:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Apr 2010 00:18:31 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1271981911.75.0.739266428281.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed to r80392 (trunk) and r80394 (py3k). Am pondering a partial backport of the SSL shutdown fixes to 2.6 and 3.1 (test_ftplib doesn't need any backport since it doesn't support TLS in these branches).

----------
assignee:  -> pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Apr 23 03:10:07 2010
From: report at bugs.python.org (jhg)
Date: Fri, 23 Apr 2010 01:10:07 +0000
Subject: [issue8502] proposal: encourage xgettext rather than pygettext.py in
	gettext docs
In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>
Message-ID: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>


New submission from jhg <jhg at upb.de>:

Wanting to figure out how to support multiple languages in my applications I read the gettext documentation and got to the part saying one should use pygettext.py to create .po files.

After copying that program from the python SVN repository I later found out that it cannot cope with plurals, i.e. ngettext(). xgettext can do that just fine. Since pygettext.py was not modified in 5 years I propose changing the documentation of gettext to encourage xgettext rather than pygettext.py.

My proposed changes are attached (edited as text file; I do not know how to convert it to a webpage and hence did not test that).
I used the 2.7b1 documentation, but the patch appears to apply just as well to the 3.1.2 documentation.

----------
assignee: georg.brandl
components: Documentation
files: gettext.txt.patch
keywords: patch
messages: 103988
nosy: georg.brandl, jhg
severity: normal
status: open
title: proposal: encourage xgettext rather than pygettext.py in gettext docs
versions: Python 2.7
Added file: http://bugs.python.org/file17048/gettext.txt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8502>
_______________________________________

From report at bugs.python.org  Fri Apr 23 03:55:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 01:55:23 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1271987723.83.0.718380813943.issue4768@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: barry -> r.david.murray
resolution:  -> accepted
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:12:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 23 Apr 2010 07:12:27 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1272006747.18.0.335024436783.issue8211@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Even if this issue doesn't fix all the configure "complete mess", I think that it improves it a little bit. Open new issues if you would like to fix other parts of the configure script.

Viktor, you are still missing the point and please stop closing the issue again and again.

Please change the configure.in script to only override the CFLAGS in case they were set before entering the AC_PROG_CC part !

I've explained that over and over again and I don't understand why you are being completely ignorant of the implications of your change.

The Mac OS X fix is unrelated to this change.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:27:32 2010
From: report at bugs.python.org (Sreejith Madhavan)
Date: Fri, 23 Apr 2010 07:27:32 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1272007652.63.0.548586963989.issue7567@psf.upfronthosting.co.za>


Sreejith Madhavan <sreejithm at gmx.com> added the comment:

Thanks for the patch.
I can confirm that the patch works for 64bit builds of python-2.6.5 on Solaris (amd64 and sparc) and RHEL5 amd64. The curses library used was ncurses-5.7 with widechar support.

----------
nosy: +Sreejith.Madhavan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:33:07 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Apr 2010 07:33:07 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272007987.22.0.097076829486.issue8325@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks for proofreading. I've uploaded a new version here with typo fix, but do not removed 1., 2. numbering. It is a very awesome feature of console UI. When you're in a hurry (and you always in a hurry when you forget something) it is easy to miss the line that starts with "Usage:" or the line below it that may be thought as continuation of arguments. The digit prefix gives you a clear signal that there is more than one way to run this. If you need an authority, take a look at the tool you are using to commit the patch. =)

----------
Added file: http://bugs.python.org/file17049/8325.improve-regrtest-help-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:38:08 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 23 Apr 2010 07:38:08 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1272006747.18.0.335024436783.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BD14E5C.1080200@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> Please change the configure.in script to only override the CFLAGS in case they were set before entering the AC_PROG_CC part !

Sorry, this should have read:

... if CFLAGS *were* set before entering AC_PROG_CC ...

> I've explained that over and over again and I don't understand why you are being completely ignorant of the implications of your change.

One of the main purposes of AC_PROG_CC is to setup CFLAGS in case
they are not and your change defeats this purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:42:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Apr 2010 07:42:22 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272008542.1.0.188709611162.issue8325@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:56:12 2010
From: report at bugs.python.org (mike s)
Date: Fri, 23 Apr 2010 07:56:12 +0000
Subject: [issue8503] smtpd module does not allow
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>


New submission from mike s <suchanek at kovagroup.ca>:

The SMTPServer supplied by the smtpd library allows clients to send mail to any domain. This makes the server attractive to spammers, thinking they have found an open relay.

The patch below adds an "accept_domain" method to SMTPServer (documented below) which can be overridden by the user to compare the incoming domain against a list, etc, and return True or False (True=accept address, False=reject).

My apologies if this is the wrong place to submit this; I have not submitted a patch like this before and am just hoping to help! :)

Mike

--- smtpd.py.bak	2010-04-23 00:22:39.000000000 -0700
+++ smtpd.py	2010-04-23 00:51:22.000000000 -0700
@@ -241,6 +241,10 @@
         if not address:
             self.push('501 Syntax: RCPT TO: <address>')
             return
+	address_domain = address.split('@')[1]
+	if self._SMTPChannel__server.accept_domain(address_domain) is False:
+	    self.push('554 Relay access denied')
+	    return
         self.__rcpttos.append(address)
         print >> DEBUGSTREAM, 'recips:', self.__rcpttos
         self.push('250 Ok')
@@ -289,6 +293,15 @@
         print >> DEBUGSTREAM, 'Incoming connection from %s' % repr(addr)
         channel = SMTPChannel(self, conn, addr)
 
+    def accept_domain(self,domain):
+    	"""domain is a string like domain.com that specifes the domain of
+	an email address supplied by client's RCPT TO command.
+	
+	Override this method to determine whether SMTPServer should
+	accept mail for a given domain. This is handy for preventing
+	spammers from thinking you are running an open relay."""
+    	return True
+
     # API for "doing something useful with the message"
     def process_message(self, peer, mailfrom, rcpttos, data):
         """Override this abstract method to handle messages from the client.

----------
components: Library (Lib)
messages: 103993
nosy: mike.s
severity: normal
status: open
title: smtpd module does not allow
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/issue8503>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:59:29 2010
From: report at bugs.python.org (mike s)
Date: Fri, 23 Apr 2010 07:59:29 +0000
Subject: [issue8503] smtpd module does not allow domain filtering
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1272009569.79.0.22593552178.issue8503@psf.upfronthosting.co.za>


Changes by mike s <suchanek at kovagroup.ca>:


----------
title: smtpd module does not allow -> smtpd module does not allow domain filtering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Fri Apr 23 09:59:57 2010
From: report at bugs.python.org (mike s)
Date: Fri, 23 Apr 2010 07:59:57 +0000
Subject: [issue8503] smtpd SMTPServer does not allow domain filtering
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1272009597.3.0.764875175973.issue8503@psf.upfronthosting.co.za>


Changes by mike s <suchanek at kovagroup.ca>:


----------
title: smtpd module does not allow domain filtering -> smtpd SMTPServer does not allow domain filtering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Fri Apr 23 10:36:00 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Fri, 23 Apr 2010 08:36:00 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1272011760.23.0.406398774037.issue8451@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Committed as 80396.  Included a change to let openlog(3) pick the ident instead of using the static string "python".

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Fri Apr 23 11:30:40 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Fri, 23 Apr 2010 09:30:40 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1272015040.67.0.53075968409.issue8451@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Ported to python3 and committed as 80401.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Fri Apr 23 11:35:00 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Apr 2010 09:35:00 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272015300.78.0.213134986155.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, thanks for reviewing the patch. In the new patch, I added a skip
for OS X.

Buildbot testing looks good. In particular, one FreeBSD bot passes
test_curses now (the other one is hanging in multiprocessing).

For most bots nothing changes. The solaris bot has the same unrelated
failures as before. Ubuntu sparc previously did the same weird linking
(readline already linked with ncurses, but using -lncursesw) and now
uses ncurses throughout. Tests pass. Debian sparc did the same, tests
give the same failures as before ("getmouse returned ERR", almost certainly
unrelated.)


Roumen, I do not see a line in configure.in that tests for the
libraries that readline is linked against.

----------
Added file: http://bugs.python.org/file17050/issue7384-4-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 23 12:02:08 2010
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 23 Apr 2010 10:02:08 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272016928.26.0.552745272413.issue7384@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

I did some digging on my side, the fact you see ncurses referenced from readline is due to the build linking readline to libtermcap:

cc  -fstack-protector -shared -Wl,-x  -o libreadline.so.8 -Wl,-soname,libreadline.so.8  `lorder readline.So vi_mode.So funmap.So keymaps.So parens.So search.So rltty.So complete.So bind.So isearch.So display.So signals.So util.So kill.So undo.So macro.So input.So callback.So terminal.So text.So nls.So misc.So compat.So xmalloc.So history.So histexpand.So histfile.So histsearch.So shell.So mbutil.So tilde.So | tsort -q` -ltermcap

And libtermcap is:

% ll /usr/lib/libtermcap.so*
0 lrwxr-xr-x  1 root  wheel  -   13B 18 apr 08:29 /usr/lib/libtermcap.so@ -> libncurses.so


That configuration option you referenced, Stefan, is that --with-termlib (generate separate terminfo library)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 23 12:02:45 2010
From: report at bugs.python.org (Tim Lyons)
Date: Fri, 23 Apr 2010 10:02:45 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>


New submission from Tim Lyons <guy.linton at gmail.com>:

A database created under python 2.5 cannot be opened under python 2.6. It gives the error message "DB_RUNRECOVERY: Fatal error, run database recovery -- process-private: unable to find environment ", and a database created under python 2.6 cannot be opened under python 2.5 (see http://trac.macports.org/ticket/24310). (This in in Mac OS X: In Windows XP SP3, Python 2.6 can read a Python 2.5 bsddb data base.
but not the other way around. If you try, you will end up with a corrupt data base.)

python 2.6 bsddb is very much slower than python 2.5. Specifically, in Gramps, import of a 500 person xml file takes 12 sec with python25 and 9 mins 30 secs with python26. The slowness has been observed in Mac OS X (See http://trac.macports.org/ticket/23768) and in Windows (see http://www.gramps-project.org/bugs/view.php?id=3750).

I am not sure, but I think that both systems are using the same underlying database module db46, and that the difference may be in the different interface modules: "_bsddb.so" (on Mac OS X)

----------
components: Library (Lib)
messages: 103998
nosy: guy.linton
severity: normal
status: open
title: bsddb databases in python 2.6 are not compatible with python 2.5 and are slow in python 2.6
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 12:18:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Apr 2010 10:18:08 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272017888.72.0.936688025699.issue8504@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Jesus, any idea?

----------
assignee:  -> jcea
nosy: +jcea, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 12:22:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Apr 2010 10:22:31 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272018151.88.0.485408025072.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, readline uses only the termcap part of ncurses. I think that
--with-termlib is the correct option, see:

http://www.mail-archive.com/util-linux-ng at vger.kernel.org/msg00273.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 23 12:24:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Apr 2010 10:24:34 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1272007987.22.0.097076829486.issue8325@psf.upfronthosting.co.za>
Message-ID: <4BD1755A.6000708@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I don?t know what ?the tool I am using to commit the patch? is (I don?t
commit patches), but every program I tested does not use numbers with
usage/synopsis lines. Having the name of the program at the start of
each line prevents me from thinking it?s a continuation (and my pager,
most, colorizes it).

That said, I?m not sure it?s useful to include both usage lines. I?d
suggest advertising only the ?-m? way.

Some of the phrasing of the patch should be improved; if no native
speaker does it this week-end, I?ll propose something.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 12:31:14 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Apr 2010 10:31:14 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272018674.66.0.221446213317.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Actually this means that we should also look for -ltinfo in the ldd
check (A Redhat buildbot would be nice).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 23 13:08:07 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 23 Apr 2010 11:08:07 +0000
Subject: [issue8503] smtpd SMTPServer does not allow domain filtering
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1272020887.76.0.246348140481.issue8503@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is the right place, thanks for the patch!

Since this is a feature request it can only be added to 3.2 (and 2.8, if such a thing ever exists).

----------
nosy: +eric.smith
priority:  -> normal
stage:  -> unit test needed
type:  -> feature request
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Fri Apr 23 13:20:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 11:20:00 +0000
Subject: [issue8468] bz2: support surrogates in filename,
	and bytes/bytearray filename
In-Reply-To: <1271765569.25.0.596764444797.issue8468@psf.upfronthosting.co.za>
Message-ID: <1272021600.16.0.0990029893451.issue8468@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r80402 (py3k), r80403 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8468>
_______________________________________

From report at bugs.python.org  Fri Apr 23 13:37:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 11:37:43 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1272022663.29.0.267952818064.issue8477@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

key_file and cert_file are mandatory (see newPySSLObject()) and bytearray are now more accepted by PyUnicode_FSConverter() (see #8485). New version of the patch is simpler and shorter.

Support bytearray is a little bit to much complex for me (because of the GIL and bytearray lock), I prefer to leave 3.1 unchanged (I will not backport this patch).

----------
Added file: http://bugs.python.org/file17051/ssl_surrogates-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8477>
_______________________________________

From report at bugs.python.org  Fri Apr 23 13:38:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 11:38:00 +0000
Subject: [issue8242] Improve support of PEP 383 (surrogates) in Python3:
	meta-issue
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1272022680.79.0.709435312856.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +Don't accept bytearray as filenames, or simplify the API

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Fri Apr 23 13:38:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 11:38:07 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1272022687.78.0.62697051322.issue8477@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17017/ssl_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8477>
_______________________________________

From report at bugs.python.org  Fri Apr 23 14:05:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 12:05:13 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1272024313.1.0.0265287645299.issue8124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r80404 (py3k), r80405 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Fri Apr 23 14:26:02 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Apr 2010 12:26:02 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272025562.52.0.243819029256.issue8504@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The database compatibility is dictated by the underlying Berkeley DB library used. Reporter, please do this: (asuming you are using "bsddb" lib in the standard lib, not external project "pybsddb")

1. Open a python2.5 shell.

2. "import bsddb"

3. "print bsddb.__version__, bsddb.db.version()"

4. Post the numbers.

5. Repeat under python2.6.

In my machine, I get:

python2.5: 4.4.5.3 (4, 5, 20)
python2.6: 4.7.3 (4, 7, 25)

So under python2.5 I would be using Berkeley DB 4.5, and under python2.6 I am using Berkeley DB 4.7.

Berkeley DB has a defined procedure to upgrade databases. This is specially important if you are using a transactional datastore. BEWARE: There is *NO* downgrade path.

http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_reference/am_upgrade.html

Most of the time, the database format doesn't change from version to version, but the environment do (specially the log format). Each Berkeley DB database release documentation includes a very detailed "upgrading" section. For instance:

http://www.oracle.com/technology/documentation/berkeley-db/db/installation/upgrade_11gr2_toc.html

Anyway the details are the following:

1. A database created with a X Berkeley DB can not be used in a Y version, if Y<X.

2. A database created with a X Berkeley DB can be used in a Y version, if Y>X, if you upgrade the environment/databases first to the new version.

The documented upgrade procedure is:

http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_reference/upgrade_process.html


If you try to use an old format with a new library without updating, you should get a CLEAR error message:

"""
Python 2.5.2 (r252:60911, Mar 14 2008, 19:21:46) 
[GCC 4.2.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> dbenv=bsddb.db.DBEnv()
>>> dbenv.open(".", bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE)
>>> db=bsddb.db.DB(dbenv)
>>> db.open("file.db",flags=bsddb.db.DB_CREATE, dbtype=bsddb.db.DB_HASH)
>>> db.close()
>>> dbenv.close()
>>> 
Python 2.6.5 (r265:79063, Mar 22 2010, 12:17:26) 
[GCC 4.4.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> dbenv=bsddb.db.DBEnv()
>>> dbenv.open(".", bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
bsddb.db.DBError: (-30971, "DB_VERSION_MISMATCH: Database environment version mismatch -- Program version 4.7 doesn't match environment version 4.5")
"""

The error is pretty obvious.

If you go the other way:

"""
Python 2.6.5 (r265:79063, Mar 22 2010, 12:17:26) 
[GCC 4.4.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> 
>>> dbenv=bsddb.db.DBEnv()
>>> dbenv.open(".", bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE)
>>> db=bsddb.db.DB(dbenv)
>>> db.open("file.db",flags=bsddb.db.DB_CREATE, dbtype=bsddb.db.DB_HASH)
>>> db.close()
>>> dbenv.close()
>>> 
Python 2.5.2 (r252:60911, Mar 14 2008, 19:21:46) 
[GCC 4.2.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> dbenv=bsddb.db.DBEnv()
>>> dbenv.open(".", bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
bsddb.db.DBError: (-30972, "DB_VERSION_MISMATCH: Database environment version mismatch -- Program version 4.5 doesn't match environment version 4.7")
"""

So, no database corruption, but a clear error message. I guess Gram is reporting database corruption because it can't open the database for some reason, not that the DB is actually corrupted.

In your case, anyway, you are saying that you are using the same Berkeley DB both in python2.5 and 2.6, so all this explanation is not actually related. Please CONFIRM that.

If you are using actually the same BDB version, the next step is to try to open the DB manually (with a short python script like the posted one).

Remember, ALSO, that if you are using a BDB previous to 4.7, you can not simply copy an environment between different endianess machines. For instance, moving from PowerPC to x86. I think that was solved in BDB 4.7, IIRC. Or maybe 4.8.

Look at http://forums.oracle.com/forums/thread.jspa?messageID=3725053

About the speed, if you are using the same BerkeleyDB release, the speed should be the same. So the first step would be to actually know if you are using the same BDB version.

I guess the importing is doing a new transaction per imported record, flushing them to disk. Flushing is an expensive and slow operation. In a regular HD, that would limit the speed to 30-120 transactions per second, maximum (depending of your filesystem). The dependency of the filesystem could explain the difference between Linux and Windows.

The an approach would be to enclose ALL the imported records in a single transaction. If the imported is huge you can run out of BDB resources, so enclose every 1000 register in a transaction, for instance. Or increase BDB resource pool (shared regions).

Another option (the right approach :) I would do would be to insert each record in its own transaction, but configuring those transactions as "not flushing", to keep them in memory as long as possible. When the last transaction is committed, do a final huge flush/checkpoint.

Berkeley DB is amazing, but mastering it is difficult.

Anyway, confirm you are using the same BDB in python2.5 and 2.6, that you are not migrating from PowerPC to x86 and that you are not flushing transactions wildy (under Linux, use "dtrace" and lookout for "sync", "fsync", "datasync", or other related syscalls).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 14:31:15 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 23 Apr 2010 12:31:15 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>
Message-ID: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Lines such as the following are removed by fix_future.py in 2to3

from __future__ import absolute_import, unicode_literals

I think this is unnecessary and I have a case where it causes problems.  It's unnecessary because this import is essentially a no-op in Python 3, so it does no harm, and serves no actual useful purpose to remove.  It causes harm because of a common idiom in doctest setups:

def setup(testobj):
    """Test setup."""
    # Make sure future statements in our doctests match the Python code.
    testobj.globs['absolute_import'] = absolute_import
    testobj.globs['unicode_literals'] = unicode_literals

fix_future.py removes the import so these cause NameErrors.  Sure, I can wrap them in try/excepts, but still what's the point of fix_future?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 104008
nosy: barry
severity: normal
status: open
title: 2to3 fix_future.py removes __future__ imports, but should it?
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Fri Apr 23 14:38:04 2010
From: report at bugs.python.org (Erik Schweller)
Date: Fri, 23 Apr 2010 12:38:04 +0000
Subject: [issue8506] SimpleXMLRPCServer Socket not closed after shutdown call
In-Reply-To: <1272026284.3.0.0989904198918.issue8506@psf.upfronthosting.co.za>
Message-ID: <1272026284.3.0.0989904198918.issue8506@psf.upfronthosting.co.za>


New submission from Erik Schweller <othererik at gmail.com>:

Calling shutdown on a SimpleXMLRPCServer will stop the server but does not close the socket, meaning new connections to the same address will fail. 

Example:

  srv = SimpleXMLRPCServer((ip, port),
                                      logRequests=False, allow_none=True)
  srv.serve_forever(poll_interval=2)


srv.shutdown() is made available to the registered class instance.


The current workaround is to delete the socket (or call close() on the socket) after the server is shutdown, (i.e., "del srv.socket") but it seems this should be handled when the server is shutdown.

----------
components: Library (Lib)
messages: 104009
nosy: othererik
severity: normal
status: open
title: SimpleXMLRPCServer Socket not closed after shutdown call
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8506>
_______________________________________

From report at bugs.python.org  Fri Apr 23 14:42:18 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Apr 2010 12:42:18 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1272026538.95.0.337141210288.issue5639@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Fri Apr 23 15:09:28 2010
From: report at bugs.python.org (Peter Landgren)
Date: Fri, 23 Apr 2010 13:09:28 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272028168.01.0.9290520406.issue8504@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

I could add what I have found using bsddb in Python 2.5 and 2.6 under Windows XP SP3. In my installation:
Python 2.5.4 bsddb 4.4.5.3
Python 2.6.4 bsddb 4.7.3
What I did: In Gramps imported an XML backup file to a empty bsddb database. It took about 1 hour with 2.6.4 and 2 minutes with 2.5.4!
I have also instelled bsddb3:
Python 2.6.4 bsddb3 4.8.4
and with the same import I'm back to 2 minutes.
I have pstat logs which I could provide.

----------
nosy: +PeterL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 15:10:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Apr 2010 13:10:16 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1272028216.26.0.620075117907.issue8477@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> key_file and cert_file are mandatory

No, they are not. Not for a client connection, at least.
Also, please add at least a simple test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8477>
_______________________________________

From report at bugs.python.org  Fri Apr 23 15:33:08 2010
From: report at bugs.python.org (Robert Escriva)
Date: Fri, 23 Apr 2010 13:33:08 +0000
Subject: [issue8507] abc.abstractproperty does not copy docstring
In-Reply-To: <1272029588.75.0.820614439308.issue8507@psf.upfronthosting.co.za>
Message-ID: <1272029588.75.0.820614439308.issue8507@psf.upfronthosting.co.za>


New submission from Robert Escriva <bugs.python at mail.robescriva.com>:

Attached file shows interpreter session where the bug manifests.

It was my expectation that abc.abstractproperty would copy the docstring just like property.  Instead, the docstring is the one for abc.abstractproperty itself.

----------
components: Library (Lib)
files: python.abc.abstractproperty.bug
messages: 104012
nosy: rescrv
severity: normal
status: open
title: abc.abstractproperty does not copy docstring
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17052/python.abc.abstractproperty.bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8507>
_______________________________________

From report at bugs.python.org  Fri Apr 23 15:35:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Apr 2010 13:35:20 +0000
Subject: [issue8507] abc.abstractproperty does not copy docstring
In-Reply-To: <1272029588.75.0.820614439308.issue8507@psf.upfronthosting.co.za>
Message-ID: <1272029720.95.0.247621459264.issue8507@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8507>
_______________________________________

From report at bugs.python.org  Fri Apr 23 16:04:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 14:04:55 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1272031495.67.0.603954578934.issue1563@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file11018/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Fri Apr 23 16:07:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 14:07:38 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1272031658.64.0.848387068051.issue1563@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since no doc only patch has been proposed and there is some disagreement as to whether it is needed anyway, I'm closing this per msg88559.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Fri Apr 23 16:15:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 14:15:26 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1272032126.86.0.686422842246.issue7806@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hearing no further argument to the contrary, I'm closing this as invalid.

----------
resolution:  -> invalid
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Fri Apr 23 16:48:06 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 23 Apr 2010 14:48:06 +0000
Subject: [issue8508] 2to3 fixer for gettext's .ugettext
In-Reply-To: <1272034086.61.0.0547716106043.issue8508@psf.upfronthosting.co.za>
Message-ID: <1272034086.61.0.0547716106043.issue8508@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

gettext module in Python 3 does not have a .ugettext method because everything's already unicodes.  Here's a fixer for that.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_ugettext.py
messages: 104015
nosy: barry
severity: normal
status: open
title: 2to3 fixer for gettext's .ugettext
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17053/fix_ugettext.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8508>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:02:32 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Apr 2010 15:02:32 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272034952.82.0.616980813984.issue8504@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I need to know the Berkeley DB version you are using in python 2.5, 2.6, both with bsddb and pybsddb (bsddb3).

Also, I would need a testcase I can try without installing Gram myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:16:47 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 23 Apr 2010 15:16:47 +0000
Subject: [issue8509] fix autoconf quoting in help strings and code snippets
In-Reply-To: <1272035806.11.0.986586497024.issue8509@psf.upfronthosting.co.za>
Message-ID: <1272035806.11.0.986586497024.issue8509@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

the attached patch adds quoting to help strings and code snippets, following the autoconf quotation rule of thumb "One pair of quotes per pair of parentheses".

checked that the generated files are identical.

----------
components: Build
files: configure.in.diff
keywords: needs review, patch
messages: 104017
nosy: doko
severity: normal
status: open
title: fix autoconf quoting in help strings and code snippets
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17054/configure.in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8509>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:26:20 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 23 Apr 2010 15:26:20 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

update to autoconf2.65

----------
components: Build
files: autoconf2.65.diff
keywords: needs review, patch
messages: 104018
nosy: doko
severity: normal
status: open
title: update to autoconf2.65
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17055/autoconf2.65.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:28:49 2010
From: report at bugs.python.org (Peter Landgren)
Date: Fri, 23 Apr 2010 15:28:49 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272036529.33.0.38606087369.issue8504@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

Requested data on my Windows box:
Python 2.5  bsddb 4.4.5.3   4.4.20
Python 2.6  bsddb 4.7.3     4.7.25
Python 2.6  bsddb 4.8.4     4.8.26

OK?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:31:20 2010
From: report at bugs.python.org (Peter Landgren)
Date: Fri, 23 Apr 2010 15:31:20 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272036680.42.0.344103113543.issue8504@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

Maybe I should add that there is no speed degradation between 2.5 and 2.5 when doing the same thing in Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:33:31 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 23 Apr 2010 15:33:31 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272036811.33.0.260390824562.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

see http://mail.python.org/pipermail/python-dev/2010-April/099639.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:38:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 15:38:29 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272037109.95.0.94532456567.issue8325@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The numbers should definitely not be there.  I favor just documenting the -m version, and you'll see why in the attached patch.  I've incorporated Anatoly's improvement to the argument description and the option updates, and made some additional improvements.  I've also more extensively rewritten the -s docs, but Florent and I are still discussing where the pynexttest file should really go (currently -s is broken on trunk).  Or maybe we should just get rid of -s.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file17056/regrtest-help.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:38:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 15:38:58 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272037138.54.0.653597415663.issue8325@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:41:28 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Apr 2010 15:41:28 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272037288.09.0.258803880806.issue8504@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Peter, and which Berkeley DB versions are used in Linux?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:42:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 15:42:07 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272037327.91.0.122849927059.issue8325@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:43:59 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Fri, 23 Apr 2010 15:43:59 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272037439.75.0.516202037995.issue8493@psf.upfronthosting.co.za>


Matthew Cowles <mdcowles at users.sourceforge.net> added the comment:

> if you get this type of error, it's probably because you're using non-
> blocking sockets

That's what I thought at first too. But the user's sockets were set to blocking.

> spinning around the send call trying to resend the data isn't going to 
> improve things, you should probably wait a little before retrying

The user switched to using send() and adding a short delay before retrying the send solved the problem.

In fact, I think it's a little silly that OS X raises the error rather than just saying that 0 bytes were sent (which is what I suppose that other OSes do).

But I think it's also not ideal that Python's socket.sendall() can't be used with confidence under OS X because it can fail under pretty normal circumstances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Fri Apr 23 17:57:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 15:57:18 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272038238.17.0.945101392359.issue8510@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Fri Apr 23 18:00:42 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Apr 2010 16:00:42 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272038442.74.0.734364055824.issue8510@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Fri Apr 23 18:12:42 2010
From: report at bugs.python.org (Peter Landgren)
Date: Fri, 23 Apr 2010 16:12:42 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272039162.79.0.963922611802.issue8504@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

In Linux it is:
4.4.5.3 (4, 6, 21)

You asked for a test case. I'm not sure how I can provide one without you having Gramps installed to test it.
Do you mean the whole database environment?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 18:15:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Apr 2010 16:15:16 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1272039316.78.0.287133138644.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The buildbots are generally happy with the change. However, on OpenBSD
test_itimer_prof fails seemingly unrelated to machine load.

I'm not so familiar with the signal module, but how can the signal
handlers in the tests be guaranteed to work? For example, if you
set a variable inside a signal handler (self.hndl_called=True), it
should be a sig_atomic_t. If you call a function, it should be listed
as signal-safe ( 
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html ),
but setitimer is not.


I say this because there might be further assumptions in the tests
that could generate hard to track down failures in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:03:08 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 23 Apr 2010 17:03:08 +0000
Subject: [issue4835] SIZEOF_SOCKET_T not defined
In-Reply-To: <18784.64475.338807.986695@montanaro.dyndns.org>
Message-ID: <1272042188.81.0.700096782536.issue4835@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm seeing this with gcc-4.4.3 with -Wall -Werror, leading to fatal errors trying to build an extension module against python 3.1

The references to SIZEOF_SOCKET_T within longobject.h appear to be just in the py3k branch, not trunk, and were added in r59009.  I'm marking this issue as python3, and as both "Interpreter Core" and "Extension Modules".

There didn't seem to be a natural place to put these types, so I'm attaching a patch against the py3k branch which adds a new public/installed header file: Include/socketrepr.h, specifically to contain them.   How does this look?

----------
components: +Extension Modules, Interpreter Core
keywords: +patch
nosy: +dmalcolm
stage:  -> patch review
type:  -> compile error
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17057/add-socketrepr.h-to-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4835>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:03:26 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Fri, 23 Apr 2010 17:03:26 +0000
Subject: [issue8511] Small mistake in tutorial web page
In-Reply-To: <1272042206.62.0.681043010082.issue8511@psf.upfronthosting.co.za>
Message-ID: <1272042206.62.0.681043010082.issue8511@psf.upfronthosting.co.za>


New submission from Matthew Cowles <mdcowles at users.sourceforge.net>:

[Originally from a post to the python-help list]

Over at:

http://docs.python.org/py3k/tutorial/datastructures.html#sets

it says:

>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
>>> fruit = set(basket)               # create a set without duplicates

I suspect that the first line should begin:

>>> basket =

----------
assignee: georg.brandl
components: Documentation
messages: 104028
nosy: georg.brandl, mdcowles
severity: normal
status: open
title: Small mistake in tutorial web page
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8511>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:08:26 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 23 Apr 2010 17:08:26 +0000
Subject: [issue4835] SIZEOF_SOCKET_T not defined
In-Reply-To: <18784.64475.338807.986695@montanaro.dyndns.org>
Message-ID: <1272042506.59.0.909892616289.issue4835@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> I'm seeing this with gcc-4.4.3 with -Wall -Werror, leading to fatal errors
> trying to build an extension module against python 3.1

Specifically, with gcc, I'm seeing this warning (trying to port SELinux Python support to Python3), which, with -Werror becomes fatal:
In file included from /usr/include/python3.1/Python.h:72,
                 from audit2why.c:1:
/usr/include/python3.1/longobject.h:36:5: error: "SIZEOF_SOCKET_T" is not defined
cc1: warnings being treated as errors

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4835>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:08:57 2010
From: report at bugs.python.org (Tim Lyons)
Date: Fri, 23 Apr 2010 17:08:57 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272042537.87.0.391195656188.issue8504@psf.upfronthosting.co.za>


Tim Lyons <guy.linton at gmail.com> added the comment:

On Mac OS X,I get

tim$ python
Python 2.5.5 (r255:77872, Mar 21 2010, 22:08:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> print bsddb.__version__, bsddb.db.version()
4.4.5.3 (4, 6, 21)
>>>
tim$ /opt/local/bin/python2.6
Python 2.6.5 (r265:79063, Apr  8 2010, 22:42:38)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> print bsddb.__version__, bsddb.db.version()
4.7.3 (4, 7, 25)

So the database versions are:
python 2.5 bsddb 4.4.5.3 (4, 6, 21)
python 2.6 bsddb 4.7.3 (4, 7, 25)

On python 2.5:
Python 2.5.5 (r255:77872, Mar 21 2010, 22:08:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> dbenv=bsddb.db.DBEnv()
>>> dbenv.open(".", bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE)
>>> db1=bsddb.db.DB(dbenv)
>>> db1.open("note.db",flags=bsddb.db.DB_RDONLY,dbtype=bsddb.db.DB_UNKNOWN)
>>> 

and on python 2.6:
Python 2.6.5 (r265:79063, Apr  8 2010, 22:42:38) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> dbenv=bsddb.db.DBEnv()
>>> dbenv.open(".", bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
bsddb.db.DBError: (-30971, "DB_VERSION_MISMATCH: Database environment version mismatch -- Program version 4.7 doesn't match environment version 4.6")
>>> 

The incompatibility between the two environments is therefore resolved as being due to different versions of bsddb. Thanks for all your help in determining this.

The database slowdown still remains to be resolved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:32:33 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 23 Apr 2010 17:32:33 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1272043953.96.0.513762953946.issue1128@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

So what happens if the original file name is something like "foo~1.txt"?  Couldn't there be a name collision?

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1128>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:41:56 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Apr 2010 17:41:56 +0000
Subject: [issue8511] Small mistake in tutorial web page
In-Reply-To: <1272042206.62.0.681043010082.issue8511@psf.upfronthosting.co.za>
Message-ID: <1272044516.34.0.618097756927.issue8511@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Duplicate of #4570.

----------
nosy: +ezio.melotti, rhettinger
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8511>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:42:14 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Apr 2010 17:42:14 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1272044534.46.0.436589835799.issue4570@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +mdcowles
priority:  -> normal
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4570>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:47:58 2010
From: report at bugs.python.org (Peter Landgren)
Date: Fri, 23 Apr 2010 17:47:58 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272044878.61.0.363561753906.issue8504@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

To make it 100% clear:

The versions are almost the same for Linux and Windows.
           Python 2.5            Python 2.6
Windows  4.4.5.3 (4, 6, 20)    4.7.3 (4.7.25)
Linux    4.4.5.3 (4, 6, 21)    4.7.3 (4.7.25)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 19:57:24 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 23 Apr 2010 17:57:24 +0000
Subject: [issue7639] bdist_msi fails on files with long names
In-Reply-To: <1262718207.72.0.84290104112.issue7639@psf.upfronthosting.co.za>
Message-ID: <1272045444.39.0.796761637271.issue7639@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

This looks a lot like bug 1128, too.  I think the patch there would also fix this one.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7639>
_______________________________________

From report at bugs.python.org  Fri Apr 23 20:05:26 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 23 Apr 2010 18:05:26 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1272045926.36.0.861873705178.issue1128@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Here's how Microsoft does it:  http://support.microsoft.com/kb/142982/en-us

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1128>
_______________________________________

From report at bugs.python.org  Fri Apr 23 20:36:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Apr 2010 18:36:53 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1272047813.43.0.687625313869.issue7319@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Fri Apr 23 20:37:34 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Apr 2010 18:37:34 +0000
Subject: [issue7997] http://www.python.org/dev/faq/ doesn't seem to explain
	how to regenerate "configure"
In-Reply-To: <1266882841.0.0.727782074241.issue7997@psf.upfronthosting.co.za>
Message-ID: <1272047854.15.0.152312937351.issue7997@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Fri Apr 23 20:44:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 18:44:51 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1272048291.47.0.245914219019.issue8451@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Assuming that it is OK for this to be in 2.7 beta2 (it smells almost like a feature, but I'm certainly willing to let it pass as a bugfix myself), the 2.7 doc change in the commit contains a typo (it says versionchanged 3.2 instead of versionchanged 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Fri Apr 23 20:46:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 18:46:01 +0000
Subject: [issue8451] syslog.syslog('msg') logs message with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1272048361.45.0.363270555558.issue8451@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, and you forgot about your note to yourself to update the argument syntax for the 3.2 commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8451>
_______________________________________

From report at bugs.python.org  Fri Apr 23 20:59:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Apr 2010 18:59:08 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272049148.67.0.677106420375.issue8325@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

?ric: svn merge

R.David Murray: "The numbers should definitely not be there." is not an argument.  `python regrtest.py` should also be a supported way to run regression suite.  With only -m favor documented somebody can quickly forget about it.  I use Mercurial clones for development, I also can't compile Windows binaries (no money, space and time for VS), so it is important for me to be able to run regrtest.py manually from the same directory I am hacking tests and global interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 21:00:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 23 Apr 2010 19:00:37 +0000
Subject: [issue8503] smtpd SMTPServer does not allow domain filtering
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1272049237.53.0.0857484289657.issue8503@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Idea: wouldn't it be better to provide a more powerful "accept_mail" method instead of "accept_domain?

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Fri Apr 23 21:05:14 2010
From: report at bugs.python.org (mike s)
Date: Fri, 23 Apr 2010 19:05:14 +0000
Subject: [issue8503] smtpd SMTPServer does not allow domain filtering
In-Reply-To: <1272049237.53.0.0857484289657.issue8503@psf.upfronthosting.co.za>
Message-ID: <3FA1AB81-712A-48D7-BB9D-F4E81C2D41ED@kovagroup.ca>


mike s <suchanek at kovagroup.ca> added the comment:

I don't think that is a suitable solution for this problem, because the expected SMTP behavior is to reject an unsuitable RCPT TO directly after it is proposed by the client.

However, I think it would be a great idea to have such a method being called after the end of the DATA segment (immediately before the message is queued - or not).

Mike

On 2010-04-23, at 12:00 PM, Giampaolo Rodola' wrote:

> 
> Giampaolo Rodola' <g.rodola at gmail.com> added the comment:
> 
> Idea: wouldn't it be better to provide a more powerful "accept_mail" method instead of "accept_domain?
> 
> ----------
> nosy: +giampaolo.rodola
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8503>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8503>
_______________________________________

From report at bugs.python.org  Fri Apr 23 21:15:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Apr 2010 19:15:46 +0000
Subject: [issue1379416] email.Header encode() unicode P2.6
Message-ID: <1272050146.11.0.5357663089.issue1379416@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1379416>
_______________________________________

From report at bugs.python.org  Fri Apr 23 21:44:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Apr 2010 19:44:49 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272051889.92.0.134242159383.issue8325@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are correct, it wasn't an argument.  I've never seen numbered alternatives anywhere *except* the svn merge help (which I've never looked at before, since I/we don't use it for python development).  And I don't like them.  (svn merge uses them to cross reference the explanatory comments that follow, but I still don't like them and I think the svnmerge help would read better without them.)

I see your point about the alternate form, though you could still use -m by making sure your modified Lib dir was in PYTHONPATH, or run it with the Lib dir as the CWD.  Without doing that I don't think you'd be testing your modified Lib directory anyway (though you would be running the modified test files).  I'm not sure about that, though, I haven't run enough experiments :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:02:46 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Apr 2010 20:02:46 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272052966.74.0.346691291476.issue8325@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

To reach a consensus we can drop line numbering, but I still would like to see two variants of invocation. Sometimes I indeed copy library from trunk/ to main Lib/ for testing, but there is no better way to work with the test suite inside version control and outside of this main library on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:13:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Apr 2010 20:13:22 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272053602.86.0.761795202181.issue8504@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Peter, please stay out of this bug report unless you are certain that you have the very problem that the OP reported, namely that a database created by Python 2.5 cannot be imported in 2.6. I'm taking the performance issues out of this bug report; anybody interested in them should create a separate bug report.

One bug per bug report, please.

----------
title: bsddb databases in python 2.6 are not compatible with python 2.5 and are slow in python 2.6 -> bsddb databases in python 2.6 are not compatible with python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:21:57 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 23 Apr 2010 20:21:57 +0000
Subject: [issue6768] asyncore file_wrapper leaking file descriptors?
In-Reply-To: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
Message-ID: <1272054117.57.0.291382478089.issue6768@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm not sure how to reproduce this issue but I doubt calling close() from __del__ would solve the problem, neither would be a good idea as close() might end up being called more than once, which is not desirable.

Try to paste the code you're using: the problem might be that your application is not calling close() for some reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6768>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:22:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 20:22:36 +0000
Subject: [issue8467] subprocess: surrogates of the error message (Python
	implementation on non-Windows)
In-Reply-To: <1271764975.75.0.223846589239.issue8467@psf.upfronthosting.co.za>
Message-ID: <1272054156.13.0.542160669392.issue8467@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited in py3k (r80413), blocked in 3.1 (r80414).

Python 3.1 uses pickle to encode the traceback and pickle supports surrogates (see #8383).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8467>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:23:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Apr 2010 20:23:50 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272054230.33.0.14397308616.issue8504@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I just noticed that Tim reports in msg104030 that the original problem is resolved. So I'm closing this report as fixed.

If you create a new one on the performance issue, please make sure to include a repeatable test case, with instructions on how to repeat it. 

Notice that Jesus suggests that the performance difference may be caused by the difference in bsddb version, in which case it wouldn't be a Python bug at all. I find that theory very plausible. Most likely, the bug would be in Gramps, for using bsddb incorrectly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:24:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Apr 2010 20:24:06 +0000
Subject: [issue8504] bsddb databases in python 2.6 are not compatible with
	python 2.5
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272054246.95.0.496662405444.issue8504@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8504>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:25:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Apr 2010 20:25:23 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272054323.88.0.574748030217.issue8510@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think Python 2.7 should upgrade to a newer autoconf version at this point. For 3.2, we could try it out.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:35:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 20:35:39 +0000
Subject: [issue8495] test_gdb: use utf8+surrogateescape charset?
In-Reply-To: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>
Message-ID: <1272054939.74.0.764561634711.issue8495@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@loewis: I think the "replace" handler would be more appropriate here.

Right. Fixed by r80416 (py3k, blocked in 3.1: r80417).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8495>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:37:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 20:37:00 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1272055020.87.0.442740535601.issue8390@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8390>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:39:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Apr 2010 20:39:20 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>
Message-ID: <1272055160.25.0.429581469619.issue8505@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You can just turn off fix_future with -x future.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:40:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Apr 2010 20:40:50 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1272055250.97.0.977882651579.issue1128@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

MSI short names must be 8.3 names. Microsoft has them in MSI in case the MSI file gets installed on an 8.3 system, or in case 8.3 applications want to access files and want to be sure they access the right one. So the actual numbering is completely irrelevant (since we only support systems with long file name support, and will always use long names to access the files). They still need to be in the 8.3 space, though, else Installer might be unhappy. So having two dots in the short name is incorrect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1128>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:48:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 23 Apr 2010 20:48:37 +0000
Subject: [issue751758] ftplib.retrbinary fails when called from retrlines
	callback
Message-ID: <1272055717.53.0.363763598791.issue751758@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Closing this out as rejected.

----------
resolution:  -> rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue751758>
_______________________________________

From report at bugs.python.org  Fri Apr 23 22:53:43 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Apr 2010 20:53:43 +0000
Subject: [issue8508] 2to3 fixer for gettext's .ugettext
In-Reply-To: <1272034086.61.0.0547716106043.issue8508@psf.upfronthosting.co.za>
Message-ID: <1272056023.1.0.069470741632.issue8508@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You should follow the model of fix_getcwdu, which handles more cases.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8508>
_______________________________________

From report at bugs.python.org  Fri Apr 23 23:00:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 21:00:33 +0000
Subject: [issue8242] Improve support of PEP 383 (surrogates) in Python3:
	meta-issue
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1272056433.51.0.0957255620741.issue8242@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +Check that _PyUnicode_AsString() result is not NULL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Fri Apr 23 23:13:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Apr 2010 21:13:54 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1272057234.74.0.632598975093.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've backported the shutdown fixes to 2.6 (r80419) and 3.1 (r80420). Thanks again everyone.

----------
status: pending -> closed
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Apr 23 23:40:31 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 23 Apr 2010 21:40:31 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1272015300.78.0.213134986155.issue7384@psf.upfronthosting.co.za>
Message-ID: <4BD213C6.8020209@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

> Roumen, I do not see a line in configure.in that tests for the
> libraries that readline is linked against.

The test in configure is how to link application to readline libs.

Platforms that support linking of shared libraries with unresolved 
symbols cannot link readline to termcap compatible library if they offer 
more then one. I think that this is the bug in package build on those 
system as this limit applications to use other termcap libraries.

Not all linux link readline to  termcap compatible library:
- SuSe (checked on 11.0) linked to ncurses :(
- Fedora (verified v 12) and Slackware - not linked . So no issue 
(before) on those platforms as application can link to any termcap 
compatible library and python will select ncursesw. On those platforms I 
expect Stefan patch to return empty string and python to fail to build 
readline module.

As configure detect how to link readline we could uncomment 
READLINE_LIBS and to add as makefile macroand to use by setup.py. If 
READLINE_LIBS contain only -lreadline => on this platform readline is 
already linked to termcap compatible library.

Also detection of dependent libraries that use ldd is limited to 
platforms that has this command, i.e. is not portable.
If distutils support a method that return dependency libraries we could 
use. (

I'm not familiar with python curses module to propose a patch .
Is possible to to run sample program to detect readline curses library ?

Or may be to try to link sample "int main() { readline(); }" and to ask 
compiler/linker to warn for duplicate symbols. Something like :
$ gcc -Wl,--warn-common test-readline.c -lreadline -lncursesw  -lncursesw
$ gcc -Wl,--warn-common test-readline.c -lreadline -ltermcap -lncurses
.../libncurses.so: warning: common of `ospeed' overridden by larger common
.../libtermcap.so: warning: larger common is here
$ gcc -Wl,--warn-common test-readline.c -lreadline -ltermcap -lncursesw
..../libncursesw.so: warning: common of `ospeed' overridden by larger common
..../../libtermcap.so: warning: larger common is here
FIXME with more portable and more correct command.

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri Apr 23 23:45:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 21:45:08 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1272059108.71.0.401526306155.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r80421 (py3k), blocked in 3.1 (80422). The commit fixes also os.getenv() to support bytes environment name.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Fri Apr 23 23:51:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Apr 2010 21:51:17 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1272059477.05.0.595303079287.issue5103@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch fixing test_poplib failures.

----------
Added file: http://bugs.python.org/file17058/ssltimeout2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Fri Apr 23 23:52:36 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 23 Apr 2010 21:52:36 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1272018674.66.0.221446213317.issue7384@psf.upfronthosting.co.za>
Message-ID: <4BD216A0.2060800@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Stefan Krah wrote:
>
> Stefan Krah<stefan-usenet at bytereef.org>  added the comment:
>
> Actually this means that we should also look for -ltinfo in the ldd
> check (A Redhat buildbot would be nice).

Or may be this mean that in configure to add test with -ltinfo and if 
readline link succeed then is save to link python curses module with 
first curses library found.

ldd - what about platforms without GNU libc ?

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 24 00:34:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 22:34:15 +0000
Subject: [issue8512] os.execvpe()
Message-ID: <1272062053.09.0.0607896315436.issue8512@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: Library (Lib)
nosy: haypo
severity: normal
status: open
title: os.execvpe()
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8512>
_______________________________________

From report at bugs.python.org  Sat Apr 24 00:40:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 22:40:51 +0000
Subject: [issue8512] os.execv*e(): fix formatting of the environment variables
In-Reply-To: <1272062451.81.0.836509652271.issue8512@psf.upfronthosting.co.za>
Message-ID: <1272062451.81.0.836509652271.issue8512@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

os.execve() and os.execvpe() of Python 3.1 eats some bytes of the environment variables: see msg103459. The problem is that it counts *characters* to allocate the *byte* string buffer.

Attached patch fixes this issue. It contains a test which may stay specific to Python 3.1 because Python 3.2 have its own test for non-ASCII environment variables: test_undecodeable_env in test_subprocess (introduced by #8391).

See also #8391.

----------
keywords: +patch
nosy: +Arfrever
title: os.execvpe() -> os.execv*e(): fix formatting of the environment variables
Added file: http://bugs.python.org/file17059/os_execve_env.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8512>
_______________________________________

From report at bugs.python.org  Sat Apr 24 00:42:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 22:42:07 +0000
Subject: [issue8513] subprocess: support bytes program name
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

While fixing #8391, I realized that subprocess doesn't support bytes program name if it's not an absolute path:
-------
$ ./python
>>> import subprocess
>>> subprocess.call([b'echo'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 449, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 681, in __init__
    restore_signals, start_new_session)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1116, in _execute_child
    for exe in executable_list)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1115, in <genexpr>
    executable_list = tuple(fs_encode(exe)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1114, in <genexpr>
    for dir in path_list)
  File "/home/SHARE/SVN/py3k/Lib/posixpath.py", line 75, in join
    if b.startswith(sep):
TypeError: expected an object with the buffer interface
[62826 refs]
-------

I'm working on a patch.

----------
components: Library (Lib), Unicode
messages: 104059
nosy: haypo
severity: normal
status: open
title: subprocess: support bytes program name
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat Apr 24 00:42:56 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 23 Apr 2010 22:42:56 +0000
Subject: [issue8513] subprocess: support bytes program name
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272062576.74.0.696944750354.issue8513@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:12:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Apr 2010 23:12:35 +0000
Subject: [issue7943] Memory leak due to circular references in ssl.SSLSocket
In-Reply-To: <1266341912.31.0.218071173939.issue7943@psf.upfronthosting.co.za>
Message-ID: <1272064355.34.0.400010114493.issue7943@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed with test in r80423 (trunk) and r80425 (2.6).
Also ported the test to py3k/3.1. Thanks!

----------
nosy: +pitrou
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7943>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:16:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 23:16:03 +0000
Subject: [issue8513] subprocess: support bytes program name
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272064563.78.0.784897606216.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch (draft version) fixes this issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file17060/subprocess_bytes_program.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:37:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Apr 2010 23:37:41 +0000
Subject: [issue5238] ssl makefile never closes socket
In-Reply-To: <1234485278.29.0.554185864263.issue5238@psf.upfronthosting.co.za>
Message-ID: <1272065861.9.0.127624351649.issue5238@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The makefile issue is fixed in r80428 (trunk) and r80431 (2.6). Also ported the additional test to py3k and 3.1.

The other issue pointed out by Marcin Bachry doesn't seem fixable without breaking backwards compatibility, for applications which close() the SSL object but expect the underlying socket to still be usable for clear-text communications. Therefore I prefer to close this issue.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5238>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:39:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 23:39:12 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python3 uses unicode filenames in Windows and bytes filenames (but support also unicode filenames) on other OS. We have to support both types. On POSIX system, bytes filenames can be stored in unicode filenames using sys.getfilesystemencoding() and the surrogateescape error handler (to store undecodable bytes as unicode surrogates, see PEP 383).

I would like to create fs_encode() and fs_decode() in os.path to ease the manipulation of filenames in the two bytes (str and bytes).
 * Use fs_decode() to convert a filename from the OS native format to unicode
 * Use fs_encode() to convert an unicode filename to the OS native format

On Windows, fs_decode() and fs_encode() don't touch the filename, but reject filenames of types different than str (unicode) with a TypeError, especially bytes filename.

Mac OS X rejects invalid UTF-8 filenames, and so surrogateescape should maybe not be used on this OS.

Attached patch is an implementation of this issue.

----------
components: Library (Lib), Unicode
files: os_path_fs_encode_decode.patch
keywords: patch
messages: 104063
nosy: haypo
severity: normal
status: open
title: Create fs_encode() and fs_decode() functions in os.path
versions: Python 3.2
Added file: http://bugs.python.org/file17061/os_path_fs_encode_decode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:41:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 23:41:13 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272066073.91.0.119841652872.issue8514@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:44:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 23:44:07 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272066247.19.0.300766004316.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #8513 would benefit from these functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:48:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 23:48:02 +0000
Subject: [issue8513] subprocess: support bytes program name
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272066482.41.0.902543553178.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I proposed the creation of fs_encode() and fs_decode() functions in os.path: see #8514. There functions would simplify my patch, but also make it correct on all OS (Windows, Mac, Linux).

----------
dependencies: +Create fs_encode() and fs_decode() functions in os.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat Apr 24 01:55:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 23:55:50 +0000
Subject: [issue8512] os.execv*e(): fix formatting of the environment variables
	(Python 3.1)
In-Reply-To: <1272062451.81.0.836509652271.issue8512@psf.upfronthosting.co.za>
Message-ID: <1272066950.34.0.42119278642.issue8512@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: os.execv*e(): fix formatting of the environment variables -> os.execv*e(): fix formatting of the environment variables (Python 3.1)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8512>
_______________________________________

From report at bugs.python.org  Sat Apr 24 02:12:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 24 Apr 2010 00:12:01 +0000
Subject: [issue8449] buildbot: test_dbm and test_dbm_ndbm
	failures on ia64 Ubuntu 3.1
In-Reply-To: <1271629817.22.0.668476357491.issue8449@psf.upfronthosting.co.za>
Message-ID: <1272067921.99.0.374688479339.issue8449@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: 
Now:
  buildbot: test_dbm and test_dbm_ndbm
  failures on ia64 Ubuntu 3.1
Was:
  buildbot: test_dbm and test_dbm_ndbm
  failures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8449>
_______________________________________

From report at bugs.python.org  Sat Apr 24 03:18:10 2010
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 24 Apr 2010 01:18:10 +0000
Subject: [issue8515] idle "Run Module" (F5) does not set __file__ variable
In-Reply-To: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za>
Message-ID: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

The python CLI always sets the __file__ variable, whether run as:

$ python foobar.py

or

$ python -m foobar

or

$ python
>>> import foobar   # __file__ set in foobar module

The idle program sets the __file__ variable properly when you do the import from the idle shell, but __file__ is not set with the "Run Module" (F5) command from the editor.

I've included a patch file to set __file__, but it doesn't del it after the module has run.  But maybe this is OK, because the os.chdir is not undone either???

----------
components: IDLE
files: idle.patch
keywords: patch
messages: 104066
nosy: dangyogi
severity: normal
status: open
title: idle "Run Module" (F5) does not set __file__ variable
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17062/idle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8515>
_______________________________________

From report at bugs.python.org  Sat Apr 24 10:12:00 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sat, 24 Apr 2010 08:12:00 +0000
Subject: [issue8516] Speed difference between Python 2.5 and 2.6 during
	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

The time it takes, in the application Gramps, to fill an empty bsddb database by importing an XML backup or a GECDOM file, incrises from about 2 minutes to about an hour in Windows XP ana Windows 7. No such degradation has been sen in Linux.

The Gramps code was the same in all test cases.
The running conditions were:
 
Python 2.5                     Python 2.6
Windows  4.4.5.3 (4, 6, 20)    4.7.3 (4.7.25)
Linux    4.4.5.3 (4, 6, 21)    4.7.3 (4.7.25)

Note one little version difference between Windows and Python.

If I install bsddb3 and change Gramps code for that, no noticable speed degradation can be seen.
Windows only with Python 2.6  bsddb3 4.8.4 (4.8.26).

I have run profiling and attach the results.

(Sorry for the fuzz I made in issue 8504.)

The only way of providing a test case,as far as I can find, is to install Gramps, create a new Family Tree (empty database) and import an test XML backup. There are two testcases (*.gramps)  available in:
http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/example/gramps/

Gramps can be found at: 
http://www.gramps-project.org/wiki/index.php?title=Installation

----------
components: Library (Lib)
files: statistics_for_python_25_26_run.txt.tar.gz
messages: 104067
nosy: PeterL
severity: normal
status: open
title: Speed difference between Python 2.5 and 2.6 during filling bsddb database.
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file17063/statistics_for_python_25_26_run.txt.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8516>
_______________________________________

From report at bugs.python.org  Sat Apr 24 10:33:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 24 Apr 2010 08:33:45 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <4BD2ACE5.8060200@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> Python3 uses unicode filenames in Windows and bytes filenames (but support also unicode filenames) on other OS. We have to support both types. On POSIX system, bytes filenames can be stored in unicode filenames using sys.getfilesystemencoding() and the surrogateescape error handler (to store undecodable bytes as unicode surrogates, see PEP 383).
> 
> I would like to create fs_encode() and fs_decode() in os.path to ease the manipulation of filenames in the two bytes (str and bytes).
>  * Use fs_decode() to convert a filename from the OS native format to unicode
>  * Use fs_encode() to convert an unicode filename to the OS native format
> 
> On Windows, fs_decode() and fs_encode() don't touch the filename, but reject filenames of types different than str (unicode) with a TypeError, especially bytes filename.
> 
> Mac OS X rejects invalid UTF-8 filenames, and so surrogateescape should maybe not be used on this OS.
> 
> Attached patch is an implementation of this issue.

Please follow the naming convention used in os.path. The functions
would have to be called os.path.fsencode() and os.path.fsdecode().

Other than that, I'm +0 on the patch: the sys.filesystemencoding logic
doesn't really work well in practice - on Unix and BSD platforms, there's
no such thing as a single system-wide file system and consequently,
the file system encoding depends on the path you are looking at. For most
of those file systems, the name is just a sequence of bytes with arbitrary
encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat Apr 24 10:43:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Apr 2010 08:43:13 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272098593.24.0.180846558723.issue8514@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat Apr 24 10:45:08 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Apr 2010 08:45:08 +0000
Subject: [issue8516] Speed difference between Python 2.5 and 2.6 during
	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272098708.12.0.336017102544.issue8516@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +jcea
priority:  -> normal
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8516>
_______________________________________

From report at bugs.python.org  Sat Apr 24 11:08:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 09:08:24 +0000
Subject: [issue7507] pipes.quote does not correctly escape !
In-Reply-To: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>
Message-ID: <1272100104.86.0.937017236011.issue7507@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r80433.

----------
assignee: r.david.murray -> georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7507>
_______________________________________

From report at bugs.python.org  Sat Apr 24 11:24:34 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 24 Apr 2010 09:24:34 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272101074.78.0.987815363505.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I included the test for libtinfo in the latest patch. The patch is tested
on Fedora and correctly links the curses module with -lncursesw.

This means that the ldd method works on all buildbots, OpenBSD, OpenSolaris
and Fedora.

----------
Added file: http://bugs.python.org/file17064/issue7384-5-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 24 11:33:14 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 24 Apr 2010 09:33:14 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272101594.86.0.296567037165.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'm not against sorting things out in configure.in, but I'm not quite
sure that it will be more portable than ldd:

On FreeBSD (the problem system!) I can't get this to work:

[stefan at freebsd-i386 ~]$ echo 'int main() { readline(); }' > test_readline.c
[stefan at freebsd-i386 ~]$ gcc -Wl,--warn-common xxx.c -lreadline -ltermcap -lncurses -lncursesw
[stefan at freebsd-i386 ~]$ gcc -Wl,--warn-common xxx.c -lreadline -lncurses -lncursesw
[stefan at freebsd-i386 ~]$ gcc -Wl,--warn-common xxx.c -lreadline -lncursesw


On OpenSolaris with suncc, ld does not have -warn-common.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 24 11:42:27 2010
From: report at bugs.python.org (Daniel Evers)
Date: Sat, 24 Apr 2010 09:42:27 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1272102147.98.0.695296528972.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

I attached a patch:
The backlog is set to at least 0 instead of 1. I also added a comment that a backlog < 0 can lead to problems and doesn't make sense anyway (so if there are systems that may crash with backlog < 0 this will be avoided).

----------
keywords: +patch
Added file: http://bugs.python.org/file17065/backlog0.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Sat Apr 24 11:57:22 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 24 Apr 2010 09:57:22 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1272103042.11.0.398674766615.issue8498@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It looks like you forgot to update the function's documentation ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Sat Apr 24 13:19:22 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 24 Apr 2010 11:19:22 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272107962.59.0.0190773757884.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Sigh. xxx.c == test_readline.c in the previous comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Sat Apr 24 13:54:26 2010
From: report at bugs.python.org (Daniel Evers)
Date: Sat, 24 Apr 2010 11:54:26 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1272110066.43.0.410744651537.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

Ah right ;)
Sorry, attached the path incl. the doc string.

----------
Added file: http://bugs.python.org/file17066/backlog0_incl_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Sat Apr 24 13:58:29 2010
From: report at bugs.python.org (Daniel Evers)
Date: Sat, 24 Apr 2010 11:58:29 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1272110309.02.0.589574954535.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

A second patch for the documentation of socket.listen().

----------
Added file: http://bugs.python.org/file17067/socket_listen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Sat Apr 24 14:20:17 2010
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Sat, 24 Apr 2010 12:20:17 +0000
Subject: [issue8517] Apple Style Guide link is broken in the "Documenting
	Python" chapter
In-Reply-To: <1272111617.25.0.289566077781.issue8517@psf.upfronthosting.co.za>
Message-ID: <1272111617.25.0.289566077781.issue8517@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

On this page, the Style Guide for people who want to try contributing to the Python documentation:

docs.python.org/documenting/style.html

there is a broken link to the Apple Style Guide.  The 2008 edition now seems gone and people are now apparently supposed to visit:

http://developer.apple.com/Mac/library/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf

----------
assignee: georg.brandl
components: Documentation
messages: 104077
nosy: brandon-rhodes, georg.brandl
severity: normal
status: open
title: Apple Style Guide link is broken in the "Documenting Python" chapter
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8517>
_______________________________________

From report at bugs.python.org  Sat Apr 24 14:23:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 12:23:33 +0000
Subject: [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1272111813.22.0.108463021835.issue2823@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I am just curious what convinced you to change the -2 opinion after two years with r80388?

Reopening to change resolution status.

----------
status: closed -> open
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
_______________________________________

From report at bugs.python.org  Sat Apr 24 14:23:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Apr 2010 12:23:54 +0000
Subject: [issue8517] Apple Style Guide link is broken in the "Documenting
	Python" chapter
In-Reply-To: <1272111617.25.0.289566077781.issue8517@psf.upfronthosting.co.za>
Message-ID: <1272111834.38.0.584787829666.issue8517@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8517>
_______________________________________

From report at bugs.python.org  Sat Apr 24 14:45:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 24 Apr 2010 12:45:01 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1272113101.94.0.955993617788.issue8490@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Builbots are all ok except Solaris which makes me think that maybe asyncore is broken on such platform:
http://python.org/dev/buildbot/builders/sparc%20solaris10%20gcc%20trunk/builds/728/steps/test/logs/stdio
I've tried to adjust the tests a little bit in r80415 but that didn't work.
I'm not sure how to proceed here.
If I'd have a chance to gain SSH access over the Solaris box I could try to debug the problem, otherwhise we could just disable the failing tests for Solaris.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Sat Apr 24 14:55:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 12:55:19 +0000
Subject: [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1272113719.03.0.279795272225.issue2823@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Please also add a link to issue3341 as a Superceder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
_______________________________________

From report at bugs.python.org  Sat Apr 24 14:57:25 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 12:57:25 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1272113845.21.0.0153019050379.issue3341@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I am glad there is some response to this issue in r80388

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:00:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:00:36 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1272114036.43.0.25411247584.issue3341@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:01:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:01:22 +0000
Subject: [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1272114082.76.0.0764210890193.issue2823@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

These links just go to the same page as the link on the front page.  It's not a link to the tracker, or a form to report a bug in the documented module.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:04:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:04:55 +0000
Subject: [issue8517] Apple Style Guide link is broken in the "Documenting
	Python" chapter
In-Reply-To: <1272111617.25.0.289566077781.issue8517@psf.upfronthosting.co.za>
Message-ID: <1272114295.23.0.696915496002.issue8517@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This was already fixed in r80150, but not backported; I've done so now in r80438 ff.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8517>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:06:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:06:15 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1272114375.0.0.385523951517.issue3341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm closing this again; I can see that nobody will implement this for Python if it's not available in Sphinx, and also I don't think it would be a good idea to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:11:13 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 24 Apr 2010 13:11:13 +0000
Subject: [issue6091] Curses segfaulting in FreeBSD/amd64
In-Reply-To: <1243044628.32.0.644486843257.issue6091@psf.upfronthosting.co.za>
Message-ID: <1272114673.47.0.5793147864.issue6091@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Can you check if the latest patch for issue 7384 fixes the problem?
The patch is against py3k, but it comes down to this:

  1) Build the readline module _only_ with -lreadline (instead of
     -lreadline -lncursesw)

  2) Build the curses and curses_panel modules with -lncurses (instead
     of -lncursesw)

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6091>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:12:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:12:59 +0000
Subject: [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1272114779.06.0.889391325875.issue2823@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution: rejected -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:13:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 13:13:04 +0000
Subject: [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1272114784.91.0.766139442576.issue2823@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Still the part "Report bug on this page" is covered. Please, add a link to Superceder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:16:30 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 24 Apr 2010 13:16:30 +0000
Subject: [issue8516] Speed difference between Python 2.5 and 2.6 during
	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272114990.85.0.637201781745.issue8516@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, install Berkeley DB 4.6.X in linux and reinstall bsddb3 to use it, instead of BDB 4.7. Would be a good idea to install pybsddb 4.7.3, too, to mimic Windows environment under linux closely.

After doing this, and verifying that linux resemble now the Windows environment, try the DB load again.

I need to confirm if the issue is in bsddb module, Berkeley DB code or BDB interaction with Windows OS/Filesystem.

Anyway, if installing a modern bsddb3 (note that we have 5.0.0 available) makes the problem go away, it is a non-issue. Python 2.6 is basically in security/crashes fixes only now. Or very close to it.

With python 2.7 almost ready, I would try the beta too, to confirm this problem is not a problem anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8516>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:16:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:16:34 +0000
Subject: [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1272114994.39.0.574299303671.issue2823@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

As you wish.

----------
superseder:  -> "Suggest a change" link

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:16:43 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 13:16:43 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1272115003.59.0.977929390769.issue3341@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Georg, if you are not going to implement it, it doesn't mean nobody will do this. In Sphinx or through disqus. I do not see the reason to close this feature request.

Also I do not understand arguments like:
"Yes, this is under consideration." in msg69834 and
"I don't think it would be a good idea to do so." in msg104084

Care to explain why you have changed your mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:17:53 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 24 Apr 2010 13:17:53 +0000
Subject: [issue8516] Speed difference between Python 2.5 and 2.6 during
	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272115073.92.0.802839170641.issue8516@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee:  -> jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8516>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:22:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:22:07 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1272115327.12.0.770864242582.issue3341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I haven't changed my mind.  The "it would not be a good idea to do so" refers to implementing this for Python exclusively.

Of course, if you volunteer to do so, I won't stop you :)  Otherwise, please trust my judgement that this issue will do nothing except eventually be closed again due to lack of movement, or because something has been implemented in Sphinx.  It may even be during this year's Summer of Code, if we're lucky.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:28:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 13:28:49 +0000
Subject: [issue8481] doc: ctypes no need to explicitly allocate writable
	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1272115729.94.0.156722115316.issue8481@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> theller
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8481>
_______________________________________

From report at bugs.python.org  Sat Apr 24 15:41:39 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 24 Apr 2010 13:41:39 +0000
Subject: [issue8516] Speed difference between Python 2.5 and 2.6 during
	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272116499.84.0.410307468705.issue8516@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +guy.linton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8516>
_______________________________________

From report at bugs.python.org  Sat Apr 24 16:25:28 2010
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Deccico?=)
Date: Sat, 24 Apr 2010 14:25:28 +0000
Subject: [issue8518] small typo in http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272119128.07.0.474354873892.issue8518@psf.upfronthosting.co.za>
Message-ID: <1272119128.07.0.474354873892.issue8518@psf.upfronthosting.co.za>


New submission from Adri?n Deccico <deccico at gmail.com>:

Hi, in this document: 

Idioms and Anti-Idioms in Python

In the "except" section, where it says:

"The example above is better written"

it should said: 

"The example below is better written"

----------
assignee: georg.brandl
components: Documentation
messages: 104091
nosy: Adri?n.Deccico, georg.brandl
severity: normal
status: open
title: small typo in http://docs.python.org/howto/doanddont.html
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8518>
_______________________________________

From report at bugs.python.org  Sat Apr 24 16:35:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 14:35:25 +0000
Subject: [issue8518] small typo in http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272119128.07.0.474354873892.issue8518@psf.upfronthosting.co.za>
Message-ID: <1272119725.32.0.885360483442.issue8518@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The text is correct as-is; the meaning is "The example that is shown above is better written like this:".

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8518>
_______________________________________

From report at bugs.python.org  Sat Apr 24 16:51:46 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 24 Apr 2010 14:51:46 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272120706.97.0.146553214669.issue8514@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat Apr 24 16:52:07 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 24 Apr 2010 14:52:07 +0000
Subject: [issue8513] subprocess: support bytes program name
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272120727.27.0.888518268257.issue8513@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat Apr 24 17:15:19 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 24 Apr 2010 15:15:19 +0000
Subject: [issue5583] Optional extensions in setup.py
In-Reply-To: <1238200962.29.0.771243104654.issue5583@psf.upfronthosting.co.za>
Message-ID: <1272122119.99.0.0883626940504.issue5583@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Warning: reverted in trunk, now leaves in distutils2

----------
components: +Distutils2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5583>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:09:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 16:09:51 +0000
Subject: [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The patch adds link to reference with various flags for termios functions and fcntl.ioctl call.

----------
assignee: georg.brandl
components: Documentation
files: ____.reference-termios-specification-for-flags.diff
keywords: patch
messages: 104094
nosy: georg.brandl, techtonik
severity: normal
status: open
title: [patch] doc: termios and ioctl reference links
versions: Python 2.7
Added file: http://bugs.python.org/file17068/____.reference-termios-specification-for-flags.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8519>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:14:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 24 Apr 2010 16:14:30 +0000
Subject: [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1272125670.81.0.84580512274.issue8519@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note that there can be any whitespace in reST markup, e.g. you can put a newline betweeen ?`thing? and ?<link>`_?, thus avoiding too long lines. I think you can put a newline in a ?<link>? too, they will be removed.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8519>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:29:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 16:29:59 +0000
Subject: [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1272126599.34.0.6268372741.issue8519@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The POSIX reference is OK; I'm hesitant to put a Linux-specific reference in though.  Also, ioctls are not limited to tty operations.  IMO a :manpage:`ioctl(2)` would suffice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8519>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:34:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 24 Apr 2010 16:34:39 +0000
Subject: [issue7838] Undocumented subprocess functions on Windows
In-Reply-To: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>
Message-ID: <1272126879.27.0.376908221286.issue7838@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed with r80439-r80442.

----------
assignee: georg.brandl -> brian.curtin
components: +Extension Modules -Documentation
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7838>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:42:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 16:42:38 +0000
Subject: [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1272127358.66.0.640672797234.issue8519@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

?ric, thanks, attached reStructured patch.

Georg, ioctl(2) is useless, because it doesn't contain the information people need in addition to Python manual, i.e. various examples (like how to get console size) and constants (like TIOCGWINSZ) that are hard to find otherwise.

----------
Added file: http://bugs.python.org/file17069/8519.reference-termios-specification-for-flags.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8519>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:56:25 2010
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Deccico?=)
Date: Sat, 24 Apr 2010 16:56:25 +0000
Subject: [issue8518] small typo in http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272119725.32.0.885360483442.issue8518@psf.upfronthosting.co.za>
Message-ID: <p2zaf571f451004240955p53172fb6y3c6ca072cdc0d855@mail.gmail.com>


Adri?n Deccico <deccico at gmail.com> added the comment:

Hi Georg,

Ok, so perhaps the text is a little confusing. Perhaps it would be a
good idea to add a colon or as you state the words "like this"

thanks

On Sat, Apr 24, 2010 at 4:35 PM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> The text is correct as-is; the meaning is "The example that is shown above is better written like this:".
>
> ----------
> resolution: ?-> works for me
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8518>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8518>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:57:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 16:57:18 +0000
Subject: [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1272128238.15.0.104834912492.issue8519@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

ioctl(2) usually has "see also" entries that list the available ioctls, such as ioctl_list on linux.

If you want to link to examples like getting console size, the manpage isn't very helpful either, since you have to figure out how exactly to call ioctl.  Linking to a pertinent recipe e.g. in the Cookbook, or including the example right there makes much more sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8519>
_______________________________________

From report at bugs.python.org  Sat Apr 24 18:58:01 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 16:58:01 +0000
Subject: [issue8518] small typo in http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272119128.07.0.474354873892.issue8518@psf.upfronthosting.co.za>
Message-ID: <1272128281.28.0.131023557407.issue8518@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'll let an English native speaker decide how to best express this.

----------
assignee: georg.brandl -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8518>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:09:52 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 17:09:52 +0000
Subject: [issue8520] test doc issue
In-Reply-To: <1272128992.76.0.452224107424.issue8520@psf.upfronthosting.co.za>
Message-ID: <1272128992.76.0.452224107424.issue8520@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Testing delivery of tracker messages, and autonosy for docs issues.

----------
assignee: docs at python
components: Documentation
messages: 104102
nosy: docs at python, georg.brandl
severity: normal
status: open
title: test doc issue
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8520>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:10:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 17:10:42 +0000
Subject: [issue8520] test doc issue
In-Reply-To: <1272128992.76.0.452224107424.issue8520@psf.upfronthosting.co.za>
Message-ID: <1272129042.57.0.147184477668.issue8520@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, works.

----------
assignee: docs at python -> 
nosy:  -docs at python
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8520>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:10:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 24 Apr 2010 17:10:46 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>
Message-ID: <1272129046.11.0.967706054991.issue8505@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the unnecessary removal of __future__ imports but consistent with the idea that Python?3 is a new start, a blank sheet, and we don?t mention every novelty since previous versions.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:12:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 24 Apr 2010 17:12:08 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272129046.11.0.967706054991.issue8505@psf.upfronthosting.co.za>
Message-ID: <4BD32665.9020509@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

s/but/is/

----------
title: 2to3 fix_future.py removes __future__ imports, but should it? -> 2to3 fix_future.py removes __future__ imports,	but should it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:22:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 17:22:22 +0000
Subject: [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1272129742.52.0.211339004786.issue8519@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I do not mind if you include a better link with ioctl constants explained or have ideas for examples. I hope you agree the ioctl(2) man page contains much less useful information than http://www.kernel.org/doc/man-pages/online/pages/man4/tty_ioctl.4.html

But I see your point that ioctl is not used solely for tty. Perhaps there could be two links. Removing tty_ioctl constants reference is not an option for me, because the whole stuff is complicated and for me it was very hard to find these console functions for Linux. There is no other way to work with Linux console from Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8519>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:27:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 24 Apr 2010 17:27:09 +0000
Subject: [issue8521] Allow some winreg functions to accept keyword arguments
Message-ID: <1272130029.0.0.870477919071.issue8521@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee: brian.curtin
components: Extension Modules, Windows
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow some winreg functions to accept keyword arguments
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8521>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:28:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 24 Apr 2010 17:28:41 +0000
Subject: [issue5774] _winreg.OpenKey() is documented with keyword arguments,
	but doesn't take them
In-Reply-To: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
Message-ID: <1272130121.25.0.993250890099.issue5774@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I changed the documentation to reflect that OpenKey, CreateKeyEx, and DeleteKeyEx (latter two are 2.7/3.2 only) do not take keyword arguments, but they have default values. Done in r80445-r80448.

I created a feature request in #8521 to implement keyword arguments.

----------
assignee:  -> brian.curtin
components: +Documentation -Library (Lib)
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5774>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:32:30 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 24 Apr 2010 17:32:30 +0000
Subject: [issue8509] fix autoconf quoting in help strings and code snippets
In-Reply-To: <1272035806.11.0.986586497024.issue8509@psf.upfronthosting.co.za>
Message-ID: <1272130350.02.0.243274207298.issue8509@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

applied the changes for 2.7 and 3.2.  there is a diff for the regenerated configure like

-rm -f -r conftest*
+rm -f conftest*

I explicitely used a vanilla autoconf-2.61 download for regenerating the configure script. Why the diff?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8509>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:35:03 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 24 Apr 2010 17:35:03 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272130503.08.0.828313545141.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

here is the diff for configure.in. The __EXTENSIONS__ macro is defined by 2.65 for Solaris, removed this explicit definition. running a test build

----------
Added file: http://bugs.python.org/file17070/configure.in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:47:57 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Apr 2010 17:47:57 +0000
Subject: [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: <1272131277.51.0.723036317849.issue8177@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

As covered in http://docs.python.org/dev/reference/expressions.html#calls, this is how function calls are bound.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8177>
_______________________________________

From report at bugs.python.org  Sat Apr 24 19:57:35 2010
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Deccico?=)
Date: Sat, 24 Apr 2010 17:57:35 +0000
Subject: [issue8522] enhacement proposal in
	http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272131855.89.0.865652130353.issue8522@psf.upfronthosting.co.za>
Message-ID: <1272131855.89.0.865652130353.issue8522@psf.upfronthosting.co.za>


New submission from Adri?n Deccico <deccico at gmail.com>:

Hi, in "Exceptions" section. 

Instead of using:

def get_status(file):
    fp = open(file)
    try:
        return fp.readline()
    finally:
        fp.close()

Why no suggest this method:

def get_status(file):
    with open(file) as fp:
	return fp.readline()


which will properly close the file.

----------
assignee: docs at python
components: Documentation
messages: 104111
nosy: Adri?n.Deccico, docs at python
severity: normal
status: open
title: enhacement proposal in http://docs.python.org/howto/doanddont.html
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8522>
_______________________________________

From report at bugs.python.org  Sat Apr 24 20:04:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 24 Apr 2010 18:04:50 +0000
Subject: [issue8522] enhacement proposal in howto/doanddont
In-Reply-To: <1272131855.89.0.865652130353.issue8522@psf.upfronthosting.co.za>
Message-ID: <1272132290.17.0.748366662461.issue8522@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

You?re right, this idiom (new in 2.5, always enabled in 2.6) is now the recommended way of doing this. Note that the older code does close the file properly too, it?s just another way of doing it.

Would you like to provide a patch against the latest version of this file?
 
Regards

----------
assignee: docs at python -> 
nosy: +merwok
stage:  -> needs patch
title: enhacement proposal in http://docs.python.org/howto/doanddont.html -> enhacement proposal in howto/doanddont
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8522>
_______________________________________

From report at bugs.python.org  Sat Apr 24 20:06:39 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Apr 2010 18:06:39 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1272132399.78.0.092272388974.issue8419@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file17071/refactor_a_bit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Sat Apr 24 20:12:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 24 Apr 2010 18:12:15 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1272132735.8.0.0388369857831.issue8350@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From http://docs.python.org/dev/reference/expressions.html#calls

?An implementation may provide built-in functions whose positional parameters do not have names, even if they are ?named? for the purpose of documentation, and which therefore cannot be supplied by keyword.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sat Apr 24 20:16:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 18:16:13 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1272132973.93.0.577464712834.issue8350@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think it would be overkill to add special markup for positional-only arguments. I think we should just close the issue as invalid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sat Apr 24 20:21:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Apr 2010 18:21:48 +0000
Subject: [issue8419] dict constructor allows invalid identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1272133308.66.0.317280990926.issue8419@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80450.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8419>
_______________________________________

From report at bugs.python.org  Sat Apr 24 20:23:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 24 Apr 2010 18:23:25 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1272133405.2.0.560181043295.issue8350@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The comment I made before yours supports that. It?s not a bug, it?s a documented behavior that just needs more exposure in the intro to the docs. (Do we have a page explaining markup?)

The real real fix would be for C functions to accept kwargs, but as far as doc is concerned, it?s ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sat Apr 24 20:57:43 2010
From: report at bugs.python.org (rubenlm)
Date: Sat, 24 Apr 2010 18:57:43 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>


New submission from rubenlm <ruben at libhertz.com>:

The code that lists directory contents in rmtree is:

try:
  names = os.listdir(path)
except os.error, err:
  onerror(os.listdir, path, sys.exc_info())

If there is an error there is nothing the "onerror" function can do to fix the problem because the variable "names" will not be updated after the problem is solved in "onerror".

Two possible solutions:

1 - Call os.listdir() again after onerror()

    try:
      names = os.listdir(path)
    except os.error, err:
      onerror(os.listdir, path, sys.exc_info())
      names = os.listdir(path)

2 - Allow onerror() to return a value and set "names" to that value.

    try:
      names = os.listdir(path)
    except os.error, err:
      names = onerror(os.listdir, path, sys.exc_info())

----------
components: Extension Modules
messages: 104117
nosy: rubenlm
severity: normal
status: open
title: shutil.rmtree and os.listdir cannot recover on error conditions
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:12:27 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sat, 24 Apr 2010 19:12:27 +0000
Subject: [issue8516] Speed difference between Python 2.5 and 2.6 during
	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272136347.68.0.178926263318.issue8516@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

1. Sorry, I made a mistake this morning. (Had to run to a funeral.)
These are the correct version:
Python 2.5                     Python 2.6
Windows  4.4.5.3 (4, 4, 20)    4.7.3 (4.7.25)
Linux    4.4.5.3 (4, 6, 21)    4.7.3 (4.7.25)

So, the same versions of bsddb and DB in Python 2.6 gives the slow speed performance with Windows but not with Linux. This means that the Windows and Linux environments are equal as far as I can see.
 
2. I installed bsddb3 5.0.0 without any problem, but I had to move libdb48.dll from c:\Python26\bsddb3\utils\
to c:\Python26\Lib\site-packages\bsddb3\
otherwise it could not be found. Any explanation for this?

3. Could not run Gramps in Windows with Py 2.7 as Gramps needs pygtk, pycairo and pygobject to run.

It seems to be a strange issue. It can be worked around by using bsddb3 in stead in Gramps for those who needs it. It is only a problem when you import a backup or a GEDCOM and when you rebuild reference maps, which you don't do very often. It's not a issue with normal usage of Gramps.

So, maybe let it wait until 2.7 is out?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8516>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:14:11 2010
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Deccico?=)
Date: Sat, 24 Apr 2010 19:14:11 +0000
Subject: [issue8522] enhacement proposal in howto/doanddont
In-Reply-To: <1272131855.89.0.865652130353.issue8522@psf.upfronthosting.co.za>
Message-ID: <1272136451.37.0.150529810633.issue8522@psf.upfronthosting.co.za>


Adri?n Deccico <deccico at gmail.com> added the comment:

Hi, you are right. I am attaching the patch. I tested against 2.6.5 and trunk (the file has no changed)

thanks

----------
keywords: +patch
Added file: http://bugs.python.org/file17072/doanddont.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8522>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:16:43 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 24 Apr 2010 19:16:43 +0000
Subject: [issue8521] Allow some winreg functions to accept keyword arguments
In-Reply-To: <1272136603.7.0.986572012684.issue8521@psf.upfronthosting.co.za>
Message-ID: <1272136603.7.0.986572012684.issue8521@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Hi Brian,

It looks like you had attached to issue5774 a patch to allow OpenKey to accept keyword arguments.  Just thought I'd mention that here so there's a link back to it.

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8521>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:19:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 19:19:29 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272136769.31.0.731118143686.issue7865@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The tests should probably check all three types of I/O (raw, buffered, text).

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:25:32 2010
From: report at bugs.python.org (Tim Lyons)
Date: Sat, 24 Apr 2010 19:25:32 +0000
Subject: [issue8516] Speed difference between Python 2.5 and 2.6 during
	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272137132.55.0.671510451923.issue8516@psf.upfronthosting.co.za>


Tim Lyons <guy.linton at gmail.com> added the comment:

I see the same slowdown in Mac OS X with python 2.6 and bsddb 4.7.3 (4.7.25). (So, same version as Windows, and same versions as apparently run OK in linux).

I rely on MacPorts to use these products, so have no idea how I would use bdsdb3 still less python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8516>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:27:35 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 24 Apr 2010 19:27:35 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>
Message-ID: <1272137255.2.0.0311426370261.issue8505@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Removing __future__ as part of explicit command line execution of 2to3 makes some sense, but I wonder if 2to3 is used more often automatically (e.g. via Distribute) where it's at best unhelpful.  2to3 is all about making it easy to port code from Python 2 to 3, and this particular transformation makes it (albeit, slightly so) harder.

A different idea would be to add a comment before the future import indicating its uselessness, but not removing it.  OTOH, I would also be happy with a better way to just disable it in a setup.py (e.g. by passing the -x flag in somehow).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:29:28 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Apr 2010 19:29:28 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272137255.2.0.0311426370261.issue8505@psf.upfronthosting.co.za>
Message-ID: <s2u1afaf6161004241229wb561742ctb9fd43a9562d8e12@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/4/24 Barry A. Warsaw <report at bugs.python.org>:
>
> Barry A. Warsaw <barry at python.org> added the comment:
>
> Removing __future__ as part of explicit command line execution of 2to3 makes some sense, but I wonder if 2to3 is used more often automatically (e.g. via Distribute) where it's at best unhelpful. ?2to3 is all about making it easy to port code from Python 2 to 3, and this particular transformation makes it (albeit, slightly so) harder.

It's also designed to be easily customizable.

>
> A different idea would be to add a comment before the future import indicating its uselessness, but not removing it. ?OTOH, I would also be happy with a better way to just disable it in a setup.py (e.g. by passing the -x flag in somehow).

I'm not sure we should get into the habit of telling people that their
code is useless. :)

I'll just close this as won't fix.

----------
title: 2to3 fix_future.py removes __future__ imports,	but should it? -> 2to3 fix_future.py removes __future__ imports, but should it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:30:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Apr 2010 19:30:38 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>
Message-ID: <1272137438.6.0.558683785849.issue8505@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:34:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 24 Apr 2010 19:34:23 +0000
Subject: [issue8505] 2to3 fix_future.py removes __future__ imports,
	but should it?
In-Reply-To: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>
Message-ID: <1272137663.25.0.239135264511.issue8505@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Since the workaround is easy enough, I won't push for this.  I still think it's an unhelpful transformation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8505>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:52:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 24 Apr 2010 19:52:58 +0000
Subject: [issue8521] Allow some winreg functions to accept keyword arguments
In-Reply-To: <1272136603.7.0.986572012684.issue8521@psf.upfronthosting.co.za>
Message-ID: <1272138778.52.0.14728276723.issue8521@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's an expanded version of that patch to include two newer functions, plus docs and test.

The doc might need work on those signatures -- there was some discussion on IRC about how keyword arguments should be documented.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8521>
_______________________________________

From report at bugs.python.org  Sat Apr 24 21:53:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 24 Apr 2010 19:53:56 +0000
Subject: [issue8521] Allow some winreg functions to accept keyword arguments
In-Reply-To: <1272136603.7.0.986572012684.issue8521@psf.upfronthosting.co.za>
Message-ID: <1272138836.01.0.331844606829.issue8521@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Forgot to attach the patch...

----------
keywords: +patch
Added file: http://bugs.python.org/file17073/issue8521.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8521>
_______________________________________

From report at bugs.python.org  Sat Apr 24 22:45:09 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 24 Apr 2010 20:45:09 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1272141909.7.0.106683649527.issue8319@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmail.com> added the comment:

I have modified my program so I will check for data/no-data at the end of a td-call (td_end). Now it produces the correct result. I think you can close this issue.

----------
Added file: http://bugs.python.org/file17074/shannon_data-v2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8319>
_______________________________________

From report at bugs.python.org  Sat Apr 24 22:47:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 20:47:47 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In 3.x, SSL sockets are created by dup()ing the original socket and then closing it. No attempt is made to conserve the socket's characteristics, such as the timeout and probably other flags.

I understand that it may be too late to change the design decision of using dup() and closing the original, but perhaps we should make a best effort to retain the original socket's characteristics. Or perhaps this limitation should be clearly documented (since especially 2.x works differently).

----------
components: Library (Lib)
messages: 104129
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: SSL sockets do not retain the parent socket's attributes
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sat Apr 24 23:11:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 21:11:58 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272143649.3402.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is actually a little funnier. dup() preserves the
blocking/non-blocking nature of the underlying OS socket, but not the
"timeout" of the Python socket. As such, a "blocking-with-timeout"
Python socket gets replaced with a truely non-blocking socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sat Apr 24 23:20:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 21:20:58 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272144058.98.0.0609352881206.issue8524@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another consequence is that the following check in __init__:

                    timeout = self.gettimeout()
                    if timeout == 0.0:
                        # non-blocking
                        raise ValueError("do_handshake_on_connect should not be specified for non-blocking sockets")

could never get triggered since the timeout is reset to None by virtue of creating a new socket object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sat Apr 24 23:21:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 21:21:32 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272144092.16.0.120306092765.issue8524@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> high
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sat Apr 24 23:33:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 21:33:15 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1272144795.42.0.936387375801.issue5103@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in trunk (r80452) and 2.6 (r80453). Also ported relevant parts to 3.x (one half of the test had to be disabled because or #8524).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Sun Apr 25 00:10:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 22:10:45 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272147045.41.0.0065871212946.issue8524@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I committed a fix+tests for the timeout value in r80456 (py3k) and r80457 (3.1). Apparently the socket objects' own dup() method doesn't try to retain anything else than the timeout.

I'm leaving this issue as "pending" in case criticism or better options are provided :)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sun Apr 25 01:10:05 2010
From: report at bugs.python.org (Rob Cliffe)
Date: Sat, 24 Apr 2010 23:10:05 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>


New submission from Rob Cliffe <rob.cliffe at btinternet.com>:

help() on an exception class lists the method resolution order, which is in effect the class inheritance hierarchy.  E.g. help(ArithmeticError) lists ArithmeticError, StandardError, Exception, BaseException, __builtin__.object.  It struck me it would help to find my way around if it also listed the builtin SUBclasses (if any).  Something like:
    Built-in subclasses:
        FloatingPointError
        OverflowError
        ZeroDivisionError
In fact why not do it for any class, not just exceptions?
I attach a patched version of pydoc.py - tested but only on my PC which is running Python 2.5 under Windows XP.  I have added lines 1129-1148 to the docclass method of the TextDoc class (and flagged them # [RAC] ).
(I don't pretend to understand the magic where __builtins__ is a dictionary when pydoc.py is run but becomes a module later on.  Never mind - the patch works (I believe).)
For consistency, a similar patch would also have to be made to the docclass nethod of the HTMLDoc class (which outputs HTML rather than plain text).  I have not attempted this as I don't know how it is called and hence how to test any patch, but it should be straightforward for anyone with the know-how.

----------
files: pydoc.py
messages: 104134
nosy: robcliffe
severity: normal
status: open
title: Small enhancement to help()
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file17075/pydoc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Sun Apr 25 02:07:14 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 25 Apr 2010 00:07:14 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Working with Python 2.6.5, I find I cannot put multiple CABs in the same installer.  This is due to this statement in msilib.CAB.commit():

        add_data(db, "Media",
                [(1, self.index, None, "#"+self.name, None, None)])

The key, 1, must be different for each record in the 'Media' table.  The symptom is an exception something like this:

_msi.MSIError: Could not insert [(1, 3, None, '#foo', None, None)] into Media

----------
assignee: loewis
components: Distutils, Library (Lib), Windows
keywords: easy
messages: 104135
nosy: janssen, loewis
severity: normal
status: open
title: msilib doesn't support multiple CAB instances in same installer
versions: Python 2.6, Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Apr 25 02:30:29 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 25 Apr 2010 00:30:29 +0000
Subject: [issue8319] HTMLparser does not handle call to handle_data when a tag
	contains no data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1272155429.32.0.328266843612.issue8319@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks. Closing on submitter's note.

----------
resolution:  -> invalid
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8319>
_______________________________________

From report at bugs.python.org  Sun Apr 25 03:16:21 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 25 Apr 2010 01:16:21 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1272158181.86.0.363283355824.issue8498@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

It'd be nice to have a unit test that passes a small enough value to listen() to trigger the check.  Since there's no way to reliably determine what the system backlog really is, there's probably no reason to actually try to determine that the "right" value was passed to listen.  Just making sure the code actually goes through the success-case when this check is hit is probably enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Sun Apr 25 03:21:02 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 25 Apr 2010 01:21:02 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272158462.96.0.727764730478.issue8524@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Well, at the risk of stating the obvious, perhaps the dup() thing should be eliminated.  The justification for it seems less than clear, and apparently it causes some problems.

That might be a direction to consider in the long term, though, rather than as a (different) immediate fix for this issue.

----------
nosy: +exarkun
priority: high -> normal
resolution: fixed -> 
stage: committed/rejected -> 
status: pending -> open
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sun Apr 25 03:33:57 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Apr 2010 01:33:57 +0000
Subject: [issue8527] [PEP 3147] compileall.compile_dir() called multiple times
	creates empty __pycache__/__pycache__ subdirectories
In-Reply-To: <1272159236.82.0.290282900197.issue8527@psf.upfronthosting.co.za>
Message-ID: <1272159236.82.0.290282900197.issue8527@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

compileall.compile_dir() called multiple times creates empty __pycache__/__pycache__ subdirectories. I'm attaching the patch.

$ mkdir test
$ touch test/__init__.py
$ python3.2 -c 'import compileall; compileall.compile_dir("test")'
Listing test ...
Compiling test/__init__.py ...
$ tree test
test
??? __init__.py
??? __pycache__
    ??? __init__.cpython-32.pyc

1 directory, 2 files
$ python3.2 -c 'import compileall; compileall.compile_dir("test")'
Listing test ...
Listing test/__pycache__ ...
$ tree test
test
??? __init__.py
??? __pycache__
    ??? __init__.cpython-32.pyc
    ??? __pycache__

2 directories, 2 files

----------
components: Library (Lib)
files: compileall.patch
keywords: patch
messages: 104139
nosy: Arfrever, barry
severity: normal
status: open
title: [PEP 3147] compileall.compile_dir() called multiple times creates empty __pycache__/__pycache__ subdirectories
versions: Python 3.2
Added file: http://bugs.python.org/file17076/compileall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8527>
_______________________________________

From report at bugs.python.org  Sun Apr 25 03:43:19 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 25 Apr 2010 01:43:19 +0000
Subject: [issue8527] [PEP 3147] compileall.compile_dir() called multiple times
	creates empty __pycache__/__pycache__ subdirectories
In-Reply-To: <1272159236.82.0.290282900197.issue8527@psf.upfronthosting.co.za>
Message-ID: <1272159799.35.0.0458078116755.issue8527@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8527>
_______________________________________

From report at bugs.python.org  Sun Apr 25 05:07:59 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 25 Apr 2010 03:07:59 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1272164879.19.0.674272384376.issue7992@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

For future reference:

http://mail.python.org/pipermail/python-committers/2010-April/000875.html

The final consensus was not to integrate bsddb Capsule for Python 2.7, since CObject is not actually deprecated in python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Sun Apr 25 05:15:26 2010
From: report at bugs.python.org (Ron Adam)
Date: Sun, 25 Apr 2010 03:15:26 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1272165326.81.0.576971003741.issue8525@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Sun Apr 25 05:15:29 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 25 Apr 2010 03:15:29 +0000
Subject: [issue5630] Create alternative CObject API that is safe and clean
In-Reply-To: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>
Message-ID: <1272165329.63.0.848398479894.issue5630@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5630>
_______________________________________

From report at bugs.python.org  Sun Apr 25 05:29:33 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 25 Apr 2010 03:29:33 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1272166173.39.0.61896024706.issue5872@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________

From report at bugs.python.org  Sun Apr 25 06:51:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 25 Apr 2010 04:51:03 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1272171063.37.0.43855578542.issue8526@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You can have at most one CAB object per database, yes. However, you can have certainly multiple cab files in the installer; just call add_data yourself.

If you are using the API provided by msilib, there should be no need to ever have more than one CAB instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Apr 25 07:21:07 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 25 Apr 2010 05:21:07 +0000
Subject: [issue5575] Add env vars for controlling building sqlite,
	hashlib and ssl
In-Reply-To: <1238101680.27.0.350099709898.issue5575@psf.upfronthosting.co.za>
Message-ID: <1272172867.09.0.924348564861.issue5575@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Collin: Antoine has asked for some feedback, can you answer that question?

----------
assignee:  -> collinwinter
nosy: +jafo
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5575>
_______________________________________

From report at bugs.python.org  Sun Apr 25 08:16:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Apr 2010 06:16:02 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1272176162.59.0.154181181982.issue8525@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Sun Apr 25 09:18:48 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sun, 25 Apr 2010 07:18:48 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272179928.81.0.878043676511.issue7865@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


Removed file: http://bugs.python.org/file17046/release_io_close_exceptions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Sun Apr 25 09:20:17 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sun, 25 Apr 2010 07:20:17 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272180017.69.0.92736269036.issue7865@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

SHould be better this way then B-)

----------
Added file: http://bugs.python.org/file17077/no_swallow_on_close2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Sun Apr 25 11:22:56 2010
From: report at bugs.python.org (akira)
Date: Sun, 25 Apr 2010 09:22:56 +0000
Subject: [issue8528] typo in argparse documentation
In-Reply-To: <1272187376.31.0.670187043497.issue8528@psf.upfronthosting.co.za>
Message-ID: <1272187376.31.0.670187043497.issue8528@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

`messges` should be replaced by `messages` on http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code page.

----------
assignee: docs at python
components: Documentation
messages: 104144
nosy: akira, docs at python
severity: normal
status: open
title: typo in argparse documentation
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8528>
_______________________________________

From report at bugs.python.org  Sun Apr 25 12:16:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Apr 2010 10:16:11 +0000
Subject: [issue8528] typo in argparse documentation
In-Reply-To: <1272187376.31.0.670187043497.issue8528@psf.upfronthosting.co.za>
Message-ID: <1272190571.35.0.110728391354.issue8528@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r80460.

----------
assignee: docs at python -> 
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8528>
_______________________________________

From report at bugs.python.org  Sun Apr 25 12:17:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Apr 2010 10:17:49 +0000
Subject: [issue8522] enhacement proposal in howto/doanddont
In-Reply-To: <1272131855.89.0.865652130353.issue8522@psf.upfronthosting.co.za>
Message-ID: <1272190669.78.0.907583316112.issue8522@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r80461.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8522>
_______________________________________

From report at bugs.python.org  Sun Apr 25 12:24:44 2010
From: report at bugs.python.org (Dan Kenigsberg)
Date: Sun, 25 Apr 2010 10:24:44 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1272191084.44.0.182681478349.issue4147@psf.upfronthosting.co.za>


Changes by Dan Kenigsberg <danken at redhat.com>:


----------
nosy: +danken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Sun Apr 25 15:25:38 2010
From: report at bugs.python.org (Ray.Allen)
Date: Sun, 25 Apr 2010 13:25:38 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272201938.13.0.229385424121.issue7946@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Apr 25 18:01:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 16:01:18 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272211278.62.0.936715621529.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Please follow the naming convention used in os.path. The functions
> would have to be called os.path.fsencode() and os.path.fsdecode().

Ok

> Other than that, I'm +0 on the patch: the sys.filesystemencoding
> logic doesn't really work well in practice - on Unix and BSD
> platforms, there's no such thing as a single system-wide file
> system

Today, most POSIX system uses utf8 by default for all partitions.  If you mount an USB key, CD-Rom or network shared directory with the wrong options, you may get filenames in a different encoding. But this issue is not about fixing your OS configuration, but helping the most common case: a system using the same encoding everywhere (for the whole file system).

You are still free to use directly the native OS type (unicode on Windows, bytes on other OS), ie. don't use fsencode()/fsdecode().

Python3 prefers unicode, eg. print expects an unicode string, not a byte string. I mean it's more pratical to use unicode everywhere in Python, and so fsencode()/fsdecode() can be really useful on POSIX systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sun Apr 25 19:01:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 25 Apr 2010 17:01:54 +0000
Subject: [issue8529] subclassing builtin class (str, unicode,
	list...) needs to override __getslice__
In-Reply-To: <1272214913.44.0.488253042315.issue8529@psf.upfronthosting.co.za>
Message-ID: <1272214913.44.0.488253042315.issue8529@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

It looks like a bug, because __getslice__ is deprecated since 2.0.

If you subclass a builtin type and override the __getitem__ method, you need to override the (deprecated) __getslice__ method too.
And if you run your program with "python -3", it 

Example script:


class Upper(unicode):

    def __getitem__(self, index):
        return unicode.__getitem__(self, index).upper()

    #def __getslice__(self, i, j):
        #return self[i:j:]


if __name__ == '__main__':
    text = Upper('Lorem ipsum')

    print text[:]
    print text[::]

----------
components: Interpreter Core
messages: 104148
nosy: flox
priority: normal
severity: normal
status: open
title: subclassing builtin class (str, unicode, list...) needs to override __getslice__
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8529>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:05:11 2010
From: report at bugs.python.org (Alex)
Date: Sun, 25 Apr 2010 18:05:11 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

In Objects/stringlib/fastsearch.h the lines:

                if (!STRINGLIB_BLOOM(mask, s[i-1]))

and

                if (!STRINGLIB_BLOOM(mask, s[i-1]))

can read beyond the front of the array that is passed to it when the loop enters with i = 0.

I originally noticed this when porting the algorithm to PyPy (which has bounds checking :)), all tests pass if I simple add `if i-1 >= 0` before the conditional.  This doesn't appear to actually cause the algorithm to ever break, but it is unsafe.

----------
messages: 104149
nosy: alex
severity: normal
status: open
title: Stringlib fastsearch can read beyond the front of an array

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:06:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Apr 2010 18:06:48 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272218808.18.0.326087674692.issue8530@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core
nosy: +flox
priority:  -> normal
stage:  -> needs patch
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/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:28:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 25 Apr 2010 18:28:41 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272220121.24.0.441135721796.issue8530@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I guess we don't have the same issue with the find() implementation?

 if (!STRINGLIB_BLOOM(mask, s[i+m]))


Because:
 * len(s) = n = (w + m)
 * the loop condition is (i <= w)
  ==> s[w+m] is beyond the array, but it is '\0' probably

Is it correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:29:39 2010
From: report at bugs.python.org (Alex)
Date: Sun, 25 Apr 2010 18:29:39 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272220179.87.0.616605347461.issue8530@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Yes, as the comment of the top of the file notes, reading to s[n] (where n == len(s)) is safe because strings are null padded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:35:01 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 25 Apr 2010 18:35:01 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272220501.88.0.790033016215.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

r80474: Replace AC_HELP_STRING with AS_HELP_STRING

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:35:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 25 Apr 2010 18:35:45 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272220545.16.0.199988330707.issue8530@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This patch should fix it.
Since there's no failure, I don't find any test to add.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17078/issue8530_rfind.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:36:36 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 25 Apr 2010 18:36:36 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272220596.05.0.877865216178.issue6085@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

The attached patch caches the result of FQDN lookup.

----------
keywords: +patch
Added file: http://bugs.python.org/file17079/base_http_server_fqdn_lag.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:40:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Apr 2010 18:40:08 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272220808.76.0.26328378944.issue8530@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't manage to trigger any crash on a Linux machine, so I think we'll live without a test.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:40:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Apr 2010 18:40:59 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272220859.99.0.351328966139.issue8530@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Of course your patch might slow down the loop, so perhaps you want to run some benchmarks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:41:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Apr 2010 18:41:13 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272220873.46.0.704496107941.issue8530@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 20:44:03 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 25 Apr 2010 18:44:03 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272221043.22.0.330791734772.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

r80475: s/AC_AIX/AC_USE_SYSTEM_EXTENSIONS/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sun Apr 25 21:23:04 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 25 Apr 2010 19:23:04 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1272223384.22.0.445826654604.issue8526@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I'm certainly using the API provided by msilib, but perhaps I'm using it badly.  Which API did you have in mind?  I'm using msilib directly, not through bdist_msi.

This seems like an artificial limitation to put on the Python library; the standard MSI spec supports 65K different cabs in a single installer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Apr 25 22:11:25 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Apr 2010 20:11:25 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272226285.87.0.311736316988.issue8523@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> tarek
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Sun Apr 25 22:12:53 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 25 Apr 2010 20:12:53 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272226373.15.0.428110490851.issue6085@psf.upfronthosting.co.za>


Santoso Wijaya <santa.ant at me.com> added the comment:

Doesn't that only cache the first remote client it encounters, though? Maybe a dictionary of caches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Sun Apr 25 22:26:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 25 Apr 2010 20:26:05 +0000
Subject: [issue8526] msilib doesn't support multiple CAB instances in same
	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1272227165.61.0.675208305881.issue8526@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still don't see the need to create multiple CABs. Just use the Directory class to add files, and that will automatically record them in the singleton CAB.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8526>
_______________________________________

From report at bugs.python.org  Sun Apr 25 22:47:01 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 25 Apr 2010 20:47:01 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272228421.29.0.306359796296.issue6085@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file17079/base_http_server_fqdn_lag.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Sun Apr 25 22:54:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Apr 2010 20:54:54 +0000
Subject: [issue6483] Modules are not deallocated correctly if m_size = -1
In-Reply-To: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>
Message-ID: <1272228894.25.0.139565889606.issue6483@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, in 2.x you didn't even have the choice. The dict of an extension module was always copied, becoming essentially immortal. In 3.x you can use an m_size>=0 so as to disable this behaviour.

----------
nosy: +pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6483>
_______________________________________

From report at bugs.python.org  Sun Apr 25 22:57:03 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Apr 2010 20:57:03 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272229023.49.0.474185638829.issue5099@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

New patch updated to at least r80476.

----------
Added file: http://bugs.python.org/file17080/subprocess_shutdown.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sun Apr 25 22:57:11 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Apr 2010 20:57:11 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272229031.79.0.360144490485.issue5099@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file16976/subprocess__del__.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:01:13 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 25 Apr 2010 21:01:13 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272229273.3.0.372201125555.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

r80478 converts all obsolete AC_TRY_* macros to AC_*_IFELSE, the outcome is ... nothing (but whitespace changes):

$ svn diff --diff-cmd diff -x -uEwB configure
Index: configure
===================================================================
--- configure	(Revision 80475)
+++ configure	(Arbeitskopie)
@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Revision: 80474 .
+# From configure.in Revision: 80475 .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.65 for python 3.2.
 #

running configure with the old and the new version shows no diffs (besides config.log).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:10:32 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 25 Apr 2010 21:10:32 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272229832.5.0.642501531302.issue6085@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Doesn't that only cache the first remote client it encounters, though? Maybe a dictionary of caches?

A BaseHTTPRequestHandler is instantiated every time a client connects, so there should be only one client per handler, no (the cache is an attribute of the handler, not the server) ?

----------
Added file: http://bugs.python.org/file17081/base_http_server_fqdn_lag.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:11:51 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 25 Apr 2010 21:11:51 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272229911.04.0.379999200196.issue8530@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Why add a bounds check if it can't be caused to fail. How about just a comment?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:14:29 2010
From: report at bugs.python.org (Alex)
Date: Sun, 25 Apr 2010 21:14:29 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272230069.66.0.531079310723.issue8530@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Well, the fact that it hasn't been shown to fail doesn't mean it can't fail.  It relies on reading undefined memory, which is usually bad ;).  However, since we're at i=0, regardless of what we add to the value it's going to end up terminating the loop, so I'm not sure if it can actually break in practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:20:19 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 25 Apr 2010 21:20:19 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272230419.05.0.891953781616.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

r80481: configure.in: Avoid autoconf warning: Assume C89 semantics that
RETSIGTYPE is always void (issue #8510).

Keep the definition, although the python code itself doesn't use it anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:24:30 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 25 Apr 2010 21:24:30 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272230670.51.0.90420659305.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

r80483: Makefile.pre.in (autoconf): Call autoconf/autoheader with -Wall to help the configure script to stay warning free.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:34:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Apr 2010 21:34:22 +0000
Subject: [issue8530] Stringlib fastsearch can read beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272231262.46.0.833217303342.issue8530@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It could read into an invalid page and segfault. It depends on specifics of the memory allocator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8530>
_______________________________________

From report at bugs.python.org  Sun Apr 25 23:44:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 25 Apr 2010 21:44:41 +0000
Subject: [issue8529] subclassing builtin class (str, unicode,
	list...) needs to override __getslice__
In-Reply-To: <1272214913.44.0.488253042315.issue8529@psf.upfronthosting.co.za>
Message-ID: <1272231881.48.0.477078503976.issue8529@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is because unicode implements __getslice__.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8529>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:17:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 25 Apr 2010 22:17:30 +0000
Subject: [issue8529] subclassing builtin class (str, unicode,
	list...) needs to override __getslice__
In-Reply-To: <1272214913.44.0.488253042315.issue8529@psf.upfronthosting.co.za>
Message-ID: <1272233850.46.0.446224671649.issue8529@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

OK, but it yields Python 3 DeprecationWarning in the subclass.
And there's no workaround to get rid of the deprecation. 

If it is the correct behaviour, maybe some words could be added about subclassing builtin types:
http://docs.python.org/reference/datamodel.html#additional-methods-for-emulation-of-sequence-types

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8529>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:18:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 25 Apr 2010 22:18:32 +0000
Subject: [issue8529] subclassing builtin class (str, unicode,
	list...) needs to override __getslice__
In-Reply-To: <1272214913.44.0.488253042315.issue8529@psf.upfronthosting.co.za>
Message-ID: <1272233912.19.0.222946155389.issue8529@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

OK, I said nothing, it is already in the doc.

:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8529>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:29:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Apr 2010 22:29:00 +0000
Subject: [issue2302] Uses of SocketServer.BaseServer.shutdown have a race
In-Reply-To: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za>
Message-ID: <1272234540.97.0.123881619751.issue2302@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed with a test in r80484 (trunk), r80486 (2.6), r80487 (py3k), r80491 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2302>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:34:16 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Apr 2010 22:34:16 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1272234856.5.0.513915822319.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

-Q now works like -3 by causing the DeprecationWarning silencing to be skipped. Committed in r80492.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:40:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 22:40:54 +0000
Subject: [issue8391] os.execvpe() doesn't support surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1272235253.99.0.122513477857.issue8391@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I blocked the fix in Python 3.1 because it's non trivial and I prefer to avoid complex changes in Python 3.1. But then I realized that Python 3.1 has two bugs about environment variables.

It uses sys.getfilesystemencoding()+surrogateecape to decode variables and sys.getdefaultencoding()+strict to encode variables: the encoding is different!

It counts the number of *characters* to allocate the *byte* string buffer and so non-ASCII values are truncated.

So I decided to backport the fix: r80494.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8391>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:42:47 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Apr 2010 22:42:47 +0000
Subject: [issue7288] Detect improper leading whitespace in C files for Vim
In-Reply-To: <1257716815.02.0.0950136651799.issue7288@psf.upfronthosting.co.za>
Message-ID: <1272235367.92.0.817411840477.issue7288@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7288>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:43:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 22:43:15 +0000
Subject: [issue8512] os.execv*e(): fix formatting of the environment variables
	(Python 3.1)
In-Reply-To: <1272062451.81.0.836509652271.issue8512@psf.upfronthosting.co.za>
Message-ID: <1272235395.3.0.870227534334.issue8512@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I choosed to backport #8391 fix to Python 3.1 (which is better) instead of writing a custom (shorter but incomplete) patch for Python 3.1: see msg104175.

(os_execve_env.patch doesn't work if LANG environment variable is not set)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8512>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:46:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 25 Apr 2010 22:46:02 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1272235562.03.0.0632173858339.issue7319@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This still hasn't been ported to py3.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:47:16 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Apr 2010 22:47:16 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1272235636.73.0.195732003853.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Making this a 3.2 issue now.

----------
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:51:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 22:51:34 +0000
Subject: [issue8531] libffi: selected processor does not support stfeqd/ldfd
	(ARMv7Thumb)
In-Reply-To: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>
Message-ID: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Errors on ARMv7Thumb Ubuntu 3.1 buildbot.

http://www.python.org/dev/buildbot/builders/ARMv7Thumb Ubuntu 3.1/builds/37/steps/compile/logs/stdio

creating build/temp.linux-armv7l-3.1-pydebug/libffi
checking build system type... armv7l-unknown-linux-gnu
checking host system type... armv7l-unknown-linux-gnu
checking target system type... armv7l-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
...
config.status: executing src commands
building '_ctypes' extension
creating build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi
creating build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src
creating build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/_ctypes.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/_ctypes.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callbacks.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callbacks.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callproc.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callproc.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/stgdict.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/stgdict.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/cfield.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/cfield.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/malloc_closure.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/malloc_closure.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/prep_cif.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.o
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S: Assembler messages:
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:203: Error: selected processor does not support `stfeqs f0,[r2]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:208: Error: selected processor does not support `stfeqd f0,[r2]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:283: Error: selected processor does not support `ldfs f0,[sp]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:286: Error: selected processor does not support `ldfd f0,[sp]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:289: Error: selected processor does not support `ldfd f0,[sp]'

----------
components: Library (Lib)
messages: 104179
nosy: haypo
severity: normal
status: open
title: libffi: selected processor does not support stfeqd/ldfd (ARMv7Thumb)
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8531>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:58:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 25 Apr 2010 22:58:36 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1272236316.3.0.663311105972.issue7319@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Brett, by the way, you had spurious changes in subprocess in your last commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Mon Apr 26 00:59:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 22:59:07 +0000
Subject: [issue8531] libffi: selected processor does not support stfeqd/ldfd
	(ARMv7Thumb)
In-Reply-To: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>
Message-ID: <1272236347.28.0.712326434592.issue8531@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 3.x doesn't have this issue because it uses libffi 3.0.9 and this version was fixed for ARMv7. Python 3.1 uses libffi 3.0.5.

The buildbot should install libffi 3.0.9 and set system libffi path to Python configure script.

... or fix test_ascii_formatd: skip the test if _ctypes module is missing.

See #8142 (libffi update to 3.0.9).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8531>
_______________________________________

From report at bugs.python.org  Mon Apr 26 01:09:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 23:09:41 +0000
Subject: [issue8531] test_ascii_formatd fails if ctypes module is missing
In-Reply-To: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>
Message-ID: <1272236981.87.0.176714021028.issue8531@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is specific to Python 3.1: test_ascii_formatd starts with "PyOS_ascii_formatd is deprecated and not called from anywhere in Python itself. So this module is the only place it gets tested. Test that it works, and test that it's deprecated."

I prefer to fix the test than the buildbot because _ctypes compilation may fail on different CPU/OS, ctypes should not be mandatory.

Fixed by r80495.

----------
status: open -> closed
title: libffi: selected processor does not support stfeqd/ldfd (ARMv7Thumb) -> test_ascii_formatd fails if ctypes module is missing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8531>
_______________________________________

From report at bugs.python.org  Mon Apr 26 01:12:59 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Apr 2010 23:12:59 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1272237179.42.0.949679766229.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm tired of svn. I swear I made sure I didn't list that file in what was changed.

Anyway, it's been reverted in r80496.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Mon Apr 26 01:18:16 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 25 Apr 2010 23:18:16 +0000
Subject: [issue8531] test_ascii_formatd fails if ctypes module is missing
In-Reply-To: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>
Message-ID: <1272237496.77.0.722178386793.issue8531@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

libffi 3.0.9 is installed. the buildbot master needs to pass --with-system-libffi to configure.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8531>
_______________________________________

From report at bugs.python.org  Mon Apr 26 01:20:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 23:20:25 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272237625.97.0.550801747243.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update path: rename fs_encode/fs_decode to fsencode/fsdecode.

----------
title: Create fs_encode() and fs_decode() functions in os.path -> Create fsencode() and fsdecode() functions in os.path
Added file: http://bugs.python.org/file17082/os_path_fs_encode_decode-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 01:20:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 23:20:36 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272237636.72.0.807955867963.issue8514@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17061/os_path_fs_encode_decode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 01:20:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 23:20:57 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272237657.99.0.346939892001.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, "Update path": I mean "Update patch" ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 01:25:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 23:25:51 +0000
Subject: [issue8531] test_ascii_formatd fails if ctypes module is missing
In-Reply-To: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>
Message-ID: <1272237951.87.0.0657768475573.issue8531@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> libffi 3.0.9 is installed. the buildbot master needs to pass --with-system-libffi to configure.

I fixed this issue by fixing my initial problem: test_ascii_formatd failure. Would you like to contact buildbot master owner to change the configuration? (are you the owner?) I don't want to work on this anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8531>
_______________________________________

From report at bugs.python.org  Mon Apr 26 02:04:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 00:04:34 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1272240274.69.0.389445377539.issue6462@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Is the following error related to this issue?

http://www.python.org/dev/buildbot/builders/x86 Windows7 2.6/builds/256/steps/test/logs/stdio

test test_bsddb3 failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.6.bolen-windows7\build\lib\bsddb\test\test_lock.py", line 127, in test03_lock_timeout
    self.assertTrue((end_time-start_time) >= 0.0999)
AssertionError

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6462>
_______________________________________

From report at bugs.python.org  Mon Apr 26 02:30:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 00:30:26 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1272241826.5.0.196897965282.issue4171@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What happens if you remove the call to settimeout()?
Also, it would be nice if you could try with the latest py3k checkout. There's a couple of fixes for do_handshake there (including timeout issues).

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Mon Apr 26 02:43:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 00:43:28 +0000
Subject: [issue7672] _ssl module overwrites existing thread safety callbacks
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1272242608.4.0.118360094168.issue7672@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think asking Python extensions to be safe in the face of brutal DLL unloading is wise. I don't think any of our C extensions tries to respect such an use case. We could still try to support the use case of some application registering its own callbacks before importing _ssl.

As for the patch, it looks wrong since CRYPTO_get_locking_callback() is compared to NULL a second time after the callback has been set to something non-NULL.

----------
nosy: +pitrou
priority:  -> normal
title: _ssl module causes segfault -> _ssl module overwrites existing thread safety callbacks
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7672>
_______________________________________

From report at bugs.python.org  Mon Apr 26 03:30:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Apr 2010 01:30:26 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272245426.77.0.988349321449.issue8523@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If solution 1 is acceptable in the general case, then I think a better fix  would look like this:

try:
    names = os.listdir(path)
except os.error, err:
    onerror(os.listdir, path, sys.exc_info())
    return

That is, this is another case in which we can't continue even if onerror returns.  However, onerror is free to correct the problem and then call rmtree.  (The danger, of course, is infinite recursion, but I don't think it is our responsibility to protect the author of an onerror handler from that potential mistake.)

By analogy to the other place rmtree returns after an onerror call, the above fix does fix a real bug, regardless of the disposition of the feature request, since currently if onerror returns we get a name error.

----------
components: +Library (Lib) -Extension Modules
keywords: +easy
nosy: +r.david.murray
priority:  -> low
stage:  -> unit test needed
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Mon Apr 26 05:41:42 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 03:41:42 +0000
Subject: [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

The attached patch makes two simple refinements to the new GIL implemented in Python 3.2.   Each is briefly described below.

1. Changed mechanism for thread time expiration

In the current implementation, threads perform a timed-wait on a condition variable.  If time expires and no thread switches have occurred, the currently running thread is forced to drop the GIL.

In the patch, timeouts are now performed by a special "GIL monitor" thread.  This thread runs independently of Python and simply handles time expiration.  Basically, it records the number of thread switches, sleeps for a specified interval (5ms), and then looks at the number of thread switches again.  If no switches occurred, it forces the currently running thread to drop the GIL.

With this monitor thread, it is no longer necessary to perform any timed condition variable waits.  This approach has a few subtle benefits.  First, threads no longer sit in a wait/timeout cycle when trying to get the GIL (so, there is less overhead).   Second, you get FIFO scheduling of threads.  When time expires, the thread that has been waiting the longest on the condition variable runs next.  Generally, you want this.

2. A very simple two-level priority mechanism

A new attribute 'cpu_bound' is added to the PyThreadState structure.  If a thread is ever forced to drop the GIL, this attribute is simply set True (1).  If a thread gives up the GIL voluntarily, it is set back to False (0).  This attribute is used to set up simple scheduling (described next).

There are now two separate condition variables (gil_cpu_cond) and (gil_io_cond) that separate waiting threads according to their cpu_bound attribute setting.  CPU-bound threads wait on gil_cpu_cond whereas I/O-bound threads wait on gil_io_cond. 

Using the two condition variables, the following scheduling rules are enforced:

   - If there are any waiting I/O bound threads, they are always signaled first, before any CPU-bound threads.
   - If an I/O bound thread wants the GIL, but a CPU-bound thread is running, the CPU-bound thread is immediately forced to drop the GIL.
   - If a CPU-bound thread wants the GIL, but another CPU-bound thread is running, the running thread is immediately forced to drop the GIL if its time period has already expired.

Results
-------
This patch gives excellent results for both the ccbench test and all of my previous I/O bound tests.  Here is the output:

== CPython 3.2a0.0 (py3k:80470:80497M) ==
== i386 Darwin on 'i386' ==

--- Throughput ---

Pi calculation (Python)

threads=1: 871 iterations/s.
threads=2: 844 ( 96 %)
threads=3: 838 ( 96 %)
threads=4: 826 ( 94 %)

regular expression (C)

threads=1: 367 iterations/s.
threads=2: 345 ( 94 %)
threads=3: 339 ( 92 %)
threads=4: 327 ( 89 %)

bz2 compression (C)

threads=1: 384 iterations/s.
threads=2: 728 ( 189 %)
threads=3: 695 ( 180 %)
threads=4: 707 ( 184 %)

--- Latency ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 0 ms. (std dev: 0 ms.)
CPU threads=2: 1 ms. (std dev: 2 ms.)
CPU threads=3: 0 ms. (std dev: 1 ms.)
CPU threads=4: 0 ms. (std dev: 1 ms.)

Background CPU task: regular expression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 2 ms. (std dev: 1 ms.)
CPU threads=2: 1 ms. (std dev: 1 ms.)
CPU threads=3: 1 ms. (std dev: 1 ms.)
CPU threads=4: 2 ms. (std dev: 1 ms.)

Background CPU task: bz2 compression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 0 ms. (std dev: 2 ms.)
CPU threads=2: 2 ms. (std dev: 3 ms.)
CPU threads=3: 0 ms. (std dev: 1 ms.)
CPU threads=4: 0 ms. (std dev: 1 ms.)

--- I/O bandwidth ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 5850.9 packets/s.
CPU threads=1: 5246.8 ( 89 %)
CPU threads=2: 4228.9 ( 72 %)
CPU threads=3: 4222.8 ( 72 %)
CPU threads=4: 2959.5 ( 50 %)

Particular attention should be given to tests involving I/O performance.  In particular, here are the results of the I/O bandwidth test using the unmodified GIL:

--- I/O bandwidth ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 6007.1 packets/s.
CPU threads=1: 189.0 ( 3 %)
CPU threads=2: 19.7 ( 0 %)
CPU threads=3: 19.7 ( 0 %)
CPU threads=4: 5.1 ( 0 %)

Other Benefits
--------------
This patch does not involve any complicated libraries, platform specific functionality, low-level lock twiddling, or mathematically complex priority scheduling algorithms.  Emphasize: The code is simple.

Negative Aspects
----------------
This modification might introduce a starvation effect where CPU-bound threads never get to run if there is an extremely heavy load of I/O-bound threads competing for the GIL.

Is starvation a real problem or a theoretical problem?  Hard to say. Would need study.

----------
components: Interpreter Core
files: gil.patch
keywords: patch
messages: 104192
nosy: dabeaz
severity: normal
status: open
title: Refinements to Python 3 New GIL
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17083/gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8532>
_______________________________________

From report at bugs.python.org  Mon Apr 26 05:58:37 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 03:58:37 +0000
Subject: [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272254317.31.0.864631920011.issue8532@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Can't decide whether this should be attached to Issue 7946 or not.
I will also post it there.  (Feel free to close this issue if you want to keep 7946 alive).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8532>
_______________________________________

From report at bugs.python.org  Mon Apr 26 06:13:30 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 04:13:30 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272255210.74.0.106498514844.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

The attached patch makes two simple refinements to the new GIL implemented in Python 3.2.   Each is briefly described below.

1. Changed mechanism for thread time expiration

In the current implementation, threads perform a timed-wait on a condition variable.  If time expires and no thread switches have occurred, the currently running thread is forced to drop the GIL.

In the patch, timeouts are now performed by a special "GIL monitor" thread.  This thread runs independently of Python and simply handles time expiration.  Basically, it records the number of thread switches, sleeps for a specified interval (5ms), and then looks at the number of thread switches again.  If no switches occurred, it forces the currently running thread to drop the GIL.

With this monitor thread, it is no longer necessary to perform any timed condition variable waits.  This approach has a few subtle benefits.  First, threads no longer sit in a wait/timeout cycle when trying to get the GIL (so, there is less overhead).   Second, you get FIFO scheduling of threads.  When time expires, the thread that has been waiting the longest on the condition variable runs next.  Generally, you want this.

2. A very simple two-level priority mechanism

A new attribute 'cpu_bound' is added to the PyThreadState structure.  If a thread is ever forced to drop the GIL, this attribute is simply set True (1).  If a thread gives up the GIL voluntarily, it is set back to False (0).  This attribute is used to set up simple scheduling (described next).

There are now two separate condition variables (gil_cpu_cond) and (gil_io_cond) that separate waiting threads according to their cpu_bound attribute setting.  CPU-bound threads wait on gil_cpu_cond whereas I/O-bound threads wait on gil_io_cond. 

Using the two condition variables, the following scheduling rules are enforced:

   - If there are any waiting I/O bound threads, they are always signaled first, before any CPU-bound threads.
   - If an I/O bound thread wants the GIL, but a CPU-bound thread is running, the CPU-bound thread is immediately forced to drop the GIL.
   - If a CPU-bound thread wants the GIL, but another CPU-bound thread is running, the running thread is immediately forced to drop the GIL if its time period has already expired.

Results
-------
This patch gives excellent results for both the ccbench test and all of my previous I/O bound tests.  Here is the output:

== CPython 3.2a0.0 (py3k:80470:80497M) ==
== i386 Darwin on 'i386' ==

--- Throughput ---

Pi calculation (Python)

threads=1: 871 iterations/s.
threads=2: 844 ( 96 %)
threads=3: 838 ( 96 %)
threads=4: 826 ( 94 %)

regular expression (C)

threads=1: 367 iterations/s.
threads=2: 345 ( 94 %)
threads=3: 339 ( 92 %)
threads=4: 327 ( 89 %)

bz2 compression (C)

threads=1: 384 iterations/s.
threads=2: 728 ( 189 %)
threads=3: 695 ( 180 %)
threads=4: 707 ( 184 %)

--- Latency ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 0 ms. (std dev: 0 ms.)
CPU threads=2: 1 ms. (std dev: 2 ms.)
CPU threads=3: 0 ms. (std dev: 1 ms.)
CPU threads=4: 0 ms. (std dev: 1 ms.)

Background CPU task: regular expression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 2 ms. (std dev: 1 ms.)
CPU threads=2: 1 ms. (std dev: 1 ms.)
CPU threads=3: 1 ms. (std dev: 1 ms.)
CPU threads=4: 2 ms. (std dev: 1 ms.)

Background CPU task: bz2 compression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 0 ms. (std dev: 2 ms.)
CPU threads=2: 2 ms. (std dev: 3 ms.)
CPU threads=3: 0 ms. (std dev: 1 ms.)
CPU threads=4: 0 ms. (std dev: 1 ms.)

--- I/O bandwidth ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 5850.9 packets/s.
CPU threads=1: 5246.8 ( 89 %)
CPU threads=2: 4228.9 ( 72 %)
CPU threads=3: 4222.8 ( 72 %)
CPU threads=4: 2959.5 ( 50 %)

Particular attention should be given to tests involving I/O performance.  In particular, here are the results of the I/O bandwidth test using the unmodified GIL:

--- I/O bandwidth ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 6007.1 packets/s.
CPU threads=1: 189.0 ( 3 %)
CPU threads=2: 19.7 ( 0 %)
CPU threads=3: 19.7 ( 0 %)
CPU threads=4: 5.1 ( 0 %)

Other Benefits
--------------
This patch does not involve any complicated libraries, platform specific functionality, low-level lock twiddling, or mathematically complex priority scheduling algorithms.  Emphasize: The code is simple.

Negative Aspects
----------------
This modification might introduce a starvation effect where CPU-bound threads never get to run if there is an extremely heavy load of I/O-bound threads competing for the GIL.

Comparison to BFS
-----------------
Still need to test. Would be curious.

----------
Added file: http://bugs.python.org/file17084/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 06:14:28 2010
From: report at bugs.python.org (Alex)
Date: Mon, 26 Apr 2010 04:14:28 +0000
Subject: [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272255268.14.0.999619800178.issue8532@psf.upfronthosting.co.za>


Changes by Alex <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8532>
_______________________________________

From report at bugs.python.org  Mon Apr 26 06:17:49 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 04:17:49 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272255469.82.0.0478538287741.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

One comment on that patch I just submitted. Basically, it's an attempt to make an extremely simple tweak to the GIL that fixes most of the problems discussed here in an extremely simple manner.  I don't have any special religious attachment to it though.  Would love to see a BFS comparison.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 06:18:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 26 Apr 2010 04:18:12 +0000
Subject: [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272255492.13.0.949084394852.issue8532@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +nirai
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8532>
_______________________________________

From report at bugs.python.org  Mon Apr 26 06:52:54 2010
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Mon, 26 Apr 2010 04:52:54 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1272241826.5.0.196897965282.issue4171@psf.upfronthosting.co.za>
Message-ID: <4BD51C17.40801@targeted.org>


Dmitry Dvoinikov <dmitry at targeted.org> added the comment:

The problem does not reproduce in 3.1.1 nor in 3.1.2
(either x86 or x64).

Antoine Pitrou ?????:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> What happens if you remove the call to settimeout()?
> Also, it would be nice if you could try with the latest py3k checkout. There's a couple of fixes for do_handshake there (including timeout issues).
> 
> ----------
> nosy: +pitrou
> priority:  -> normal
> versions: +Python 3.1, Python 3.2 -Python 3.0
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4171>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Mon Apr 26 06:56:08 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 04:56:08 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272257768.26.0.104299835364.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Here is the result of running the writes.py test with the patch I submitted.   This is on OS-X.

bash-3.2$ ./python.exe writes.py
t1 2.83990693092 0
t2 3.27937912941 0
t1 5.54346394539 1
t2 6.68237304688 1
t1 8.9648039341 2
t2 9.60041999817 2
t1 12.1856160164 3
t2 12.5866689682 3
t1 15.3869640827 4
t2 15.7042851448 4
t1 18.4115200043 5
t2 18.5771169662 5
t2 21.4922711849 6
t1 21.6835460663 6
t2 24.6117911339 7
t1 24.9126679897 7
t1 27.1683580875 8
t2 28.2728791237 8
t1 29.4513950348 9
t1 32.2438161373 10
t2 32.5283250809 9
t1 34.8905010223 11
t2 36.0952250957 10
t1 38.109760046 12
t2 39.3465380669 11
t1 41.5758800507 13
t2 42.587772131 12
t1 45.1536290646 14
t2 45.8339021206 13
t1 48.6495029926 15
t2 49.1581180096 14
t1 51.5414950848 16
t2 52.6768190861 15
t1 54.818582058 17
t2 56.1163961887 16
t1 58.1549630165 18
t2 59.6944830418 17
t1 61.4515309334 19
t2 62.7685520649 18
t1 64.3223180771 20
t2 65.8158640862 19
65.8578810692

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 07:23:28 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 26 Apr 2010 05:23:28 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272259408.32.0.32282709464.issue7946@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Nice dabeaz.

One potential concern with "dabeaz_gil.patch 2010-04-25 21:13" is that it appears to always leave the gil_monitor thread running.  This is bad on mobile/embedded platforms where waking up at regular intervals prevents advanced sleep states and wastes power/battery.  (practical example: the OLPC project has run into this issue in other code in the past)

Could this be modified so that gil_monitor stops looping (blocks) so long as there are only IO bound Python threads running or while no python thread owns the GIL?

In that situation a multithreaded python process that has either reverted to one thread or has all threads blocked in IO would be truly idle rather than leaving the gil_monitor polling.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 07:26:11 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 26 Apr 2010 05:26:11 +0000
Subject: [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272259571.32.0.485609038385.issue8532@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

since the other discussion is ongoing on issue7946 i posted my comment there.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8532>
_______________________________________

From report at bugs.python.org  Mon Apr 26 07:29:33 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 26 Apr 2010 05:29:33 +0000
Subject: [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272259773.89.0.56533763919.issue8532@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8532>
_______________________________________

From report at bugs.python.org  Mon Apr 26 07:31:00 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 26 Apr 2010 05:31:00 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272259860.48.0.398285978247.issue8514@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i'm +0.7 on fsencode/fsdecode going into os.path.

My bikeshed 0.7?  They're also useful for dealing with environment variables which are not strictly filesystem (fs) related but also suffer from the same issue requiring surrogate escape.  But other than just calling these os.encode and os.decode I don't have any brilliant alternate naming suggestions.  thoughts?  I could easily live with os.path.fsencode/fsdecode, I just wanted to point the other use out.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:53:18 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:53:18 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272271998.1.0.854974926632.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Added file: http://bugs.python.org/file17085/timemodule-gmtime-r265.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:53:38 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:53:38 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272018.8.0.594739463258.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Added file: http://bugs.python.org/file17086/timemodule-gmtime-r27b1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:53:53 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:53:53 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272033.46.0.310061603342.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Added file: http://bugs.python.org/file17087/timemodule-gmtime-r312.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:54:11 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:54:11 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272051.44.0.158755750317.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Added file: http://bugs.python.org/file17088/timemodule-gmtime-3-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:54:29 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:54:29 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272069.91.0.531266220024.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Removed file: http://bugs.python.org/file16351/timemodule-gmtime-2-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:54:34 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:54:34 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272074.03.0.927712473691.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Removed file: http://bugs.python.org/file16352/timemodule-gmtime-2-r27a3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:54:37 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:54:37 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272077.55.0.564580861407.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Removed file: http://bugs.python.org/file16353/timemodule-gmtime-2-r311.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:54:42 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:54:42 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272082.52.0.890074093713.issue6280@psf.upfronthosting.co.za>


Changes by Francesco Del Degan <f.deldegan at ngi.it>:


Removed file: http://bugs.python.org/file16354/timemodule-gmtime-2-r264.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 10:54:59 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 08:54:59 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272272099.92.0.257567332126.issue6280@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

Fixed typos, new patches added

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 11:13:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 09:13:38 +0000
Subject: [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272273218.38.0.768957723627.issue8532@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Convoy effect with I/O bound threads and New GIL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8532>
_______________________________________

From report at bugs.python.org  Mon Apr 26 11:22:46 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 26 Apr 2010 09:22:46 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272273766.84.0.637958196032.issue8493@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> That's what I thought at first too. But the user's sockets were set to blocking.

That's one broken networking stack...

> In fact, I think it's a little silly that OS X raises the error rather than just saying that 0 bytes were sent (which is what I suppose that other OSes do).

"Normal" OS just block inside the send() call whenever socket buffers are full (unless there're set to non-blocking). So you can resume sending as soon as buffer space is available, and you don't have to resort to this send()/fail/sleep/re-send() scheme... 

> But I think it's also not ideal that Python's socket.sendall() can't be used with confidence under OS X because it can fail under pretty normal circumstances.

Agreed, but it's really a OS X issue here. How would you circumvent this problem anyway ? Add a timeout option to sendall() as a hint to how much we should wait before retrying when errno 35 is returned ? It would be really hacky...

Maybe the user could try increasing SO_SNDBUF, but this won't necessarily solve his problem...

@exarkun: ideas on this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 11:36:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 09:36:28 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1272255210.74.0.106498514844.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272274719.3539.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Dave,

> In the current implementation, threads perform a timed-wait on a
> condition variable.  If time expires and no thread switches have
> occurred, the currently running thread is forced to drop the GIL.

A problem, as far as I can see, is that these timeout sleeps run
periodically, regardless of the actual times at which thread switching
takes place. I'm not sure it's really an issue but it's a bit of a
departure from the "ideal" behaviour of the switching interval.

> A new attribute 'cpu_bound' is added to the PyThreadState structure.
> If a thread is ever forced to drop the GIL, this attribute is simply
> set True (1).  If a thread gives up the GIL voluntarily, it is set
> back to False (0).  This attribute is used to set up simple scheduling
> (described next).

Ok, so it's not very different, at least in principle, from what
gilinter.patch does, right?
(and actually, the benchmark results look very similar)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 11:48:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 09:48:48 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272275328.66.0.51017590771.issue8493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's what I thought at first too. But the user's sockets were set to 
> blocking.

If you set a timeout on a socket, it is really non-blocking internally (from the OS' point of view). So perhaps this is what you are witnessing.

By the way, rather than sleeping a fixed amount of time before retrying, you could probably use select() on the socket.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 11:54:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 09:54:21 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272275661.14.0.886569600837.issue8493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What is the mnemonic corresponding to errno 35 under OS X?
(under Linux I get EDEADLOCK, which probably isn't the right one)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 11:56:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 09:56:42 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1272275802.34.0.951031799315.issue4171@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so I think we can close the issue then. Thank you!

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:00:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 10:00:42 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272276042.35.0.886899888631.issue6085@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, DNS resolution should be disabled by default, as in most HTTP servers probably.

----------
nosy: +pitrou
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:37:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 10:37:04 +0000
Subject: [issue8513] subprocess: support bytes program name
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272278224.28.0.561343125728.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch changes:
 * os._execvpe(): support bytes type for the file argument (program name)
 * os.get_exec_path(): support bytes type for the PATH environment variable
 * Popen._execute_child(): decode the executable name before encoding the arguments (if the program name is not an absolute path)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:37:45 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 26 Apr 2010 10:37:45 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272278265.13.0.264125466675.issue6085@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

And for this specific request, it fdqn is looked up only for "logging" to sys.stderr. Either removing the fqdn call or just caching per connection it as the patch does is both fine. I doubt if someone is relying this logging anywhere in the code. This is useful only when BaseHTTPServer is started in the command like as a standalone HTTP server.

What shall we do for this? remove the fqdn or cache it once and use it. Either is fine. And there is not testing code present (or required too - as this is a cli invocation scenario).

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:38:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 10:38:00 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272278280.43.0.421714122935.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> They're also useful for dealing with environment variables 
> which are not strictly filesystem (fs) related but also suffer 
> from the same issue requiring surrogate escape.

Yes, Python3 decodes environment variables using sys.getfilesystemencoding()+surrogateescape. And since my last fix on os.execve(), subprocess (and os.execv(p)e) uses also surrogateescape to encode environment variables.

And yes again, I also patched os.getenv() to decode bytes name to unicode using sys.getfilesystemencoding()+surrogateescape.

> But other than just calling these os.encode and os.decode

*fs*encode() and *fs*decode() is a reference to the encoding: sys.get*filesystem*encoding().

> I just wanted to point the other use out

See also issue #8513.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:38:39 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 26 Apr 2010 10:38:39 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272278319.18.0.138778230776.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I believe I have the first function implemented.  See the attached patch for that code and feel free to review.

----------
keywords: +patch
nosy:  -haypo
Added file: http://bugs.python.org/file17089/logexception.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:43:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 10:43:14 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If a test fails, regrtest writes the backtrace to sys.stdout. If the backtrace contains a non-ASCII characters, it's encoded using sys.stdout encoding.

In some conditions, sys.stdout is unable to encode some or all non-ASCII characters. Eg. if there is no locale set (empty environment or at least empty LANG variable value), sys.stdout.encoding="ascii".

If regrtest fails to display a test output (error backtrace), regrtest exits directly (don't execute next tests).

I propose to use backslashreplace error handler in sys.stdout, as done for sys.stderr to avoid this annoying issue.

Attached patch (for py3k) replace sys.stdout by a new file using backslashreplace, just before executing the tests.

I don't know if the issue concerns also Python2.

----------
files: regrtest_stdout_backslashreplace.patch
keywords: patch
messages: 104212
nosy: haypo
severity: normal
status: open
title: regrtest: use backslashreplace error handler for stdout
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17090/regrtest_stdout_backslashreplace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:43:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 10:43:20 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272278600.66.0.975181918955.issue8533@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Tests, Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:45:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 10:45:56 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1272278265.13.0.264125466675.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272278887.3539.10.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> And for this specific request, it fdqn is looked up only for "logging"
> to sys.stderr. Either removing the fqdn call or just caching per
> connection it as the patch does is both fine. I doubt if someone is
> relying this logging anywhere in the code. This is useful only when
> BaseHTTPServer is started in the command like as a standalone HTTP
> server.

I think we should totally remove the call to fqdn. The common practice
with HTTP servers is to log numeric IPs and, if desired, let a batch log
analysis process (such as awstats) deal with DNS resolution and caching.

> And there is not testing code present (or required too - as this is a
> cli invocation scenario).

What do you mean? BaseHTTPRequestHandler is tested in test_httpservers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:49:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 10:49:22 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272278962.99.0.0792943418506.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh! In Python3, ntpath.expanduser() supports bytes path and uses sys.getfilesystemencoding() to encode an unicode environment variable to a byte string.

Should we remove bytes path support in ntpath.expanduser(), or support bytes in ntpath.fsencode()/.fsdecode()?

(sys.getfilesystemencoding() is "mbcs" on Windows)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:52:15 2010
From: report at bugs.python.org (simon)
Date: Mon, 26 Apr 2010 10:52:15 +0000
Subject: [issue8534] multiprocessing not working from egg
In-Reply-To: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za>
Message-ID: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za>


New submission from simon <ext-simon.steiner at nokia.com>:

testmultiprocessing.py:

def main():
    import multiprocessing

    proc = multiprocessing.Process(target=runhi)
    proc.start()
    proc.join()
    
def runhi():
    print 'hi'
    
if __name__ == "__main__":
    main()

testmultiprocessing.py is inside myegg.egg

set PYTHONPATH=myegg.egg

python -m testmultiprocessing

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\multiprocessing\forking.py", line 341, in main
    prepare(preparation_data)
  File "C:\Python26\lib\multiprocessing\forking.py", line 450, in prepare
    file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named testmultiprocessing

----------
components: Library (Lib)
messages: 104215
nosy: simonsteiner
severity: normal
status: open
title: multiprocessing not working from egg
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8534>
_______________________________________

From report at bugs.python.org  Mon Apr 26 12:57:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 26 Apr 2010 10:57:44 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1272278887.3539.10.camel@localhost>
Message-ID: <20100426105733.GC9423@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Mon, Apr 26, 2010 at 10:45:56AM +0000, Antoine Pitrou wrote:

> What do you mean? BaseHTTPRequestHandler is tested in test_httpservers.

I meant specifically for that function which is logging to sys.stderr.
No return values, state changes and no tests present in test_httpservers.
Seems to me the cli invokation scenario of the BaseHTTPServer module.

Only other place where fqdn look up happens is HTTPServer.server_bind
and in the setting of server_name, if any code is relying on it could
break.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:00:43 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 26 Apr 2010 11:00:43 +0000
Subject: [issue8535] passing optimization flags to the linker required for
	builds with gcc -flto
In-Reply-To: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>
Message-ID: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

Building with -flto (GCC 4.5.0) requires passing the very same optimization flags to the linker (lto1) as well. The attached patch just does this.  Tested on Linux only, I don't know what will/could break on on other systems/compilers.

Tested with a static build (--disable-shared) on x86_64. pybench results improve by 5% when building with 4.5.0 instead of 4.4.3, and by another 5% by building with -flto.

----------
components: Build
files: make-lto.diff
keywords: needs review, patch
messages: 104217
nosy: doko
severity: normal
status: open
title: passing optimization flags to the linker required for builds with gcc -flto
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17091/make-lto.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8535>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:06:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 26 Apr 2010 11:06:47 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272278962.99.0.0792943418506.issue8514@psf.upfronthosting.co.za>
Message-ID: <4BD573C4.7060104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Oh! In Python3, ntpath.expanduser() supports bytes path and uses sys.getfilesystemencoding() to encode an unicode environment variable to a byte string.
> 
> Should we remove bytes path support in ntpath.expanduser(), or support bytes in ntpath.fsencode()/.fsdecode()?
> 
> (sys.getfilesystemencoding() is "mbcs" on Windows)

I don't see what environment variables have to do with the file
system.

Those are two different contexts and thus also require two different
approaches to the problem.

Command line parameters are another area, where an encoding
comes into play, but this again does not have to coincide with the
file system encoding.

Also note that "mbcs" on Windows is a meta-encoding. The
implementation of that encoding depends on the locale used by
the Windows user. It's just a coincidence that this may actually
work for the environment variables on Windows as well, but there's
no guarantee.

On Unix, you often have the case that the environment variables
use mixed encodings, e.g. the CGI interface is a good example
where this happens per definition. The CGI environment can
includes file system paths, data encoded in Latin-1 (or some
other encoding), etc.

See http://www.ietf.org/rfc/rfc3875.txt for details.

Environment variables are also commonly used to interface
to external programs from daemons, e.g. postfix, procmail
and others use environment variables to communicate with
external helper applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:08:47 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 11:08:47 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272280127.79.0.530665801616.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Greg,

I like the idea of the monitor suspending if no thread owns the GIL.  Let me work on that.   Good point on embedded systems.

Antoine, 

Yes, the gil monitor is completely independent and simply ticks along every 5 ms.   A worst case scenario is that an I/O bound thread is scheduled shortly after the 5ms tick and then becomes CPU-bound afterwards.  In that case, the monitor might let it run up to about 10ms before switching it.  Hard to say if it's a real problem though---the normal timeslice on many systems is 10 ms so it doesn't seem out of line.  

As for the priority part, this patch should have similar behavior to the glinter patch except for very subtle differences in thread scheduling due to the use of the GIL monitor.  For instance, since threads never time out on the condition variable anymore, they tend to cycle execution in a purely round-robin fashion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:16:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 26 Apr 2010 11:16:19 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <1272211278.62.0.936715621529.issue8514@psf.upfronthosting.co.za>
Message-ID: <4BD575FF.6010203@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> Please follow the naming convention used in os.path. The functions
>> would have to be called os.path.fsencode() and os.path.fsdecode().
> 
> Ok
> 
>> Other than that, I'm +0 on the patch: the sys.filesystemencoding
>> logic doesn't really work well in practice - on Unix and BSD
>> platforms, there's no such thing as a single system-wide file
>> system
> 
> Today, most POSIX system uses utf8 by default for all partitions.  If you mount an USB key, CD-Rom or network shared directory with the wrong options, you may get filenames in a different encoding. But this issue is not about fixing your OS configuration, but helping the most common case: a system using the same encoding everywhere (for the whole file system).
>
> You are still free to use directly the native OS type (unicode on Windows, bytes on other OS), ie. don't use fsencode()/fsdecode().

Right, but if you start using those new API in standard lib
functions, programmers no longer have that choice.

In real life applications, you do run into these problems quite
often, so instead of coding against an ideal world, we have to be
aware of the problems and make it possible for the standard lib modules
to deal with them.

> Python3 prefers unicode, eg. print expects an unicode string, not a byte string. I mean it's more pratical to use unicode everywhere in Python, and so fsencode()/fsdecode() can be really useful on POSIX systems.

Sure, but forcing UnicodeDecodeErrors upon Python3 programmers is
not a good idea. Please keep that in mind.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------
title: Create fsencode() and fsdecode() functions in os.path -> Create fs_encode() and fs_decode() functions in os.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:22:44 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 26 Apr 2010 11:22:44 +0000
Subject: [issue8535] passing optimization flags to the linker required
	for	builds with gcc -flto
In-Reply-To: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>
Message-ID: <4BD57781.40408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Matthias Klose wrote:
> 
> New submission from Matthias Klose <doko at debian.org>:
> 
> Building with -flto (GCC 4.5.0) requires passing the very same optimization flags to the linker (lto1) as well. The attached patch just does this.  Tested on Linux only, I don't know what will/could break on on other systems/compilers.

On some systems, this may very well break, due to
configruations where LDFLAGS and CFLAGS contain
the same options.

While this is normally not much of a problem, some compilers may complain
about this.

E.g. GCC on Mac OS X complains about duplicate use of the -sysroot
option.

It's probably better to just pass OPT to the linker instead.

----------
nosy: +lemburg
title: passing optimization flags to the linker required for builds with gcc -flto -> passing optimization flags to the linker required for	builds with gcc -flto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8535>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:27:19 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 26 Apr 2010 11:27:19 +0000
Subject: [issue8535] passing optimization flags to the linker required
	for	builds with gcc -flto
In-Reply-To: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>
Message-ID: <1272281239.09.0.0884151930706.issue8535@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> It's probably better to just pass OPT to the linker instead.

not enough, because -fno-strict-aliasing might be passed in BASE_CFLAGS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8535>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:29:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 11:29:35 +0000
Subject: [issue8534] multiprocessing not working from egg
In-Reply-To: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za>
Message-ID: <1272281375.53.0.184649670711.issue8534@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller
priority:  -> low
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8534>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:30:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 11:30:38 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272281438.2.0.843478688883.issue8533@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A better resolution IMO would be to output tracebacks on stderr instead.

----------
nosy: +flox, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Mon Apr 26 13:44:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 11:44:56 +0000
Subject: [issue8514] Create fs_encode() and fs_decode() functions in os.path
In-Reply-To: <4BD575FF.6010203@egenix.com>
Message-ID: <201004261344.46779.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> In real life applications, you do run into these problems quite
> often

Yes, I'm agree 100% with you :-)

> > Python3 prefers unicode, eg. print expects an unicode string, not a byte
> > string. I mean it's more pratical to use unicode everywhere in Python,
> > and so fsencode()/fsdecode() can be really useful on POSIX systems.
> 
> Sure, but forcing UnicodeDecodeErrors upon Python3 programmers is
> not a good idea. Please keep that in mind.

I proposed to reject bytes on Windows because Martin (who knows Windows better 
than me) decided to *not* support byte string on Windows. Windows native API 
uses unicode, and conversion from bytes and unicode on Windows using "mbcs" is 
not reliable (it depends on the locale, and it may loose some informations).

http://mail.python.org/pipermail/python-dev/2010-April/099556.html

Reject byte string on Windows is just a suggestion. To support byte strings on 
Windows, each Python function written in C should be fixed to use the ANSI 
version instead of the Wide version (eg. CreateProcessA instead of 
CreateProcessW) if it gets byte arguments. The code would become twice bigger, 
and it introduces new issues: which function should be choosen if there are 
two arguments, one is a byte string, and the other an unicode string? 
_subprocess.CreateProcess has 9 arguments...

Since unicode is a superset of MBCS and MBCS has subtle bugs, it's preferable 
to use (force) unicode.

--

But on POSIX, it's the opposite: I'm doing my best to support byte string 
everywhere (filenames, environment variables, etc.). See the dependency list 
of my "meta" issue #8242.

The first goal of fsencode() is to accept byte strings on POSIX systems. 
Maybe, I didn't explained it correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:00:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 12:00:17 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <4BD573C4.7060104@egenix.com>
Message-ID: <201004261400.08237.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le lundi 26 avril 2010 13:06:48, vous avez ?crit :
> I don't see what environment variables have to do with the file
> system.

A POSIX system only offers *one* function about the encoding: 
nl_langinfo(CODESET) and Python3 uses it for the filenames, environment 
variables and the command line arguments.

Are you suggesting that Python3 should support a encoding different for 
environment variables and the file system? How would the user configure it?

About filenames, Python3 choose the encoding using the locale, but the user 
cannot change it: sys.setfilesystemencoding() is removed by the site module.

> Also note that "mbcs" on Windows is a meta-encoding. The
> implementation of that encoding depends on the locale used by
> the Windows user. It's just a coincidence that this may actually
> work for the environment variables on Windows as well, but there's
> no guarantee.

os.getenv() should raise a TypeError on Windows if key is a byte string.

os.getenv() didn't support byte string. I patched it to support byte string 
(issue #8391, r80421). But I don't like my fix because we should reject 
support byte string *on Windows*. I would like to factorize the type check for 
all operations on the file system and environment variables in 
fsencode()/fsdecode().

> On Unix, you often have the case that the environment variables
> use mixed encodings, e.g. the CGI interface is a good example
> where this happens per definition. The CGI environment can
> includes file system paths, data encoded in Latin-1 (or some
> other encoding), etc.

Since Python3 choosed to store environment variables as unicode string on 
Windows and POSIX, in this specific case you should reconvert the value to 
byte strings using fsencode() and then manipulate byte strings. Because 
Python3 uses surrogateescape, you will get the original byte string values.

My patch should help both cases: people using unicode objects and people using 
the native OS type (bytes on POSIX). As written in my previous message, you 
can still use byte strings if you want. My patch doesn't change that (on POSIX 
systems).

----------
title: Create fs_encode() and fs_decode() functions in os.path -> Create fsencode() and fsdecode() functions in os.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:00:21 2010
From: report at bugs.python.org (simon)
Date: Mon, 26 Apr 2010 12:00:21 +0000
Subject: [issue8534] multiprocessing not working from egg
In-Reply-To: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za>
Message-ID: <1272283221.82.0.143640745363.issue8534@psf.upfronthosting.co.za>


Changes by simon <ext-simon.steiner at nokia.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17092/forking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8534>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:29:47 2010
From: report at bugs.python.org (Tim Pietzcker)
Date: Mon, 26 Apr 2010 12:29:47 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1272284987.64.0.736986833165.issue3262@psf.upfronthosting.co.za>


Tim Pietzcker <tim.pietzcker at web.de> added the comment:

Sorry to revive this dormant (?) topic - has anybody brought this any further? This "feature" has tripped me up a few times, and I would be all for adding a flag to enable the "split on zero-size matches" behavior, but I myself am not competent enough to code a patch.

----------
nosy: +pietzcker
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:32:53 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Apr 2010 12:32:53 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272285173.58.0.459039796939.issue8493@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> What is the mnemonic corresponding to errno 35 under OS X?

EAGAIN

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:44:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 12:44:19 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272285859.2.0.572821455183.issue8493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Matthew, can you confirm whether the socket had a timeout set to it?
(either through settimeout() or setglobaltimeout())

I think this is a bug in Python's socket module.

recv()-like functions are written so as to first call select() before actually receiving data, but send()-like functions aren't. I guess blocking sends are quite rare thanks to in-kernel buffering, but we should do the correct thing and use the same logic for send() as we do for recv().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:47:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 12:47:24 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272286044.93.0.811857583754.issue8533@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> A better resolution IMO would be to output tracebacks on stderr instead.

Yeah, that sounds easier and safer. Attached patch writes the tracebacks to stderr.

I don't remember how to reproduce this issue :-/ I guess that stdout/stderr encoding should be ASCII (eg. LANG="") and the traceback (eg. the error message) should contain a non-ASCII character.

----------
Added file: http://bugs.python.org/file17093/regrtest_traceback_stderr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:48:03 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 26 Apr 2010 12:48:03 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272286083.97.0.565883285977.issue8493@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> What is the mnemonic corresponding to errno 35 under OS X?
(under Linux I get EDEADLOCK, which probably isn't the right one)

>From the first message: "errno 35 (resource temporarily unavailable)". It's actually EAGAIN on Linux (which makes sense on a non-blocking socket).

> By the way, rather than sleeping a fixed amount of time before retrying, you could probably use select() on the socket.

select doesn't mean much for sockets you want to send to, because it will report the socket in the writable set as soon as there's one byte free in the send buffer, so you can very well block (or fail in that case) even when select reports the socket as ready for writting.

> If you set a timeout on a socket, it is really non-blocking internally (from the OS' point of view). So perhaps this is what you are witnessing.

Yes. Maybe it would help to have the sample code ?

Googling a little bit gave this: http://lists.freebsd.org/pipermail/freebsd-hackers/2004-January/005369.html

> > I have written a test program,
> > http://www.infres.enst.fr/~pook/send/server.c, that shows that send does
> > not block on FreeBSD.  It does with Linux and Solaris.
> 
> Do you know what the behaviour of Net- and/or OpenBSD is?

NetBSD is the same as FreeBSD.  I have not tested OpenBSD.
MacOS X is similiar to FreeBSD in that send doesn't block, howver
the send does not give an error: the packet is just thrown away.

So there seems to be an issue on some systems when you run out of socket buffers, and since select doesn't seem to work either, I guess the only option is this sleep-a-little-hoping-the-buffer-gets-drained approach.

> I think this is a bug in Python's socket module.
> recv()-like functions are written so as to first call select() before actually receiving data, but send()-like functions aren't. I guess blocking sends are quite rare thanks to in-kernel buffering, but we should do the correct thing and use the same logic for send() as we do for recv().

When I look at trunk, I see this:

do {
		timeout = internal_select(s, 1);
		n = -1;
		if (timeout)
			break;
#ifdef __VMS
		n = sendsegmented(s->sock_fd, buf, len, flags);
#else
		n = send(s->sock_fd, buf, len, flags);
#endif
		if (n < 0) {
#ifdef EINTR
			/* We must handle EINTR here as there is no way for
			 * the caller to know how much was sent otherwise.  */
			if (errno == EINTR) {
				/* Run signal handlers.  If an exception was
				 * raised, abort and leave this socket in
				 * an unknown state. */
				if (PyErr_CheckSignals())
					return NULL;
				continue;
			}
#endif
			break;
		}
		buf += n;
		len -= n;
	} while (len > 0);

we call internal_select(s, 1) (1 for writting) before sending.
But as I said, it's not reliable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:49:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 12:49:23 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272286163.6.0.25419953856.issue8533@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Write to stderr instead of stdout might change buildbot output order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Mon Apr 26 14:58:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 12:58:17 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1272286083.97.0.565883285977.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272286830.3539.25.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

[...]
> we call internal_select(s, 1) (1 for writting) before sending.

Oh, sorry, you are right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 15:19:03 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 13:19:03 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272287943.66.0.649232521787.issue7946@psf.upfronthosting.co.za>


Changes by David Beazley <dave at dabeaz.com>:


Removed file: http://bugs.python.org/file17084/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 15:21:18 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 13:21:18 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272288078.48.0.0264512214087.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I've updated the GIL patch to reflect concerns about the monitor thread running forever.  This version has a suspension mechanism where the monitor goes to sleep if nothing is going on for awhile.  It gets resumed if threads try to acquire the GIL, but timeout for some reason.

----------
Added file: http://bugs.python.org/file17094/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 15:31:16 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 13:31:16 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272288676.57.0.140012794498.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I've also attached a new file schedtest.py that illustrates a subtle difference between having the GIL monitor thread and not having the monitor.

Without the monitor, every thread is responsible for its own scheduling.  If you have a lot of threads running, you may have a lot of threads all performing a timed wait and then waking up only to find that the GIL is locked and that they have to go back to waiting.  One side effect is that certain threads have a tendency to starve.

For example, if you run the schedtest.py with the original GIL, you get a trace where three CPU-bound threads run like this:

Thread-3 16632
Thread-2 16517
Thread-1 31669
Thread-2 16610
Thread-1 16256
Thread-2 16445
Thread-1 16643
Thread-2 16331
Thread-1 16494
Thread-3 16399
Thread-1 17090
Thread-1 20860
Thread-3 16306
Thread-1 19684
Thread-3 16258
Thread-1 16669
Thread-3 16515
Thread-1 16381
Thread-3 16600
Thread-1 16477
Thread-3 16507
Thread-1 16740
Thread-3 16626
Thread-1 16564
Thread-3 15954
Thread-2 16727
...

You will observe that Threads 1 and 2 alternate, but Thread 3 starves.  Then at some point, Threads 1 and 3 alternate, but Thread 2 starves. 

By having a separate GIL monitor, threads are no longer responsible for making scheduling decisions concerning timeouts.  Instead, the monitor is what times out and yanks threads off the GIL.  If you run the same test with the GIL monitor, you get scheduling like this:

Thread-1 33278
Thread-2 32278
Thread-3 31981
Thread-1 33760
Thread-2 32385
Thread-3 32019
Thread-1 32700
Thread-2 32085
Thread-3 32248
Thread-1 31630
Thread-2 32200
Thread-3 32054
Thread-1 32721
Thread-2 32659
Thread-3 34150

Threads nicely cycle round-robin.  There also appears to be about half as much thread switching (for reasons I don't quite understand).

----------
Added file: http://bugs.python.org/file17095/schedtest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Apr 26 15:35:15 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Apr 2010 13:35:15 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272288915.06.0.64720543812.issue8493@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> But as I said, it's not reliable.

I don't see any evidence in support of this statement.  Did you notice that the FreeBSD thread you referenced is:

  * 6 years old
  * about UDP

It's not obvious to me that it's actually relevant here.

> Maybe it would help to have the sample code ?

This seems to be an excellent idea, though.  Without actually knowing what program triggers this behavior, any change is just a wild guess and probably a waste of time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 16:05:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 14:05:02 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272290702.63.0.969392838371.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 3 of the patch: fix also os.getenv() which rejects now bytes on Windows (one of the goals of this issue).

----------
Added file: http://bugs.python.org/file17096/os_path_fs_encode_decode-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 16:05:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 14:05:07 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272290707.93.0.108996167256.issue8514@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17082/os_path_fs_encode_decode-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Mon Apr 26 16:40:13 2010
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 26 Apr 2010 14:40:13 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1272292813.81.0.465932723741.issue4120@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I'm not sure this issue is really done.  The current state works fine, but there is one problem remaining:

There are Python extensions that seem to need a manifest pointing to the MSVC runtime libs:  dlls that start in-process com servers, like pythoncom.dll (from the PyWin32 extension), and also _ctypes.pyd plays this role.

First question: Open a new issue, or discuss it in this one (and repoen it)?

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Mon Apr 26 16:44:44 2010
From: report at bugs.python.org (egaudry)
Date: Mon, 26 Apr 2010 14:44:44 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1272292813.81.0.465932723741.issue4120@psf.upfronthosting.co.za>
Message-ID: <4BD5A6F1.1090609@fft.be>


egaudry <eg at fft.be> added the comment:

Hi Thomas,

I think we should open a new issue (child from issue 4120), just to make 
sure the whole thing remains understandable.

Regards,
Eloi

Thomas Heller wrote:
> Thomas Heller <theller at ctypes.org> added the comment:
>
> I'm not sure this issue is really done.  The current state works fine, but there is one problem remaining:
>
> There are Python extensions that seem to need a manifest pointing to the MSVC runtime libs:  dlls that start in-process com servers, like pythoncom.dll (from the PyWin32 extension), and also _ctypes.pyd plays this role.
>
> First question: Open a new issue, or discuss it in this one (and repoen it)?
>
> ----------
> nosy: +theller
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4120>
> _______________________________________
>   

-- 

Eloi Gaudry

Free Field Technologies
Axis Park Louvain-la-Neuve
Rue Emile Francqui, 1
B-1435 Mont-Saint Guibert
BELGIUM

Company Phone: +32 10 487 959
Company Fax:   +32 10 454 626

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Mon Apr 26 17:20:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Apr 2010 15:20:20 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272295220.32.0.776907378341.issue5099@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello


Brett?s patch contains strange-looking docstrings. Since they are for private methods, they could be comments instead.

The patch looks otherwise good to me.

Does anyone have an idead on how to not write a __del__ method at all, according to Gabriel?s first comment?


Regards

----------
nosy: +merwok
title: subprocess.POpen.__del__() AttributeError (os module == None!) -> subprocess.Popen.__del__ causes AttributeError (os module == None)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 17:22:38 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 26 Apr 2010 15:22:38 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272295358.91.0.610259764452.issue8493@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> I don't see any evidence in support of this statement. 

>From Microfost Windows' documentation:

"The parameter writefds identifies the sockets that are to be checked for writability. If a socket is processing a connect call (nonblocking), a socket is writeable if the connection establishment successfully completes. If the socket is not processing a connect call, writability means a send, sendto, or WSASendto are guaranteed to succeed. However, they can block on a blocking socket if the len parameter exceeds the amount of outgoing system buffer space available. It is not specified how long these guarantees can be assumed to be valid, particularly in a multithreaded environment."

For the Linux kernel, a few years ago a socket would be returned as writable if it had a fixed amount of send socket buffer queue available, so if you send more than is available at that time, you're either going to block, or get an error (now the threshold is 1/2 of the used buffer space, but this doesn't change the problem).
That's why I said it's not reliable.

> Did you notice that the FreeBSD thread you referenced is:

  * 6 years old
  * about UDP

So ? 

> It's not obvious to me that it's actually relevant here.

I'm not saying that it's the source of the problem, I'm just saying that there's a record of send() calls failing on lack of socket buffers, on blocking sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 17:47:27 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Mon, 26 Apr 2010 15:47:27 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272296847.14.0.619835472931.issue8493@psf.upfronthosting.co.za>


Matthew Cowles <mdcowles at users.sourceforge.net> added the comment:

[Replying to various posts]

[neologix]
> That's one broken networking stack...

I'm not disagreeing, but you'd have to take that up with Apple.

> How would you circumvent this problem anyway ?

The code has to go around again in the case of an incomplete send. I imagine that it could go around again if the return value was -1 and errno was 35. Doing that in Python fixed the problem for the user.

[pitrou]
> Matthew, can you confirm whether the socket had a timeout set to it?
> (either through settimeout() or setglobaltimeout())

I double- and triple-checked that the user wasn't setting a timeout. The problem came up in the context of the ftplib module and a look at the code (it was Python 2.6.2) suggests that that module doesn't set a timeout unless you ask it to.

[neologix]
> Maybe it would help to have the sample code ?

I'm sorry but I can't quite tell which code you mean here. The original user's traceback ended with:

File "/Library/Frameworks/Python.framework/Versions/
        2.6/lib/python2.6/ftplib.py",
line 452, in storbinary
    conn.sendall(buf)
    File "<string>", line 1, in sendall
error: [Errno 35] Resource temporarily unavailable

If there's something else that would be useful and I can provide it, I'd be glad to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 17:48:09 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Apr 2010 15:48:09 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272296889.45.0.48918955101.issue8493@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

None of that has much relevance when the socket is in *non-blocking* mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 17:48:50 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Apr 2010 15:48:50 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272296930.4.0.180066586857.issue8493@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> If there's something else that would be useful and I can provide it, I'd be glad to.

A minimal example which reproduces the behavior. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 17:59:04 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 26 Apr 2010 15:59:04 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1272297544.26.0.285544166489.issue4120@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

I mentioned the problem with pythoncom.dll and suggested a solution in issue7833.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Mon Apr 26 18:01:12 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 26 Apr 2010 16:01:12 +0000
Subject: [issue8527] [PEP 3147] compileall.compile_dir() called multiple times
	creates empty __pycache__/__pycache__ subdirectories
In-Reply-To: <1272159236.82.0.290282900197.issue8527@psf.upfronthosting.co.za>
Message-ID: <1272297672.71.0.474611965643.issue8527@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for the patch!  I added a test and committed your patch in r80497.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8527>
_______________________________________

From report at bugs.python.org  Mon Apr 26 18:01:47 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 26 Apr 2010 16:01:47 +0000
Subject: [issue8527] [PEP 3147] compileall.compile_dir() called multiple times
	creates empty __pycache__/__pycache__ subdirectories
In-Reply-To: <1272159236.82.0.290282900197.issue8527@psf.upfronthosting.co.za>
Message-ID: <1272297707.25.0.08820438735.issue8527@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

er, make that r80501

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8527>
_______________________________________

From report at bugs.python.org  Mon Apr 26 18:27:19 2010
From: report at bugs.python.org (rubenlm)
Date: Mon, 26 Apr 2010 16:27:19 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272299239.42.0.485647391757.issue8523@psf.upfronthosting.co.za>


rubenlm <ruben at libhertz.com> added the comment:

Your solution sounds fine to me.

Currently we don't get a NameError because "names" is set to [] before the "try". What happens is that the "for" is skipped and later rmdir fails with "directory not empty".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Mon Apr 26 18:42:59 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 16:42:59 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1272300179.48.0.905732153808.issue3928@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file16536/mknod-solaris_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Apr 26 18:45:50 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 16:45:50 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1272300350.12.0.134248545436.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, Review. Roumen?.

I plan to commit this to 2.7, 2.6, 3.1 and 3.2, if you agree.

----------
Added file: http://bugs.python.org/file17097/mknod-solaris_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Apr 26 18:55:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 16:55:27 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1272300927.26.0.479932706478.issue3928@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Jesus, this looks ok, have you checked the changes work fine under e.g. Linux?
I don't think DEC Unix is supported anymore, actually I'm not sure anyone still uses it.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:04:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Apr 2010 17:04:12 +0000
Subject: [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1272301452.71.0.56818179947.issue8325@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed (with both call formats) to trunk in r80503 and py3k in r80505.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8325>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:11:10 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 17:11:10 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1272301870.44.0.164833118579.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Pitrou, the code configures correctly in Linux.

Reading PEP11, I don't see the procedure to propose a platform for deprecation. Just mailing python-dev?

I will delay the patch committing a couple of days, just in case somebody else want to comment.

Thanks for the review, Pitrou.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:22:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 17:22:19 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1272301870.44.0.164833118579.issue3928@psf.upfronthosting.co.za>
Message-ID: <1272302673.3436.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Reading PEP11, I don't see the procedure to propose a platform for
> deprecation. Just mailing python-dev?

Yes.

> Thanks for the review, Pitrou.

You can call me Antoine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:22:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Apr 2010 17:22:46 +0000
Subject: [issue7583] Improve explanation of tab expansion in doctests
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1272302566.15.0.356184495822.issue7583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The problem is that it would be equally reasonable for someone to want to put real tab characters in the output section (which results in strange looking doctest text) or to put expanded spaces in the doctest output section based on the assumption that output starts in the column under the first > of the >>> and that doctest will expand the tabs in the output it receives from the executed test using a tabstop of 8.  Neither of these is a good solution (the first gives you messed up looking doctests, the second means the output you document isn't really the output the test gives).  The second solution would also mean a significant rewrite of the doctest processing loop.  So the best course, since doctests are *primarily* about documentation, is to allow tabs in the output only with whitespace normalization.  (If you really want to test for the presence of tabs in the output, as opposed to just creating documentation, you can capture the output and test it using string comparison.)

Personally I think the 'too bad' language in the docs is not really appropriate, so if you can think of a succinct way to document the above, I'll see about getting it in to the docs.

----------
components: +Documentation -Library (Lib)
stage: patch review -> needs patch
title: doctest should normalize tabs when comparing output -> Improve explanation of tab expansion in doctests
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7583>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:23:11 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 17:23:11 +0000
Subject: [issue8536] Support new features of ZLIB 1.2.5
In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>
Message-ID: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Zlib 1.2.5 adds new features like "inflateReset2()", "inflateMark()", or "Z_TREES" flags.

We should support them if we have zlib 1.2.5 installed.

I think the patch is trivial, beside testing that we have a recent zlib version.

----------
keywords: easy
messages: 104254
nosy: jcea
severity: normal
status: open
title: Support new features of ZLIB 1.2.5
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8536>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:28:53 2010
From: report at bugs.python.org (bugs-python@vendor.thewrittenword.com)
Date: Mon, 26 Apr 2010 17:28:53 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1272302933.88.0.136972621352.issue6006@psf.upfronthosting.co.za>


bugs-python at vendor.thewrittenword.com <bugs-python at vendor.thewrittenword.com> added the comment:

Python is using the wrong ffi code, it should be using ffi_darwin.c

----------
keywords: +patch
nosy: +bugs-python at vendor.thewrittenword.com
Added file: http://bugs.python.org/file17098/pyffi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6006>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:30:37 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 17:30:37 +0000
Subject: [issue8536] Support new features of ZLIB 1.2.5
In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>
Message-ID: <1272303037.0.0.667071542258.issue8536@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Relevant links:

http://www.zlib.net/
http://www.zlib.net/manual.html


My mistake: these new features were added in zlib 1.2.4, not 1.2.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8536>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:31:01 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 17:31:01 +0000
Subject: [issue8536] Support new features of ZLIB 1.2.4
In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>
Message-ID: <1272303061.34.0.623957086202.issue8536@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
title: Support new features of ZLIB 1.2.5 -> Support new features of ZLIB 1.2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8536>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:31:48 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 26 Apr 2010 17:31:48 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1272303108.11.0.495579688452.issue3262@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

You could try the regex module mentioned in issue 2636.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:36:35 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:36:35 +0000
Subject: [issue8537] Add ConfigureAction to argparse
In-Reply-To: <1272303394.25.0.68455397409.issue8537@psf.upfronthosting.co.za>
Message-ID: <1272303394.25.0.68455397409.issue8537@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

>From a python-dev email from Neal Becker, copied here so it won't get lost.
----------------------------
steven.bethard at gmail.com made a very nice module for me to enhance argparse called argparse_bool.py, which contains ConfigureAction.  This will allow a boolean value to be set very like the gnu configure style:

--foo
--with-foo
--without-foo
--no-foo
--foo=yes
--foo=no

I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library.

----------
components: Library (Lib)
files: argparse_bool.py
messages: 104258
nosy: bethard, eric.smith
severity: normal
status: open
title: Add ConfigureAction to argparse
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17099/argparse_bool.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8537>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:38:07 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:38:07 +0000
Subject: [issue8538] Add ConfigureAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

>From a python-dev email from Neal Becker, copied here so it won't get lost.
----------------------------
steven.bethard at gmail.com made a very nice module for me to enhance argparse called argparse_bool.py, which contains ConfigureAction.  This will allow a boolean value to be set very like the gnu configure style:

--foo
--with-foo
--without-foo
--no-foo
--foo=yes
--foo=no

I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library.

----------
components: Library (Lib)
files: argparse_bool.py
messages: 104259
nosy: bethard, eric.smith
severity: normal
status: open
title: Add ConfigureAction to argparse
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17100/argparse_bool.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:38:12 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:38:12 +0000
Subject: [issue8539] Add ConfigureAction to argparse
In-Reply-To: <1272303491.8.0.482178644573.issue8539@psf.upfronthosting.co.za>
Message-ID: <1272303491.8.0.482178644573.issue8539@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

>From a python-dev email from Neal Becker, copied here so it won't get lost.
----------------------------
steven.bethard at gmail.com made a very nice module for me to enhance argparse called argparse_bool.py, which contains ConfigureAction.  This will allow a boolean value to be set very like the gnu configure style:

--foo
--with-foo
--without-foo
--no-foo
--foo=yes
--foo=no

I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library.

----------
components: Library (Lib)
files: argparse_bool.py
messages: 104260
nosy: bethard, eric.smith
severity: normal
status: open
title: Add ConfigureAction to argparse
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17101/argparse_bool.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8539>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:38:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:38:44 +0000
Subject: [issue8539] Add ConfigureAction to argparse
In-Reply-To: <1272303491.8.0.482178644573.issue8539@psf.upfronthosting.co.za>
Message-ID: <1272303524.95.0.456276493105.issue8539@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8539>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:38:56 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 26 Apr 2010 17:38:56 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1272303536.09.0.143500444746.issue7904@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

The fix for this bug breaks any code which worked with non-standard
schemes in 2.6.4 (by working around the issue).  This kind of backward
incompatibility should be called out prominently in NEWS.txt (assuming
that such a fix is considered appropriate in a third-dot release).

----------
nosy: +tseaver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7904>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:43:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Apr 2010 17:43:43 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272303823.49.0.489601728056.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

It is too late to get new features in 2.x.

Francesco,

Please double-check timemodule-gmtime-r312.diff, it does not seem to reflect your reported changes. ('-' vs '--' typo is still there)

There is no need to submit multiple patches.  A patch for py3k branch should be enough.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:45:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Apr 2010 17:45:31 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The Context class in the decimal module has a hidden _clamp attribute, that controls whether to clamp values with large exponents.  (Clamping a Decimal value involves adding extra significant zeros to decrease its exponent, while not altering the numeric value;  it's sometimes necessary to get the exponent within a legal range).

I think we should consider making this attribute public (documenting it, having it appear in the __str__ or __repr__ of a Context), for a couple of reasons:

(1) It's necessary for full compliance with the specification:  Python's default behaviour is actually non-compliant with the spec;  it's only after doing getcontext()._clamp = 1 that it complies.

(2) Clamping is necessary for modeling the standard formats described in IEEE 754-2008 (decimal64, decimal128), etc.  These formats are coming into use in other languages (gcc already supports them and C201x may well include them).  To be able to communicate effectively with other languages using these formats, it would be useful to expose Context._clamp.

----------
components: Library (Lib)
messages: 104263
nosy: facundobatista, mark.dickinson, rhettinger, skrah
severity: normal
stage: unit test needed
status: open
title: Make Context._clamp public in decimal module
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Mon Apr 26 19:46:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:46:46 +0000
Subject: [issue8537] Add ConfigureAction to argparse
In-Reply-To: <1272303394.25.0.68455397409.issue8537@psf.upfronthosting.co.za>
Message-ID: <1272304006.66.0.702300751293.issue8537@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Sorry for the dupes. My ISP keeps disconnecting, but apparently it was able to create this issue 3 times for me.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8537>
_______________________________________

From report at bugs.python.org  Mon Apr 26 20:00:06 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 18:00:06 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1272304806.74.0.25998064758.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Informal europeans! :-).

Hi, Antoine, I am Jes?s (sunny Spain!).

Deprecation request mailed to python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Apr 26 20:00:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Apr 2010 18:00:11 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272304811.27.0.00387279324659.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Some more comments:

- Documentation needs a "versionadded" entry.

- A fate of calendar.timegm() needs to be decided.  If the decision is to deprecate it, deprecation warning need to be added to calendar module and docs updated accordingly.   Given that as implemented, time.timegm() is not a drop-in replacement for calendar.timegm(), deprecation may not be appropriate, it which case the difference between the two functions should probably be explained in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 20:11:36 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 18:11:36 +0000
Subject: [issue7844] Add -3 warning for absolute imports.
In-Reply-To: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za>
Message-ID: <1272305496.36.0.721549964271.issue7844@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7844>
_______________________________________

From report at bugs.python.org  Mon Apr 26 20:52:52 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 18:52:52 +0000
Subject: [issue8538] Add ConfigureAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1272307972.04.0.898263516742.issue8538@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Mon Apr 26 21:14:06 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 26 Apr 2010 19:14:06 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272309246.54.0.949216242909.issue6085@psf.upfronthosting.co.za>


Santoso Wijaya <santa.ant at me.com> added the comment:

Please correct my understanding if I am mistaken, but from skimming through the source code, it seems that a new BaseHTTPRequestHandler is instantiated per request. If a caching mechanism is to be adopted as per the patch, wouldn't it be forgotten when a new request from the same client arrives in the future?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Mon Apr 26 21:31:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Apr 2010 19:31:16 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1272292813.81.0.465932723741.issue4120@psf.upfronthosting.co.za>
Message-ID: <4BD5EA00.40605@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> First question: Open a new issue, or discuss it in this one (and repoen it)?

Please open a new issue. AFAICT, the original issues request (do not
embed manifests in pyd files) is now implemented fully. Feel free to
leave a link to the new issue here, but please start over describing the
problem you are seeing, and in what version you are seeing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Mon Apr 26 21:56:18 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 26 Apr 2010 19:56:18 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1272311778.24.0.223320391827.issue6280@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

I thinks that isn't a so easy decision to take.

And there are some other issues, imho:

1. timegm function is not specified by any standard (POSIX). The portable way (setting TZ, calling mktime, restore TZ) is a pure hack (could not work in future multithreaded environments).
2. if we want to strictly follow the time.h definition from POSIX standards, the timegm function should be kept away from time module (as now).
3. timegm seems to have some issues on mingw32. 
4. Solaris doesn't come with the timegm function out-of-the-box.

We could give up at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:11:16 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Apr 2010 20:11:16 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272312676.04.0.102450140278.issue5099@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Did you run the patch on a Windows machine, Eric?

As for Gabriel's comment about not using a __del__ method, it's a general rule of thumb, not something you have to do. __del__ methods exist for those times when you REALLY need them, but otherwise should be avoided when possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:12:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Apr 2010 20:12:18 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272312738.74.0.144860616279.issue8540@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:22:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 20:22:22 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272313342.39.0.237096545424.issue5099@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm -1 on Brett's patch: keep a reference to the required functions in the function arguments is ugly to me. The process should be destroyed before unloading the modules. I don't know how (or even if it's possible or not :-)), but I think that Brett's patch is the wrong solution to the problem.

Eg. Can't we use atexit.register() to destroy the processes at exit?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:30:00 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Mon, 26 Apr 2010 20:30:00 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272313800.69.0.392402727922.issue8493@psf.upfronthosting.co.za>


Matthew Cowles <mdcowles at users.sourceforge.net> added the comment:

> A minimal example which reproduces the behavior. :)

Unfortunately the problem wasn't mine originally. I'm just the guy on python-help who happened to figure out the answer. But if someone can get me access to an FTP server on the other end of a slow link, I'd be glad to do what I can <half-wink>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:31:10 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Apr 2010 20:31:10 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272313870.42.0.55106249925.issue5099@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I was just following the style already set in __del__ for storing a reference to sys (that and I didn't feel like having to explicitly store all of those references in the __init__ or at the class level just above the methods).

As for using atexit, it's possible that could be the proper solution, it just requires someone coding it up before we hit 2.7rc1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:32:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Apr 2010 20:32:02 +0000
Subject: [issue8541] Test issue
In-Reply-To: <1272313922.39.0.094018844125.issue8541@psf.upfronthosting.co.za>
Message-ID: <1272313922.39.0.094018844125.issue8541@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

What is the default priority?

----------
messages: 104274
nosy: loewis
severity: normal
status: open
title: Test issue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8541>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:33:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Apr 2010 20:33:01 +0000
Subject: [issue8541] Test issue
In-Reply-To: <1272313922.39.0.094018844125.issue8541@psf.upfronthosting.co.za>
Message-ID: <1272313981.85.0.356479876647.issue8541@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8541>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:33:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Apr 2010 20:33:20 +0000
Subject: [issue8542] Another test issue
In-Reply-To: <1272314000.64.0.308936581064.issue8542@psf.upfronthosting.co.za>
Message-ID: <1272314000.64.0.308936581064.issue8542@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

What is the priority now?

----------
messages: 104275
nosy: loewis
priority: normal
severity: normal
status: open
title: Another test issue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8542>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:33:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Apr 2010 20:33:55 +0000
Subject: [issue8542] Another test issue
In-Reply-To: <1272314000.64.0.308936581064.issue8542@psf.upfronthosting.co.za>
Message-ID: <1272314035.78.0.266682058264.issue8542@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8542>
_______________________________________

From report at bugs.python.org  Mon Apr 26 22:36:26 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Apr 2010 20:36:26 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272314186.51.0.363311211964.issue8493@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> But if someone can get me access to an FTP server on the other end of a slow link, I'd be glad to do what I can <half-wink>.

It's easy to get a slow FTP server.  Twisted's FTP support lets you do all kinds of customization; making a server that doesn't read very fast (or at all!) would be a snap.

Ultimately, I don't think you should actually need an FTP server to reproduce this, though.  A discard server should work just as well.

> Unfortunately the problem wasn't mine originally. I'm just the guy on python-help who happened to figure out the answer.

Perhaps you can encourage the OP to take a look at this issue and post some code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Mon Apr 26 23:15:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Apr 2010 21:15:08 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1272312676.04.0.102450140278.issue5099@psf.upfronthosting.co.za>
Message-ID: <4BD60258.7080203@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t own a Windows machine. I just read the code, sorry if that was
not helpful.

Regarding quick fix vs. right fix, nothing prevents us from using
Brett?s fix now and take some time to try the atexit way later.

acute-accent-ly yours, ?ric

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 23:28:51 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 26 Apr 2010 21:28:51 +0000
Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes
	lag
In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za>
Message-ID: <1272317331.16.0.700480955087.issue6085@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

@santa4nt: You're correct, the cache is retained only from within the same handler: the other solution would be to keep the cache at the server level, but then you'd have to deal with the cache size (you don't want it to grow forever), and it seems a bit overkill. I just kept the FQDN resolution because the code seemed to do it on purpose, but I agree that if nothing relies on this behaviour, it might be as simple to remove the resolution altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6085>
_______________________________________

From report at bugs.python.org  Mon Apr 26 23:30:46 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 26 Apr 2010 21:30:46 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1272300350.12.0.134248545436.issue3928@psf.upfronthosting.co.za>
Message-ID: <4BD60602.1060805@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Sorry Jes?s, right now I cannot test new patch it but It looks goodand I 
expect first test to succeed so that second won't be tested as result 
OCF_XXX to be defined. If there is no spelling error it is fine.

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Apr 26 23:42:43 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Apr 2010 21:42:43 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272318163.16.0.474985168608.issue5099@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Code reviews are always helpful, ?ric. I just wanted since that is what is preventing me from committing.

And you are right that I can commit my change now and we can fix it after the fact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 23:43:02 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Apr 2010 21:43:02 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272318182.68.0.709784291455.issue5099@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 23:43:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Apr 2010 21:43:13 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1272318193.92.0.46607806903.issue5099@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Apr 26 23:47:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 21:47:53 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272158462.96.0.727764730478.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272318602.3436.10.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, at the risk of stating the obvious, perhaps the dup() thing
> should be eliminated.  The justification for it seems less than clear,
> and apparently it causes some problems.

I've just found another problem while investigating the cause of some
sporadic Windows failures:
http://www.python.org/dev/buildbot/builders/x86%20XP-4%
203.1/builds/718/steps/test/logs/stdio

I've reproduced it on an XP VM and the explanation is that, sometimes,
just after a dup() of a socket, calling getpeername() on the child
socket fails (while getpeername() on the parent succeeds). It seems very
timing-sensitive: if I insert enough code after the dup(), the call to
getpeername() succeeds.

I will fix the buildbot issue by using a different logic (simply, call
getpeername() on the parent rather than the child), but this seems to
confirms that dup() may not be a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Tue Apr 27 00:18:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Apr 2010 22:18:27 +0000
Subject: [issue5774] _winreg.OpenKey() is documented with keyword arguments,
	but doesn't take them
In-Reply-To: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
Message-ID: <1272320307.83.0.919561909294.issue5774@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

See also #8350

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5774>
_______________________________________

From report at bugs.python.org  Tue Apr 27 00:20:30 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 26 Apr 2010 22:20:30 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1272107962.59.0.0190773757884.issue7384@psf.upfronthosting.co.za>
Message-ID: <4BD611AA.6020007@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Yes , I  understand .
For the protocol did gcc on FreeBSD warn if library order is -lncursesw 
  -lreadline  ?
Forget for

Also I'm not able to write C test case similar to python msg103231 by 
Mark Dickinson that fail on system where readline library is not linked 
to ncurses. Always program work and didn't code dump(=bus error) 
nevertheless order of ncurses (with w and without w suffix) and readline 
libraries.

So if there is no way to write C test program that fail I could not see 
ather way to detect issue except to parse result from programs that 
output library dependencies. Also I expect this to fail for static build 
(--disable-shared).
I'm not sure that readline library work well with static builds - but 
this is another issue and my time machine is stop working :) .

To write script that check platform and if is freebsd, suse link with a, 
b, c if os is XX link with d, e, f will work with shared and static 
build - It is not reasonable solution :(

P.S. Issue with readline library linked to termcap compatible library on 
system that distribute more then one termcap compatible library is about 
10 years old.

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Tue Apr 27 00:27:59 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Mon, 26 Apr 2010 22:27:59 +0000
Subject: [issue1712522] urllib.quote throws exception on Unicode URL
Message-ID: <1272320879.7.0.282897602104.issue1712522@psf.upfronthosting.co.za>


Changes by Lino Mastrodomenico <l.mastrodomenico at gmail.com>:


----------
nosy: +mastrodomenico

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1712522>
_______________________________________

From report at bugs.python.org  Tue Apr 27 00:29:46 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 26 Apr 2010 22:29:46 +0000
Subject: [issue8536] Support new features of ZLIB 1.2.4
In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>
Message-ID: <1272320986.17.0.244061804893.issue8536@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Do you intend to provide a patch?

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8536>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:14:19 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Apr 2010 23:14:19 +0000
Subject: [issue8524] SSL sockets do not retain the parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272323659.66.0.220868442065.issue8524@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

getpeername() "sometimes" failing "soon" after a socket is created is a semi-well-known Windows socket... feature.  For whatever that's worth.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:20:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 26 Apr 2010 23:20:15 +0000
Subject: [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1272324015.3.0.403174320578.issue6916@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I seem to remember that those classes were initially removed and then re-added by Josiah for backward compatibility (see discussions in issue 1641 and issue 1736190).

Despite practically useless after the changes applied to asynchat in Python 2.6, both classes are there since the very first checkin of asynchat.py, and the common policy in this case is to grant compatibility with older code, just in case few person out of many still rely on it.

I'd be more for stopping to mention them in the documentation, also because now that I look at it, the doc is wrong as it claims that "Each channel maintains a fifo" while this is no longer true since fifo() has been replaced by a deque().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6916>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:21:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Apr 2010 23:21:27 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1272324087.22.0.587527682771.issue2521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Someone with a better knowledge of ABCs than me should probably do a final review of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:22:54 2010
From: report at bugs.python.org (Nir Aides)
Date: Mon, 26 Apr 2010 23:22:54 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272324174.66.0.14429243749.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Dave, there seems to be a bug in your patch on Windows XP. It crashes in ccbench.py with the following output:

>python_d.exe y:\ccbench.py
== CPython 3.2a0.0 (py3k) ==
== x86 Windows on 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' ==

--- Throughput ---

Pi calculation (Python)

threads= 1:   840 iterations/s. balance
Fatal Python error: ReleaseMutex(mon_mutex) failed
threads= 2:   704 ( 83%)        0.8167
threads= 3:   840 (100%)        1.6706
threads= 4:   840 (100%)        2.0000

and the following stack trace:

 	ntdll.dll!7c90120e() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	python32_d.dll!Py_FatalError(const char * msg)  Line 2033	C
>	python32_d.dll!gil_monitor(void * arg)  Line 314 + 0x24 bytes	C
 	python32_d.dll!bootstrap(void * call)  Line 122 + 0x7 bytes	C
 	msvcr100d.dll!_callthreadstartex()  Line 314 + 0xf bytes	C
 	msvcr100d.dll!_threadstartex(void * ptd)  Line 297	C
 	kernel32.dll!7c80b729()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:25:02 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 23:25:02 +0000
Subject: [issue8536] Support new features of ZLIB 1.2.4
In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>
Message-ID: <1272324302.5.0.579150582058.issue8536@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am documenting a "need" and marking it as "easy".

If somebody else want to work on this, perfect. If not, I would adopt it in the future, and provide a patch myself. I rather prefer the first option, and I think is a good issue for a newbie (with C knowledge).

Let's say this issue is a "to be done". Creating the issue will prevent me to forget about modern zlib support in Python. But if anybody else step forward, I will be glad :).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8536>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:51:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 26 Apr 2010 23:51:52 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1272325912.7.0.0396323144155.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Someone with appropriate permissions want to update the "Stage"?

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:55:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 26 Apr 2010 23:55:55 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1272326155.21.0.374192794523.issue2521@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Tue Apr 27 01:57:48 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 26 Apr 2010 23:57:48 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272326268.07.0.939454884114.issue8005@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thomas, could you write a unit test to go along with your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 02:21:56 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 27 Apr 2010 00:21:56 +0000
Subject: [issue8543] asynchat documentation issues
In-Reply-To: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>
Message-ID: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

I recently took a look at asynchat doc and found out it has some issues which should be addressed.
In my opinion the following methods and functions should NOT be mentioned:


- async_chat.refill_buffer()

this has been removed in Python 2.6 and no longer exists, plus there was no reason to override it in the first place as it was an internal method


 - asynchat.find_prefix_at_end(haystack, needle)

there's really no reason to mention this one, it is just used internally by async_chat class to implement the terminator logic


- async_chat.handle_close()
- async_chat.readable()
- async_chat.writable()
- async_chat.handle_read()
- async_chat.handle_write()

all inherited from asyncore, plus, aside from handle_close(), they should *NOT* be overridden as they implement the entire logic behind asynchat module


- class asynchat.simple_producer(data[, buffer_size=512])
- class asynchat.fifo([list=None])

as discussed in issue 6916 these are very old classes which are no longer used; imho not worth to be mentioned in the doc


- async_chat._collect_incoming_data(data)
- async_chat._get_data()

both added in 2.6 (this isn't mentioned), not sure if it's worth mentioning them (I wouldn't) but they're basically private methods which are never used in the base class and only provide a sample implementation


I think asynchat documentation should focus more on showing those parts of the API which are really going to be used, basically push*(), close_when_done() and terminator-related methods.
All other methods like handle_*(), etc..., are deliberately not supposed to be used and only create confusion.

I think I'm going to attach a patch tomorrow but I'd like to hear the opinion of Josiah Carlson before doing anything.

----------
assignee: docs at python
components: Documentation
messages: 104292
nosy: docs at python, giampaolo.rodola, josiah.carlson, josiahcarlson, r.david.murray
priority: normal
severity: normal
status: open
title: asynchat documentation issues
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8543>
_______________________________________

From report at bugs.python.org  Tue Apr 27 02:50:06 2010
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Apr 2010 00:50:06 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1272329406.53.0.220694296409.issue7833@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Tue Apr 27 02:50:48 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 00:50:48 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272329448.6.0.659361198611.issue7946@psf.upfronthosting.co.za>


Changes by David Beazley <dave at dabeaz.com>:


Removed file: http://bugs.python.org/file17094/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 02:52:59 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 00:52:59 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272329579.41.0.312057347857.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

New version of patch that will probably fix Windows-XP problems. Was doing something stupid in the monitor (not sure how it worked on Unix).

----------
Added file: http://bugs.python.org/file17102/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 06:25:08 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Tue, 27 Apr 2010 04:25:08 +0000
Subject: [issue8544] i didn't get rqrd output for programme in python?(plz...
	help)
In-Reply-To: <1272342306.38.0.0856724920628.issue8544@psf.upfronthosting.co.za>
Message-ID: <1272342306.38.0.0856724920628.issue8544@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

i want to print the all posssibilities that occurs in rearrangement of letter between given input?(repetations are not allowed)?

suppose i give input as car => the output is like this

car
cra
acr
arc
rac
rca

like that ..i want factorial of length of the given input ?

----------
messages: 104294
nosy: abdelazer, krishnalolla
priority: normal
severity: normal
status: open
title: i didn't get rqrd output for programme in python?(plz... help)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8544>
_______________________________________

From report at bugs.python.org  Tue Apr 27 06:26:19 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Tue, 27 Apr 2010 04:26:19 +0000
Subject: [issue8545] i didn't get rqrd output for programme in python?(plz...
	help)
In-Reply-To: <1272342379.47.0.213432765207.issue8545@psf.upfronthosting.co.za>
Message-ID: <1272342379.47.0.213432765207.issue8545@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

i want to print the all posssibilities that occurs in rearrangement of letter between given input?(repetations are not allowed)?

suppose i give input as car => the output is like this

car
cra
acr
arc
rac
rca

like that ..i want factorial of length of the given input ?

----------
components: Regular Expressions
messages: 104295
nosy: abdelazer, krishnalolla
priority: normal
severity: normal
status: open
title: i didn't get rqrd output for programme in python?(plz... help)
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8545>
_______________________________________

From report at bugs.python.org  Tue Apr 27 06:33:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 27 Apr 2010 04:33:56 +0000
Subject: [issue8544] i didn't get rqrd output for programme in python?(plz...
	help)
In-Reply-To: <1272342306.38.0.0856724920628.issue8544@psf.upfronthosting.co.za>
Message-ID: <1272342836.59.0.390346831278.issue8544@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Please use python-help at python.org or comp.lang.python, not the tracker.
Also check the collections module.

----------
nosy: +orsenthil
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8544>
_______________________________________

From report at bugs.python.org  Tue Apr 27 08:47:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 27 Apr 2010 06:47:07 +0000
Subject: [issue8545] i didn't get rqrd output for programme in python?(plz...
	help)
In-Reply-To: <1272342379.47.0.213432765207.issue8545@psf.upfronthosting.co.za>
Message-ID: <1272350827.69.0.170675226975.issue8545@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please use python-help at python.org or comp.lang.python for usage questions, not the tracker.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8545>
_______________________________________

From report at bugs.python.org  Tue Apr 27 08:48:05 2010
From: report at bugs.python.org (Paul Jimenez)
Date: Tue, 27 Apr 2010 06:48:05 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1272350885.87.0.160157604363.issue1462525@psf.upfronthosting.co.za>


Paul Jimenez <pj at place.org> added the comment:

Since no one else has commented on this in over a year, and the new (2.6+) code works fine, I'll just close this to help clean things up.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462525>
_______________________________________

From report at bugs.python.org  Tue Apr 27 09:09:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 27 Apr 2010 07:09:24 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1272352164.11.0.437630969062.issue8128@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

In Python 2.x, __unicode__ is called instead of __str__.  Whether that's "correct" behavior, I'm not sure, but at least it is consistent with "{}".format(K()).

In Python 3.x, __unicode__ doesn't exist and __str__ isn't called; but for "{}".format(K()), it is.  Therefore I think here a fix should be made in any case.

Benjamin, what do you think?

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Tue Apr 27 09:13:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 27 Apr 2010 07:13:37 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1272352417.4.0.419776261447.issue4037@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

So for staticmethods and classmethods, valname doesn't need to be reassigned?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4037>
_______________________________________

From report at bugs.python.org  Tue Apr 27 10:26:50 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Tue, 27 Apr 2010 08:26:50 +0000
Subject: [issue8546] The parameter buffering in _pyio.open doesn't work the
	same as in the builtin open
In-Reply-To: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>
Message-ID: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

As far as I understand the _pyio.open function should resemble the builtin open, but in case of the buffering parameter, it doesn't. The builtin version doesn't allow None as argument, but this is the default in the _pyio.open signature.

I attached a patch, which changes the default value of the buffering parameter to -1, which is the default in the builtin version.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: change_pyio_open_buffering_parameter.diff
keywords: patch
messages: 104301
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: The parameter buffering in _pyio.open doesn't work the same as in the builtin open
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17103/change_pyio_open_buffering_parameter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8546>
_______________________________________

From report at bugs.python.org  Tue Apr 27 11:18:02 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 27 Apr 2010 09:18:02 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <4BD611AA.6020007@roumenpetrov.info>
Message-ID: <20100427091636.GA31863@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Roumen Petrov <report at bugs.python.org> wrote:
> Yes , I  understand .
> For the protocol did gcc on FreeBSD warn if library order is -lncursesw 
>   -lreadline  ?

No.

> P.S. Issue with readline library linked to termcap compatible library on 
> system that distribute more then one termcap compatible library is about 
> 10 years old.

I didn't want to touch the termcap logic. There's potential for breakage,
and a real investigation would be time consuming.

(There's a needless warning on Tiger about /usr/lib/termcap that could
be fixed in another issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Tue Apr 27 11:23:34 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 27 Apr 2010 09:23:34 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272360214.21.0.902766014317.issue7946@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

@dabeaz
I'm getting random segfaults with your patch (even with the last one), pretty much everywhere malloc or free is called.
Ater skimming through the code, I think the problem is due to gil_last_holder:
In drop_gil and take_gil, you dereference gil_last_holder->cpu_bound, but it might very well happen that gil_last_holder points to a thread that has been deleted (through tstate_delete_common). Dereferencing is not risky, because there's a high chance that the address is still valid, but in drop_gil, you do this:
    /* Make the thread as CPU-bound or not depending on whether it was forced off */
    gil_last_holder->cpu_bound = gil_drop_request;

Here, if the thread has been deleted in meantine, you end up writting to a random location on the heap, and probably corrupting malloc administration data, which would explain why I get segfaults sometimes later on unrelated malloc() or free() calls.
I looked at it really quickly though, so please forgive me if I missed something obvious ;-)

@nirai
I have some more remarks on your patch:
- /* Diff timestamp capping results to protect against clock differences 
 * between cores. */
_LOCAL(long double) _bfs_diff_ts(long double ts1, long double ts0) {

I'm not sure I understand. You can have problem with multiple cores when reading directly the TSC register, but that doesn't affect gettimeofday. gettimeofday should be reliable and accurate (unless the OS is broken of course), the only issue is that since it's wall clock time, if a process like ntpd is running, then you'll run into problem
- pretty much all your variables are declared as volatile, but volatile was never meant as a thread-synchronization primitive. Since your variables are protected by mutexes, you already have all necessary memory barriers and synchronization, so volatile just prevents optimization
- you use some funtions just to perform a comparison or substraction, maybe it would be better to just remove those functions and perform the substractions/comparisons inline (you declared the functions inline but there's no garantee that the compiler will honor it).
- did you experiment with the time slice ? I tried some higher values and got better results, without penalizing the latency. Maybe it could be interesting to look at it in more detail (and on various platforms).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 11:27:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 27 Apr 2010 09:27:49 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1272360469.68.0.498423288901.issue8128@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with Georg. I think 2.x is arguably correct, and 3.1 is broken.

It looks like this has already been fixed in 3.2. It's not immediately obvious why that is, I'll have to look at the code more than the quick glance I just gave it.

Python 3.1.1+ (release31-maint:77299, Jan  4 2010, 08:27:32) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class MyStr(str):
...     def __str__(self): return "Surprise!"
... 
>>> '%s' % MyStr('foo')
'foo'
>>> '{}'.format(MyStr('foo'))
'Surprise!'

Python 3.2a0 (py3k:80525M, Apr 27 2010, 05:19:53) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class MyStr(str):
...     def __str__(self): return "Surprise!"
... 
>>> '%s' % MyStr('foo')
'Surprise!'
>>> '{}'.format(MyStr('foo'))
'Surprise!'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Tue Apr 27 11:38:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Apr 2010 09:38:45 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272361125.7.0.828398271234.issue8005@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See issue 5516 for a related issue.

----------
nosy: +belopolsky, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 11:53:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 27 Apr 2010 09:53:58 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272362038.05.0.870798753745.issue8540@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

(1) Perhaps I missed the relevant part in the spec, so I had to check
what decNumber does: In the default context, clamp is 0, in the extended
contexts, it is 1. So Python's ExtendedContext should indeed set _clamp
to 1.


(2) I agree about the importance of the formats, and I think they should
be explicitly selectable like here:

http://java.sun.com/j2se/1.5.0/docs/api/java/math/class-use/MathContext.html

The current ExtendedContext is a bit of a vague concept, since it
should be exactly one of DECIMAL32, DECIMAL64 or DECIMAL128. And
none of these has prec=9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Tue Apr 27 12:07:32 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 27 Apr 2010 10:07:32 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272362852.0.0.564824463553.issue8540@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I knew it was somewhere: In the test case description, clamp=0 is
specified as the default:

http://speleotrove.com/decimal/dtfile.html#syntax

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Tue Apr 27 12:15:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Apr 2010 10:15:55 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272363355.68.0.960088801616.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Yes, the spec itself is rather vague on the subject of clamping, so I withdraw my claim that clamping is necessary for compliance with the spec.  It *is* necessary to make the those testcases with 'clamp=1' pass, though.

So from the point of view of compliance with the specification it's fine to leave the _clamp attribute private.

I agree it would be useful to give easy access to the IEEE 754 formats, though, for interoperability with C and Java (thanks for the Java link!).  The most important formats are decimal32, decimal64 and decimal128, but IEEE 754 also specifies parameters for decimal{k} where k is any multiple of 32 bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Tue Apr 27 12:40:32 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 10:40:32 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272364832.88.0.445931615314.issue7946@psf.upfronthosting.co.za>


Changes by David Beazley <dave at dabeaz.com>:


Removed file: http://bugs.python.org/file17102/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 12:48:30 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 10:48:30 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272365310.6.0.0963425282137.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Added extra pointer check to avoid possible segfault.

----------
Added file: http://bugs.python.org/file17104/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 12:50:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Apr 2010 10:50:33 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272365433.03.0.752179029322.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re: ExtendedContext, the comments in decimal.py say:

# Pre-made alternate contexts offered by the specification
# Don't change these; the user should be able to select these
# contexts and be able to reproduce results from other implementations
# of the spec.

This doesn't make a lot of sense to me, since (as Stefan says) the choice of precision 9 doesn't seem to come from the specification.

However, the current ExtendedContext is used extensively in doctests and elsewhere;  it would be awkward to change it now.  I think adding the IEEE formats and encouraging users to use those in place of ExtendedContext might be the best bet.

I'd also still want to make _clamp public in this case, to avoid people wondering why two apparently identical contexts (one with _clamp=1, one with _clamp=0) can lead to different results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Tue Apr 27 13:04:22 2010
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Tue, 27 Apr 2010 11:04:22 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1272366262.94.0.354317270566.issue7384@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this issue and he asked:

"Basically, this is caused by

  a) our readline.so is linked against ncurses.so (via -ltermcap which is the same lib)
  b) wide-character enabled ncurses, ncursesw.so, is also loaded in the same process

To solve that, we need to have a separate termcap.so, do I understand the issue correctly?"

He also mentioned that "[a]nother more aggressive way is to make only ncursesw installed into the system which requires a recompilation of all ports that use ncurses (ncurses and ncursesw are source compatible, but in most cases they are binary compatible as long as application don't assume size of ncurses structures)."

Which I fully support, it's something that I did on DragonFly BSD a long time ago already (for all I can remember).

Your opinion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:20:45 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 27 Apr 2010 12:20:45 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272370845.74.0.50987667001.issue7946@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I don't see segfaults anymore, but there's still an unsafe dereference of gil_last_holder inside take_gil:

    /* Wait on the appropriate GIL depending on thread's classification */
    if (!tstate->cpu_bound) {
      /* We are I/O bound.  If the current thread is CPU-bound, force it off now! */
      if (gil_last_holder->cpu_bound) {
	SET_GIL_DROP_REQUEST();
      }

You're still accessing a location that may have been free()'d previously: while it will work most of the time (that's why I said it's not as risky), if the page gets unmapped between the time the current thread is deleted and the next thread takes over, you'll get a segfault. And that's undefined behaviour anyway ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:23:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Apr 2010 12:23:19 +0000
Subject: [issue8547] unittest test discovery can fail when package under test
	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

When test discovery is invoked on a package on the filesystem which is also installed in site-packages then importing the tests will look in the installed version. This causes discovery to run the wrong tests or fail.

We can detect this (compare the __file__ against the expected location) and also insert the top level path as the first location in sys.path instead of appending it to the end.

If we detect a failed import then we should error out with an appropriate message.

(Nose gets round this by patching __import__ to import from a specific location which seems potentially fragile.)

----------
assignee: michael.foord
components: Library (Lib)
messages: 104313
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest test discovery can fail when package under test is also installed globally
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8547>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:24:51 2010
From: report at bugs.python.org (donal djeo)
Date: Tue, 27 Apr 2010 12:24:51 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272371091.49.0.589185817075.issue7946@psf.upfronthosting.co.za>


donal djeo <donaldjeo12 at gmail.com> added the comment:

I'm getting random segfaults with your patch (even with the last one), pretty much everywhere malloc or free is called.
Ater skimming through the code, I think the problem is due to gil_last_holder:
In drop_gil and take_gil, you dereference gil_last_holder->cpu_bound, but it might very well happen that gil_last_holder points to a thread that has been deleted (through tstate_delete_common). Dereferencing is not risky, because there's a high chance that the address is still valid, but in drop_gil, you do this:
/* Make the thread as CPU-bound or not depending on whether it was forced off */
gil_last_holder->cpu_bound = gil_drop_request;

Here, if the thread has been deleted in meantine, you end up writting to a random location on the heap, and probably corrupting malloc administration data, which would explain why I get segfaults sometimes later on unrelated malloc() or free() calls.
I looked at it really quickly though, so please forgive me if I missed something obvious ;-)

@nirai
I have some more remarks on your patch:
- /* Diff timestamp capping results to protect against clock differences
* between cores. */
_LOCAL(long double) _bfs_diff_ts(long double ts1, long double ts0) {

I'm not sure I understand. You can have problem with multiple cores when reading directly the TSC register, but that doesn't affect gettimeofday. gettimeofday should be reliable and accurate (unless the OS is broken of course), the <a href="http://www.mcpexams.net">mcp</a> only issue is that since it's wall clock time, if a process like ntpd is running, then you'll run into problem
- pretty much all your variables are declared as volatile, but volatile was never meant as a thread-synchronization primitive. Since your variables are protected by mutexes, you already have all necessary memory barriers and synchronization, so volatile just prevents optimization
- you use some funtions just to perform a comparison or substraction, maybe it would be better to just remove those functions and perform the substractions/comparisons inline (you declared the functions inline but there's no garantee that the compiler will honor it).
- did you experiment with the time slice ? I tried some higher values and got better results, without penalizing the latency. Maybe it could be interesting to look at it in more detail (and on various platforms).

----------
components: +None -Interpreter Core
nosy: +donaldjeo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:39:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 12:39:53 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272371993.1.0.742526673783.issue7946@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:40:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 12:40:22 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272372022.19.0.410300377223.issue7946@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:43:23 2010
From: report at bugs.python.org (Koen van de Sande)
Date: Tue, 27 Apr 2010 12:43:23 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1272372203.43.0.893240526004.issue7833@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

There should be no manifest embedded into wininst, because then the cases which Issue 4120 fixed (a CRT installed into a local folder, instead of system-wide, due to limited access rights), will 'break' again: the installer can then no longer work unless there is a system-wide installation of the CRT.

Option #1, #2 and #3 all sound reasonable (and #2 is the current situation).

I have some doubts about option #4: it is a very specific use case, and then the whole benefit of issue 4120 is lost, because stripping runtimes would have to be removed again. Why is putting a separate manifest file next to the DLL not an option? Combined with #3 (allow extension developer to disable embedding of manifests) a separate manifest can fix the problem.

----------
nosy: +koen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:43:25 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 27 Apr 2010 12:43:25 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1272366262.94.0.354317270566.issue7384@psf.upfronthosting.co.za>
Message-ID: <20100427124151.GA2620@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Jeroen Ruigrok van der Werven <report at bugs.python.org> wrote:
> Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this issue and he asked:
>
> "Basically, this is caused by
>
>   a) our readline.so is linked against ncurses.so (via -ltermcap which is the same lib)
>   b) wide-character enabled ncurses, ncursesw.so, is also loaded in the same process
>
> To solve that, we need to have a separate termcap.so, do I understand the issue correctly?"

Yes, only that the separate termcap is called libtinfo.so. The approach of
splitting out libtinfo from ncurses (used by Fedora) is the most flexible
and allows the user to choose ncurses or ncursesw.

[stefan at fedora-amd64 ~]$ ldd /lib64/libreadline.so.6.0
        linux-vdso.so.1 =>  (0x00007fff725ff000)
        libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00000036e4a00000)
        libc.so.6 => /lib64/libc.so.6 (0x00000036d9600000)
        /lib64/ld-linux-x86-64.so.2 (0x00000036d9200000)

+ports that use ncurses (ncurses and ncursesw are source compatible, but in most cases they are binary compatible as long as application don't
+assume size of ncurses structures)."
>
> Which I fully support, it's something that I did on DragonFly BSD a long time ago already (for all I can remember).
>
> Your opinion?

I think the libtinfo approach is more flexible, and I'm not aware of any drawbacks.
So, for FreeBSD, I'd use it.

Stefan Krah

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:43:53 2010
From: report at bugs.python.org (Guilherme Salgado)
Date: Tue, 27 Apr 2010 12:43:53 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272372233.92.0.0965663544125.issue7946@psf.upfronthosting.co.za>


Changes by Guilherme Salgado <gsalgado at gmail.com>:


----------
nosy:  -salgado

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:44:46 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 12:44:46 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272372286.19.0.963204766455.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

That second access of gil_last_holder->cpu_bound is safe because that block of code is never entered unless some other thread currently holds the GIL.   If a thread holds the GIL, then gil_last_holder is guaranteed to have a valid value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 14:49:47 2010
From: report at bugs.python.org (Koen van de Sande)
Date: Tue, 27 Apr 2010 12:49:47 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1272372587.01.0.812567853026.issue7833@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

Concerning the patch: what happens when the developer already added /MANIFEST:NO to the flags, and the code deduces that MSVCR9 is the only runtime, e.g. the case where /MANIFEST:NO is in the flags twice? Does the linker handle this OK, or does there need to be an additional check as to not have it twice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Tue Apr 27 15:24:12 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 27 Apr 2010 13:24:12 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272374652.33.0.64652266623.issue7946@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Didn't have much sleep last night, so please forgive me if I say something stupid, but:

Python/pystate.c:
void
PyThreadState_DeleteCurrent()
{
	PyThreadState *tstate = _PyThreadState_Current;
	if (tstate == NULL)
		Py_FatalError(
			"PyThreadState_DeleteCurrent: no current tstate");
	_PyThreadState_Current = NULL;
	tstate_delete_common(tstate);
	if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
		PyThread_delete_key_value(autoTLSkey);
	PyEval_ReleaseLock();
}

the current tstate is deleted and freed before releasing the GIL, so if another thread calls take_gil after the current thread has called tstate_delete_common but before it calls PyEval_ReleaseLock (which calls drop_gil and set gil_locked to 0), then it will enter this section and dereference gil_last_holder.
I just checked with valgrind, and he also reports an illegal dereference at this precise line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 15:44:45 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 13:44:45 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272375885.82.0.776192486581.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I stand corrected.   However, I'm going to have to think of a completely different approach for carrying out that functionality as I don't know how the take_gil() function is able to determine whether gil_last_holder has been deleted or not.   Will think about it and post an updated patch later. 

Do you have any examples or insight you can provide about how these segfaults have shown up in Python code?   I'm not able to observe any such behavior on OS-X or Linux.  Is this happening while running the ccbench program?  Some other program?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 15:54:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2010 13:54:09 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1272376449.3.0.499590844672.issue7027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Same error here:
http://www.python.org/dev/buildbot/builders/AMD64 Ubuntu 2.6/builds/555/steps/test/logs/stdio

(codecs_none.txt is a copy of stdio)

----------
nosy: +haypo
Added file: http://bugs.python.org/file17105/codecs_none.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________

From report at bugs.python.org  Tue Apr 27 15:59:19 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 13:59:19 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272376759.55.0.301084179731.issue2810@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
title: _winreg.EnumValue fails when the registry data includes multibyte unicode characters -> _winreg.EnumValue sometimes raises WindowsError ("More data is available")

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:07:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 27 Apr 2010 14:07:41 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272377261.93.0.576483464337.issue8540@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'd prefer to drop the ExtendedContext completely. Reasons are:

  1) _clamp, prec, emin and emax aren't set to IEEE754 values.

  2) The use of 'extended' is decNumber specific (see
     http://speleotrove.com/decimal/dncont.html ). In IEEE754
     'extended' has yet another meaning (AFAICS).


I can see that it is awkward to remove it, but if there's consensus
I'd be willing to work on a patch.

Making clamp visible sounds fine to me. (Personally, I'd rather have
capitals non-visible.)

If we make Decimal{32,64,128} contexts available, we should document exactly how the arithmetic deviates from IEEE754.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:08:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 14:08:12 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1272377292.83.0.679969793129.issue1289118@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:13:16 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 27 Apr 2010 14:13:16 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1272377596.67.0.278352061218.issue8128@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

It's probably a duplicate of issue #1583863.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:31:01 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 14:31:01 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272378661.08.0.00217552027304.issue7946@psf.upfronthosting.co.za>


Changes by David Beazley <dave at dabeaz.com>:


Removed file: http://bugs.python.org/file17104/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:31:17 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 27 Apr 2010 14:31:17 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272378677.07.0.992982916704.issue7946@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Do you have any examples or insight you can provide about how these segfaults have shown up in Python code?   I'm not able to observe any such behavior on OS-X or Linux.  Is this happening while running the ccbench program?  Some other program?

If you're talking about the first issue (segfaults due to writting to gil_last_holder->cpu_bound), it was occuring quite often during ccbench (pretty much anywhere malloc/free was called). I'm running a regular dual-core Linux box, nothing special.

For the second one, I didn't observe any segfault, I just figured this out reading the code and confirmed it with valgrind, but it's much less likely because the race window is very short and it also requires that the page is unmmaped in between.

If someone really wanted to get segfaults, I guess a good start would be:
- get a fast machine, multi-core is a bonus
- use a kernel with full preemption
- use a lot of threads (-n option with ccbench)
- use purify or valgrind --free-fill option so that you're sure to jump to noland if you dereference a previously-free'd pointer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:32:36 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 27 Apr 2010 14:32:36 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272378756.05.0.212671232568.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

One more attempt at fixing tricky segfaults.   Glad someone had some eagle eyes on this :-).

----------
Added file: http://bugs.python.org/file17106/dabeaz_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:45:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 27 Apr 2010 14:45:24 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1272379524.65.0.730769531301.issue8128@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Yes, that's the cause, thanks for finding that issue. It's actually fixed in 3.1.2, I just hadn't updated my local copy.

Closing, since there's nothing to fix here. The 2.6 behavior is correct, and the 3.x behavior that was broken has been fixed.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> __str__ cannot be overridden on unicode-derived classes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:57:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 27 Apr 2010 14:57:36 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272380256.89.0.874292036139.issue8005@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Is there a patch with a fix or just a patch with a test.  If the later, maybe someone can remove a patch keyword.

----------
nosy: +Alexander.Belopolsky -belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 16:58:56 2010
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 27 Apr 2010 14:58:56 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272380336.88.0.296093732046.issue8005@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

It's just a test. Finishing the patch completely slipped my mind. I'll work on it later tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:00:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:00:12 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272380412.99.0.48273010981.issue8005@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

You're right.  I asked Thomas the wrong question, and the Keywords and Stage need updating.

Thomas, do you still plan to submit a patch that fixes the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:01:00 2010
From: report at bugs.python.org (Nir Aides)
Date: Tue, 27 Apr 2010 15:01:00 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272380460.56.0.644911408925.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

On Tue, Apr 27, 2010 at 12:23 PM, Charles-Francois Natali wrote:

> @nirai
> I have some more remarks on your patch:
> - /* Diff timestamp capping results to protect against clock differences
>  * between cores. */
> _LOCAL(long double) _bfs_diff_ts(long double ts1, long double ts0) {
>
> I'm not sure I understand. You can have problem with multiple cores when reading directly the 
> TSC register, but that doesn't affect gettimeofday. gettimeofday should be reliable and accurate 
> (unless the OS is broken of course), the only issue is that since it's wall clock time, if a process 
> like ntpd is running, then you'll run into problem

I think gettimeofday() might return different results on different cores as result of kernel/hardware problems or clock drift issues in VM environments:
http://kbase.redhat.com/faq/docs/DOC-7864
https://bugzilla.redhat.com/show_bug.cgi?id=461640

In Windows the high-precision counter might return different results on different cores in some hardware configurations (older multi-core processors). I attempted to alleviate these problems by using capping and by using a "python time" counter constructed from accumulated slices, with the assumption that IO bound threads are unlikely to get migrated often between cores while running. I will add references to the patch docs.

> - did you experiment with the time slice ? I tried some higher values and got better results, 
> without penalizing the latency. Maybe it could be interesting to look at it in more detail (and 
> on various platforms).

Can you post more details on your findings? It is possible that by using a bigger slice, you helped the OS classify CPU bound threads as such and improved "synchronization" between BFS and the OS scheduler.

Notes on optimization of code taken, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:01:12 2010
From: report at bugs.python.org (Thomas W. Barr)
Date: Tue, 27 Apr 2010 15:01:12 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272380472.49.0.499798636878.issue8005@psf.upfronthosting.co.za>


Thomas W. Barr <twb at rice.edu> added the comment:

I'm still reasonably new to the codebase, but I'm certainly going to try to fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:04:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:04:26 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272380666.51.0.374289310846.issue8005@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Great!  If you get stuck or have a question, just ask. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:18:18 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:18:18 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272381498.81.0.706326865141.issue8005@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
keywords:  -patch
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:19:44 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:19:44 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272381584.2.0.0971770660929.issue2810@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee:  -> stutzbach
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:24:40 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:24:40 +0000
Subject: [issue6672] Add Mingw recognition to pyport.h to allow building
	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1272381880.46.0.535098838405.issue6672@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
components: +Windows
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:28:13 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:28:13 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1272382093.07.0.771052256751.issue5553@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee:  -> stutzbach
priority:  -> low
stage:  -> needs patch
type:  -> performance
versions: +Python 3.2 -Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5553>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:34:06 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:34:06 +0000
Subject: [issue4295] closing stdout in a child process on cygwin means that
	process doesn't receive bytes from stdin anymore. I think.
In-Reply-To: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>
Message-ID: <1272382446.69.0.609893688694.issue4295@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4295>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:35:18 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:35:18 +0000
Subject: [issue808164] socket.close() doesn't play well with __del__
Message-ID: <1272382518.75.0.486491618764.issue808164@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee:  -> stutzbach
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue808164>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:37:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:37:09 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272382629.75.0.864594966754.issue7079@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:37:44 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:37:44 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272382664.93.0.258871226703.issue7079@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee: gregory.p.smith -> stutzbach
stage: patch review -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:39:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 15:39:36 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272382776.44.0.885403689669.issue8005@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee:  -> stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 17:53:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 27 Apr 2010 15:53:34 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272383614.89.0.142846286365.issue8005@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Before someone spends more time writing a patch, lets pause and consider whether this is a bug in the first place.

My understanding of the issue is that given

>>> class A(object):
...   def __eq__(self, other):
...    return True
... 

OP expects date(1,1,1) == A() to return True, but instead

>>> date(1,1,1) == A()
False


Note that this problem can be worked around by endowing A with a timetuple attribute:

>>> A.timetuple=1

Now

>>> date(1,1,1) == A()
True

This is a documented feature:

"""
 In order to stop comparison from falling back to the default scheme of comparing object addresses, date comparison normally raises TypeError if the other comparand isn?t also a date object. However, NotImplemented is returned instead if the other comparand has a timetuple() attribute. This hook gives other kinds of date objects a chance at implementing mixed-type comparison. If not, when a date object is compared to an object of a different type, TypeError is raised unless the comparison is == or !=. The latter cases return False or True, respectively.
""" http://docs.python.org/release/2.6.5/library/datetime.html#datetime.date.day (Note 4)

I am adding Tim to the "nosy" list because he appears to be the author of the relevant code.

It is my understanding that this issue can only be regarded as an RFE. Given the fact that 2.x is approaching bug fix only stage (if it is not already there) and the problem is fixed in 3.x, I recommend closing this as "won't fix."

Mark,

No, I don't think this is directly related to issue 5516.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 18:43:11 2010
From: report at bugs.python.org (Jeff Binder)
Date: Tue, 27 Apr 2010 16:43:11 +0000
Subject: [issue8548] Building on CygWin 1.7: PATH_MAX redefined
In-Reply-To: <1272386591.01.0.834578637911.issue8548@psf.upfronthosting.co.za>
Message-ID: <1272386591.01.0.834578637911.issue8548@psf.upfronthosting.co.za>


New submission from Jeff Binder <extruded at gmail.com>:

Building Python 3.1.2 on Cygwin 1.7, I got errors in main.c stemming from a warning: PATH_MAX redefined (see attached log).  I got around this by commenting out the #define.  I don't know if the best solution is #ifndef, #undef, or something else. . . . I know CygWin has changed the value of PATH_MAX in 1.7 (see: http://www.cygwin.com/cygwin-ug-net/ov-new1.7.html), though I'm not sure why that would cause this problem.

----------
components: Installation
files: python-build-logs.tar.gz
messages: 104334
nosy: jbinder
priority: normal
severity: normal
status: open
title: Building on CygWin 1.7: PATH_MAX redefined
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file17107/python-build-logs.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8548>
_______________________________________

From report at bugs.python.org  Tue Apr 27 18:44:46 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 27 Apr 2010 16:44:46 +0000
Subject: [issue8506] SimpleXMLRPCServer Socket not closed after shutdown call
In-Reply-To: <1272026284.3.0.0989904198918.issue8506@psf.upfronthosting.co.za>
Message-ID: <1272386686.24.0.339178068845.issue8506@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santa.ant at me.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8506>
_______________________________________

From report at bugs.python.org  Tue Apr 27 18:45:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 16:45:58 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1272375885.82.0.776192486581.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272386891.3413.7.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I stand corrected.   However, I'm going to have to think of a
> completely different approach for carrying out that functionality as I
> don't know how the take_gil() function is able to determine whether
> gil_last_holder has been deleted or not.

Please note take_gil() currently doesn't depend on the validity of the
pointer. gil_last_holder is just used as an opaque value, equivalent to
a thread id.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 18:46:41 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Apr 2010 16:46:41 +0000
Subject: [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: <1272386801.03.0.504297015921.issue8060@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Too late for 2.7, but I would like this to hit 3.2. Some calculators have engineering format as an output option and it would be good for Python.

This issue is being discussed in python-list in thread "Engineering numerical format...". The OP (or someone) posted an Engineer(float) class with a .format method that does what *he* would like. Participants have been invited by Mark to comment here.

It was noted that Decimal has a .to-engineering-string method, but it follows the standard at page 20 of
speleotrove.com/decimal/decarith.pdf
which is different from what is being asked for.

----------
nosy: +tjreedy
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Tue Apr 27 19:19:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2010 17:19:31 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1272388771.71.0.52121639704.issue7027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is specific to Python 2.6. It can be reproduced with:

./python -E -tt ./Lib/test/regrtest.py -l -w test_pep263 test_operator test_asynchat test_zipimport_support test_pydoc test_code test_dis test_quopri test_doctest test_class test_sax test_fileio test_asyncore test_mailbox test_abstract_numbers test_uuid test_io test_enumerate test_property test_codecs

Or with this little test case:
----
import codecs, _codecs, sys, encodings

encoding = "cp1252"

codec = _codecs.lookup(encoding)

modname = 'encodings.%s' % encoding
__import__(modname)
del sys.modules[modname]
delattr(encodings, encoding)

encoder = codecs.getincrementalencoder(encoding)()
encoder.encode("", True)
----

module_dealloc() was modified in python trunk: the dictionary is only cleared if the reference counter is equal to 1.

/* If we are the only ones holding a reference, we can clear the dictionary. */
if (Py_REFCNT(m->md_dict) == 1) _PyModule_Clear((PyObject *)m);

----------
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________

From report at bugs.python.org  Tue Apr 27 19:21:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 17:21:19 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1272388879.66.0.619250623895.issue7027@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________

From report at bugs.python.org  Tue Apr 27 19:24:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2010 17:24:21 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1272389061.59.0.766411913298.issue7027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

module-dealloc() was changed by #7140 by r75437: "imp.new_module does not function correctly if the module is returned from a function and used directly".

Can we backport the fix to 2.6? It would be complex to write a workaround in the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________

From report at bugs.python.org  Tue Apr 27 19:42:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2010 17:42:44 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1272390164.13.0.268961289733.issue7027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a workaround. I didn't expected a short patch, but it's enough.

----------
keywords: +patch
Added file: http://bugs.python.org/file17108/regrtest_preload_ascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________

From report at bugs.python.org  Tue Apr 27 19:52:36 2010
From: report at bugs.python.org (Sriram)
Date: Tue, 27 Apr 2010 17:52:36 +0000
Subject: [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1272390756.88.0.622898737626.issue5727@psf.upfronthosting.co.za>


Sriram <sriramrathinavelu at yahoo.com> added the comment:

Hi,

I believe this behaviour can be tested if we can prove that Cmd's cmdloop uses raw_input to get the data as against self.stdin.readline().

To test it, ideally I would have liked to override sys.stdin with a fake input stream and pass the list of args (like it's done in test_doctest.py). I can then pass the character codes for Up and Down Arrows in our fake stream and check if the raw_input can use readline and move through the fake input stream but that won't be possible because the C implementation of raw_input uses the readline functionality if only both stdin and stdout are from a terminal.

So alternatively, if we can just ensure that doctest's pdb (_OutputREdirectingPdb) has use_rawinput as 1, we can be assured that readline will be used.

I have attached the svn diff with trunk. Please review and comment

Thanks
Sriram

----------
Added file: http://bugs.python.org/file17109/pdbreadline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5727>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:03:44 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 27 Apr 2010 18:03:44 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1272391424.98.0.394441217483.issue7833@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

> I have some doubts about option #4: it is a very specific use case, and then the whole benefit of issue 4120 is lost

Pythoncom are pywintypes are indeed special cases: Out of the 170 DLL files in my Python site-packages directory, these seem to be the only ones built with distutils. All other DLLs are apparently built without  Python involvement using make, nmake, CMake, or Visual Studio and most of them contain embedded manifests, which is the default when using nmake, CMake, or Visual Studio. Practically, to make a standalone distribution of any Python 2.6/3.1 application with external DLL dependencies likely requires to provide external manifest files. The issue4120 patch does not change this situation and I don't see any sane way to patch Python/distutils that could. The main benefit of the issue4120 patch, as I see it, is that PYD files produced by distutils work in a standalone distribution without any further attention. Msvc9compiler_stripruntimes_revised.patch does not change this.

My reasoning for this patch (besides fixing the bdist_wininst installer issue) was to allow the popular pywin32 package to build without changes, and offer a way for other extension packages to exclude manifests from DLL files if required (apparently not that common). Alternatively one could provide a mechanism to embed specific manifests into DLLs. Is that currently possible? Then pywin32 setup.py could be fixed.


> Why is putting a separate manifest file next to the DLL not an option?

Because the pythoncom dll is currently installed into the Windows system directory. Putting manifest files there will pollute the system directory even more and possibly interfere with other system components if not done right (not tested). But again, pywin32 setup.py could be fixed to not install the DLL/manifest files into the system directory.


Which Python packages other than pywin32 build DLL files via distutils? I don't know any.

Can anyone provide a minimal setup.py script and C file that produces a DLL file for testing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:04:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Apr 2010 18:04:02 +0000
Subject: [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: <1272391442.47.0.100600980759.issue8060@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

After the all-important issue of what letter to use (the folks on the python-list thread suggested 'm', and it seems as good a letter as any, so I'll use it in the examples below), there are some open questions:

(1) The exact form of the output needs to be determined.  For a nonzero finite number, I'm guessing the output should look something like:

'<sign><digits>.<digits>e<exponent>

with at least 1 and at most 3 digits to the left of the point (and the first of those digits being nonzero).  Is this about right?  The sign would be controlled in the same way as for 'e', 'f' and 'g' formatting.  Would the exponent be included even when it's zero, or should it be omitted in that case?

(We'd need to determine how to output zeros, nans and infinities, too, but that shouldn't be a big issue.)

(2) When doing something like 'format(x, '.5m')', what would the 5 refer to?  The two options I see are (a) number of significant digits, or (b) number of digits to the right of the point.  The former seems to make more sense mathematically, but might be a bit awkward when it comes to aligning results in a table:

format(3.2, '.5m')  -> 3.20000e+00
format(13.2, '.5m') -> 13.2000e+00

The latter results in different numbers of significant digits depending on where the exponent lies.

Hmm.  Perhaps there's also (c):  number of places to the right of the *true* decimal point, so that 'm' is more analogous to 'f' than to 'e'.

(3) What should the default precision be?  6 is what's used for 'e', 'f' and 'g' formatting, so should probably also be used for 'm'.

(4) When (if ever) should trailing zeros and a trailing decimal point be omitted (like 'g' formatting does).  I'd say never.

(5) What should the decimal module do?  Call to_eng_string, or try to match float's behaviour?  Formatting for the decimal type has the added complication of trying to preserve significant zeros where possible;  this might require some thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:04:31 2010
From: report at bugs.python.org (Josiah Carlson)
Date: Tue, 27 Apr 2010 18:04:31 +0000
Subject: [issue8543] asynchat documentation issues
In-Reply-To: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>
Message-ID: <1272391471.28.0.698643147.issue8543@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

The suggested documentation changes sound good to me.  Those items that aren't documented may need a note that they are deprecated and will be removed in the future, but I'd consider that optional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8543>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:10:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Apr 2010 18:10:45 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272391845.35.0.876307887475.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'd prefer to drop the ExtendedContext completely.

We have to be careful not to break existing 3rd party code, though.  A newly-designed decimal module, prepared with 20/20 hindsight, probably wouldn't include an ExtendedContext with the current definition. But we're not dealing with a newly-designed module:  we're dealing with a well-established and well-used module, so there's not a lot of scope for removals or major behaviour changes.

Personally, I don't think the design error (if there is a design error here) is big enough to make it worth breaking backwards compatibility.  I'd rather leave ExtendedContext in for the duration of Python 3.x, but introduce better options and steer (via the documentation) new decimal users towards those.

(BTW, Python takes backwards compatibility pretty seriously:  see PEP 387 for a write-up of the policy.)

> If we make Decimal{32,64,128} contexts available, we should document exactly how the arithmetic deviates from IEEE754.

Possibly, though that's less important to me than just being able to read and write values in these formats produced by other systems.

Were you thinking of any deviations in particular?


Making clamp public should be straightforward enough though, and is independent of the changes discussed above;  I'll see if I can come up with a patch.  (Even here, though, I think it makes sense to leave the private _clamp attribute in place in case people are using it;  a new public 'clamp' property can be added that wraps the _clamp attribute.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:12:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 27 Apr 2010 18:12:11 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1272391931.26.0.647723245187.issue8005@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thanks for pointing that out.  

For what it's worth, if I understand the documentation correctly the goal is to prevent the following misleading comparisons:

date with time
datetime with date
datetime with time
datetime w/ timezone with datetime w/o timezone
time w/ timezone with time w/o timezone

It's unfortunate that it throws a TypeError for all comparisons (unlike complex numbers which only throw a TypeError when comparing with numbers), but I suppose you are right that it's too late to fix this in 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:28:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2010 18:28:03 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1272392883.99.0.251239763431.issue7027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Can we backport the fix to 2.6?

It's too late to fix such subtle bug in module machinery, so I commited my workaround in regrtest.py: r80538. Wait for the buildbots before closing the issue.

test_io and/or test_codecs failed on buildbots:
 - AMD64 Ubuntu 2.6 (r80535)
 - x86 Tiger 2.6 (r80535)
 - x86 Windows7 2.6 (r80531)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:31:20 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 27 Apr 2010 18:31:20 +0000
Subject: [issue8549] Modules/_ssl.c: extra comma breaks build on AIX
In-Reply-To: <1272393080.82.0.0882803221687.issue8549@psf.upfronthosting.co.za>
Message-ID: <1272393080.82.0.0882803221687.issue8549@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Modules/_ssl.c

guido at 36917	
    64
enum py_ssl_version {
guido at 36917	
    65
	PY_SSL_VERSION_SSL2,
guido at 36917	
    66
	PY_SSL_VERSION_SSL3,
guido at 36917	
    67
	PY_SSL_VERSION_SSL23,
guido at 36917	
    68
	PY_SSL_VERSION_TLS1,
guido at 36917	
    69
};

Attached patch fixes this issue.

----------
components: Build
messages: 104347
nosy: srid
priority: normal
severity: normal
status: open
title: Modules/_ssl.c: extra comma breaks build on AIX
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8549>
_______________________________________

From report at bugs.python.org  Tue Apr 27 20:31:47 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 27 Apr 2010 18:31:47 +0000
Subject: [issue8549] Modules/_ssl.c: extra comma breaks build on AIX
In-Reply-To: <1272393080.82.0.0882803221687.issue8549@psf.upfronthosting.co.za>
Message-ID: <1272393107.6.0.192548422687.issue8549@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17110/fix-extra-comma-aix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8549>
_______________________________________

From report at bugs.python.org  Tue Apr 27 21:41:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 19:41:55 +0000
Subject: [issue8549] Modules/_ssl.c: extra comma breaks build on AIX
In-Reply-To: <1272393080.82.0.0882803221687.issue8549@psf.upfronthosting.co.za>
Message-ID: <1272397315.3.0.636329073056.issue8549@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you very much! Committed in r80540 (trunk), r80541 (2.6), r80542 (py3k), r80543 (3.1).

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8549>
_______________________________________

From report at bugs.python.org  Tue Apr 27 21:42:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 19:42:46 +0000
Subject: [issue8549] Modules/_ssl.c: extra comma breaks build on AIX
In-Reply-To: <1272393080.82.0.0882803221687.issue8549@psf.upfronthosting.co.za>
Message-ID: <1272397366.51.0.024798351227.issue8549@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8549>
_______________________________________

From report at bugs.python.org  Tue Apr 27 21:45:43 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Tue, 27 Apr 2010 19:45:43 +0000
Subject: [issue8493] socket's send can raise errno 35 under OS X,
	which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1272397543.8.0.320192964454.issue8493@psf.upfronthosting.co.za>


Matthew Cowles <mdcowles at users.sourceforge.net> added the comment:

Apologies! Further investigation indicates that the user had set a timeout in the ftplib module. I'll close this. In an ideal world, errors due to timeouts would look like they were related to timeouts. But that's a different matter entirely.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8493>
_______________________________________

From report at bugs.python.org  Tue Apr 27 21:50:26 2010
From: report at bugs.python.org (Keith Brafford)
Date: Tue, 27 Apr 2010 19:50:26 +0000
Subject: [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: <1272397826.52.0.418826825409.issue8060@psf.upfronthosting.co.za>


Keith Brafford <keith.brafford at gmail.com> added the comment:

Ok, let's zero in on how this should work.  I'll start the concrete proposal discussion in terms of how it would have worked with the old-style specifiers (since I am more familiar with that method) and we can bring it up to Py3K standards as a group.

I was thinking something along these lines:
%[<space> | 0 ][.precision]m

where the optional space or zero means that you want the whole number part of the output to be padded to three digits, either with spaces or prepended zeroes.  No space or zero means no prepending of anything.

The .precision would be the number of digits after the decimal point you want to see.  If you don't specify this, then the default would be something that people agreed made the most sense, say 4 for now.

f = math.pi * 1e-5
print f
3.1415926535897935e-005
print "%m" % f
31.4159e-06
print "% m" % f
  31.4159e-06
print "%0m" % f
031.4159e-06
print "% m.6" % f
  31.415927e-06

Mark brought up this point:

e.g. format(12345.678, '.5m'):  Should the '5' indicate 5 digits
after the point (giving '12.34568e+3' in this case), or 5 significant
digits in total (giving '12.345e+3').  

I tend to think that it's more important that the precision number tell you the number of digits after the decimal point.  This is because the underlying float still has all of the precision, and the format specifier is used simply to make the printout look correct.  Being able to specify that you want three slots before the point, then a constant number after the point lets you get perfectly aligned columns in a tabular printout without a lot of fuss.

I wrote a class that I've been using to test these formats out with (attached).  I use it like this:

>>> from efloat impot EFloat as E

it has a class "precision" value that you can set:

>>> E.precision = 5
>>> E(math.pi)
3.14159e+0
>>> E(math.pi / 1e-9)
3.14159e+9
>>> E(math.pi / 1e-2)
314.15927e+0
>>> E(math.pi / 1e-5)
314.15927e+3

It has a slight bug, though.  It doesn't give me two digits of exponent, which would be required in the engineering format specifier, IMHO, so that programmers can easily get constant tabular column widths.

----------
nosy: +Keith.Brafford
Added file: http://bugs.python.org/file17111/efloat.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Tue Apr 27 21:55:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 19:55:45 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272398145.65.0.689379751837.issue7865@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I just tried the patch. One problem is that you are supposed to be able to call close() several times without having it fail:

>>> f = open("LICENSE")
>>> f.close()
>>> f.close()
>>> f = io.open("LICENSE")
>>> f.close()
>>> f.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

This means your patch should be a little smarter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:03:01 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Apr 2010 20:03:01 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272398581.89.0.105987222591.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

astraw: I've been playing with stdeb.  I think it's a nice implementation of bdist_deb, but it doesn't seem to include the dh_make/debianize functionality of this patch.  Is that the case or have I missed something?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:10:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 20:10:20 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272399020.17.0.879062892856.issue7079@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your proposal looks reasonable.
Two things:
- your patch should include an unit test (see Lib/test/test_file2k.py)
- fileobject.c should use tabs for indentation, not spaces

And you're right, py3k doesn't have this problem.

----------
nosy: +pitrou, tim_one
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:14:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 27 Apr 2010 20:14:29 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272399269.44.0.478171811957.issue1054967@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

There has been a number of discussions about bdist_deb, and some code too. I don?t have links handy, unfortunately, but I remember a conclusion that was: Don?t.

 Debian packages are best made by Debian tools, which go to great lengths to comply with Debian Policy, work together, and are frequently updated. On the Distutils(2) site, the most we can do would be a bdist_dsc command that produces a special file which is used by debianizing tools.

 A key thing to remember is that .deb is not just a file format, it?s the embodiment of a Policy (the real value of Debian is its policy, not its package manager?a nice technical side effect), and as such, best handled by Debian tools.

Disclaimers: I?ve not been following packaging discussions for long, these lines are a summary of other people?s thoughts, I?m not a Debian developer or maintainer.

Cheers

----------
components: +Distutils2 -Distutils
nosy: +merwok
versions: +Python 2.5, Python 2.6, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:22:24 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Apr 2010 20:22:24 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272399744.79.0.624126839659.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

There are really two aspects of this patch.  At the moment, I'm less interested in bdist_deb than I am in the 'debianize' (i.e. dh_make) functionality.  I think 'python setup.py debianize' (or whatever) would be a nice way to jump start a debian/ directory from the available metadata.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:26:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 27 Apr 2010 20:26:52 +0000
Subject: [issue1054967] bdist_deb - Debian packager
In-Reply-To: <1272399744.79.0.624126839659.issue1054967@psf.upfronthosting.co.za>
Message-ID: <4BD7487E.6080709@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Why not use Debian?s dh_make?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:31:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:31:22 +0000
Subject: [issue1404] warnings module bug: BytesWarning: str() on a bytes
	instance
In-Reply-To: <1194530562.67.0.490755632259.issue1404@psf.upfronthosting.co.za>
Message-ID: <1272400282.91.0.882547528097.issue1404@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1404>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:31:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:31:38 +0000
Subject: [issue1601] IDLE not working correctly on Windows (Py30a2/IDLE30a1)
In-Reply-To: <1197450599.05.0.953423788601.issue1601@psf.upfronthosting.co.za>
Message-ID: <1272400298.55.0.65960464558.issue1601@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1601>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:31:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:31:51 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1272400311.01.0.624438535043.issue3947@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:32:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:32:07 +0000
Subject: [issue5249] Fix strftime on windows.
In-Reply-To: <1234542248.51.0.455809582678.issue5249@psf.upfronthosting.co.za>
Message-ID: <1272400327.16.0.967158346114.issue5249@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5249>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:32:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:32:23 +0000
Subject: [issue5273] 3.0.1 crashes in unicode path
In-Reply-To: <1234697173.89.0.607307713692.issue5273@psf.upfronthosting.co.za>
Message-ID: <1272400343.59.0.512622014634.issue5273@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5273>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:32:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:32:39 +0000
Subject: [issue5334] array.fromfile() fails to insert values when EOFError is
	raised
In-Reply-To: <1235189293.4.0.0829880938906.issue5334@psf.upfronthosting.co.za>
Message-ID: <1272400360.0.0.272746915333.issue5334@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5334>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:33:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:33:05 +0000
Subject: [issue6150] test_unicode fails in wide unicode build
In-Reply-To: <1243716302.52.0.46548419038.issue6150@psf.upfronthosting.co.za>
Message-ID: <1272400385.12.0.112034259732.issue6150@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6150>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:33:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:33:24 +0000
Subject: [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1272400404.43.0.172956845145.issue6453@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:33:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 20:33:34 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1272400414.8.0.541603170414.issue7540@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:38:58 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Apr 2010 20:38:58 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272400738.2.0.520684092469.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

That's essentially what I want, except I want to feed dh_make some better defaults based on metadata that already lives in setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:54:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Apr 2010 20:54:21 +0000
Subject: [issue7027] test_io.py: codecs.IncrementalDecoder is sometimes None
In-Reply-To: <1254358899.51.0.885628036765.issue7027@psf.upfronthosting.co.za>
Message-ID: <1272401661.81.0.699308832682.issue7027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_io and test_codecs didn't fail in the last build of x86 Tiger 2.6 and x86 Windows7 2.6. I suppose that the issue is now closed. Repopen the issue if it's not the case.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7027>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:56:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 20:56:43 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

We should expose SSL contexts at the Python level, and rework SSL sockets to use those objects internally (rather than creating their own private context).
It would allow to:
- specify the various options iteratively, rather than having to dump them all in the wrap_socket() arguments
- add methods to query information about the current options, key/cert, etc.
- solve issue3823 (you can build the context first, passing it the key/cert info, then drop privileges before creating any sockets)
- more easily share and reuse configuration information
- possibly add more powerful functionality such as sessions

The way I see it, the existing wrap_socket() module-level function would be kept for compatibility; context objects would expose their own wrap_socket() method, without all the arguments of course.

----------
components: Library (Lib)
messages: 104359
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose SSL contexts
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Tue Apr 27 22:59:51 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 27 Apr 2010 20:59:51 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1272401991.16.0.932591544641.issue8550@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

For reference:

http://pyopenssl.sourceforge.net/pyOpenSSL.html/openssl-context.html
http://www.heikkitoivonen.net/m2crypto/api/M2Crypto.SSL.Context%27.Context-class.html

and `man -k SSL_CTX_`

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:02:27 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Apr 2010 21:02:27 +0000
Subject: [issue8546] The parameter buffering in _pyio.open doesn't work the
	same as in the builtin open
In-Reply-To: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>
Message-ID: <1272402147.19.0.425487422872.issue8546@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80544.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8546>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:06:49 2010
From: report at bugs.python.org (Fran Rogers)
Date: Tue, 27 Apr 2010 21:06:49 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1272402409.31.0.0991940483434.issue1284316@psf.upfronthosting.co.za>


Fran Rogers <fran at dumetella.net> added the comment:

I'd like to concur that Python should install to %ProgramFiles% by default. The root-directory default is particularly anomalous on 64-bit Windows, where you have separate 64- and 32-bit Program Files directories; if I have a Python installation in "C:\Python26", is it amd64 Python or x86 Python? If I want to install both (since many packages don't yet support amd64), which one should I install to \Python26 and which should I rename?

As mel's post above (2005-11-15 11:39) points out, installing to C:\ is comparable to installing to /python2.6 on a Unix box; it's nonstandard, inelegant, and prone to ACL problems like the one this bug was opened for. If convenience on the command line (for non-power-users unfamiliar with %Path%) is the concern, a better solution would be a checkbox in the installer to add the new Python to the system %Path%.

----------
nosy: +fran.rogers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:09:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:09:01 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1272402541.46.0.910579286654.issue4870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch for py3k (the previous one didn't apply cleanly).

----------
Added file: http://bugs.python.org/file17112/sslopts2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:16:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:16:05 +0000
Subject: [issue3596] Provide a way to disable SSLv2 (or better yet,
	disable by default)
In-Reply-To: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
Message-ID: <1272402965.75.0.041453888712.issue3596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Someone else requested it and even provided a patch. See you on issue4870.

----------
resolution: out of date -> duplicate
status: pending -> closed
superseder:  -> ssl module is missing SSL_OP_NO_SSLv2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3596>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:26:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:26:08 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1272403568.11.0.177877728741.issue2550@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is now fixed, right? Personal experience as well as buildbot behaviour seems to show that parallel test execution (either through -j, or by running several test suites at the same time) works ok.

----------
nosy: +exarkun, pitrou
resolution: accepted -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2550>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:31:39 2010
From: report at bugs.python.org (=?utf-8?b?RnJlZHJpayBIw6XDpXJk?=)
Date: Tue, 27 Apr 2010 21:31:39 +0000
Subject: [issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1272403899.79.0.904968167388.issue6662@psf.upfronthosting.co.za>


Changes by Fredrik H??rd <fredrik.haard at gmail.com>:


----------
nosy: +fredrik.haard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:37:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:37:48 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1272404268.13.0.780513026537.issue8086@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks reasonable enough.

----------
nosy: +pitrou
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:38:25 2010
From: report at bugs.python.org (=?utf-8?b?RnJlZHJpayBIw6XDpXJk?=)
Date: Tue, 27 Apr 2010 21:38:25 +0000
Subject: [issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1272404305.3.0.595496433632.issue6662@psf.upfronthosting.co.za>


Fredrik H??rd <fredrik.haard at gmail.com> added the comment:

Is there a reason for HTMLParser to treat anything that does not match  the regex '&#\d+;' as a charref?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:39:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:39:27 +0000
Subject: [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1272404367.93.0.948185470568.issue8106@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

issue8550 is probably a prerequisite for implementing this properly.

----------
dependencies: +Expose SSL contexts
nosy: +pitrou
stage:  -> needs patch
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8106>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:40:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:40:25 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1272404425.15.0.357990702987.issue6560@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:41:48 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 27 Apr 2010 21:41:48 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272404508.22.0.728667364903.issue7946@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

> In Windows the high-precision counter might return different results
> on different cores in some hardware configurations (older multi-core
> processors).

More specifically: some older multi-core processors where the HAL implements QueryPerformanceCounter using the TSC from the CPU, and the HAL doesn't keep the cores in sync and QPC doesn't otherwise account for it.  This is rare; frequently QPC is implemented using another source of time.

But it's true: QPC is not 100% reliable.  QPC can unfortunately jump backwards (when using TSC and you switch cores), jump forwards (when using TSC and you switch cores, or when using the PCI bus timer on P3-era machines with a specific buggy PCI south bridge controller), speed up or slow down (when using TSC and not accounting for changing CPU speed via SpeedStep &c).  The simple solution: give up QPC and use timeGetTime() with timeBeginPeriod(1), which is totally reliable but only has millisecond accuracy at best.

http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:42:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:42:47 +0000
Subject: [issue3212] ssl module - should test for a wrong cert
In-Reply-To: <1214505254.08.0.113211233471.issue3212@psf.upfronthosting.co.za>
Message-ID: <1272404567.28.0.163929057415.issue3212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so it was fixed.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3212>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:46:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:46:17 +0000
Subject: [issue5565] Strange behavior when I logout() with IMAP4_SSL
In-Reply-To: <1238051545.58.0.380777960062.issue5565@psf.upfronthosting.co.za>
Message-ID: <1272404777.1.0.495140524148.issue5565@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Do you still witness the issue?
Could you post a small code sample showing the problem with IMAP4_SSL?

(it's not obvious it's a Python problem at all; details of the TCP implementation are obviously handled by the OS, and Python only uses the standard C socket API -- recv(), send() and friends)

----------
nosy: +pitrou
type:  -> behavior
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5565>
_______________________________________

From report at bugs.python.org  Tue Apr 27 23:49:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 21:49:24 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1272404964.79.0.252722522974.issue1251@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

do_handshake() not respecting the socket timeout was fixed in r80452.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1251>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:05:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Apr 2010 22:05:35 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1272405935.35.0.22887799397.issue6656@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed a very slightly modified version of the patch to trunk in r80512, and to py3k in 80521.  I'm leaving this issue open and, unless there is an objection, if no problems show up after the next beta has been out for a while, I'll backport the fix to 2.6 and 3.1.

----------
keywords:  -needs review
resolution:  -> fixed
stage: patch review -> committed/rejected
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:10:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 22:10:06 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1272406206.41.0.403177217498.issue8086@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r80557 (trunk) and r80558 (2.6). 3.1 and 3.2 weren't affected, but I still merged in the additional tests. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:15:28 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 27 Apr 2010 22:15:28 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1272406528.2.0.571118405063.issue8550@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:20:22 2010
From: report at bugs.python.org (David Albert Torpey)
Date: Tue, 27 Apr 2010 22:20:22 +0000
Subject: [issue8551] Start argument for str.rfind used incorrectly
In-Reply-To: <1272406821.86.0.455746879552.issue8551@psf.upfronthosting.co.za>
Message-ID: <1272406821.86.0.455746879552.issue8551@psf.upfronthosting.co.za>


New submission from David Albert Torpey <dtorp at users.sourceforge.net>:

The purpose of the start argument in str.find() and str.rfind() is to allow for repeated searches.  

>>> def find_third_occurrence(s, value):
...	p = s.find(value)
...	p = s.find(value, p+1)
...	return s.find(value, p+1)
...
>>> find_third_occurrence('scientific american', 'c')
16

The rfind() method is meant for searching from the right, but its start argument is used internally as if it were searching from the left.  This bug makes it useless for repeated searches from the right.

>>> 'scientific american'.rfind('c')
16
>>> 'scientific american'.rfind('c', 15)
16
>>> 'scientific american'.rfind('c', 14)
16

Having found the first 'c' from the right at position 16, there is no way to tell it to search further from the right and find the second 'c' at position 9.

----------
components: Interpreter Core
messages: 104375
nosy: dtorp
priority: normal
severity: normal
status: open
title: Start argument for str.rfind used incorrectly
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8551>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:43:48 2010
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 27 Apr 2010 22:43:48 +0000
Subject: [issue3216] Scarce msilib documentation
In-Reply-To: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>
Message-ID: <1272408228.97.0.622054514828.issue3216@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Here's another one:

class Directory shows an extra arg, "component", which isn't in the code.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3216>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:48:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 27 Apr 2010 22:48:07 +0000
Subject: [issue1636] Execfile unable to take arguments beyond 255!
In-Reply-To: <1197767959.22.0.840307964309.issue1636@psf.upfronthosting.co.za>
Message-ID: <1272408487.07.0.750641034133.issue1636@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I don't have much to contribute other than a simple test to reproduce the issue:

>>> code = """                                                                                                                                                                                  
... def f(%s):                                                                                                                                                                                  
...   pass                                                                                                                                                                                      
... """ % ','.join('a%d' % i for i in range(300))
>>> exec(code)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2
SyntaxError: more than 255 arguments

----------
nosy: +Alexander.Belopolsky
Added file: http://bugs.python.org/file17113/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1636>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:53:27 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Apr 2010 22:53:27 +0000
Subject: [issue8551] Start argument for str.rfind used incorrectly
In-Reply-To: <1272406821.86.0.455746879552.issue8551@psf.upfronthosting.co.za>
Message-ID: <1272408807.16.0.478154406672.issue8551@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is in intentional for consistency with find().

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8551>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:55:51 2010
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 27 Apr 2010 22:55:51 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

I'm trying to create a CAB file containing about 69MB of data, in 4555 files.  msilib fails in CAB.commit():

$ python build-msi-installer.py /c/UpLib/1.7.9 ~/uplib 1.7.9 ./uplib-1.7.9.msi
c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.9.msi
install_location c:/UpLib/1.7.9
c:\docume~1\wjanssen\locals~1\temp\tmpu5dwz6 68943045
gc: collecting generation 0...
gc: objects in each generation: 670 702 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 707 1364 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 699 2031 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 794 2680 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 730 3373 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 765 4018 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 741 4697 8255
gc: done, 0.0000s elapsed.
(1, 4555, None, '#prereqs', None, None)
Traceback (most recent call last):
  File "build-msi-installer.py", line 780, in <module>
    p.run()
  File "build-msi-installer.py", line 243, in run
    self.add_files()
  File "build-msi-installer.py", line 312, in add_files
    cab.commit(self.db)
  File "c:\Python26\lib\msilib\__init__.py", line 223, in commit
    [(1, self.index, None, "#"+self.name, None, None)])
  File "c:\Python26\lib\msilib\__init__.py", line 97, in add_data
    v = db.OpenView("SELECT * FROM `%s`" % table)
_msi.MSIError: 1: 2229 2: c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.9.msi 3: Media 4: SELECT * FROM `Media` 
gc: collecting generation 2...
gc: objects in each generation: 416 5351 8254
gc: done, 0.0000s elapsed.
$

(I added a bit of code to print out the Media table record, and the size of the file created with FCICreate.)

This works fine if I choose a slightly smaller subset, such as /c/UpLib/1.7.9/lib, for instance.  So I'm guessing this is a memory problem; at some point there's just not enough memory to open the MSI file and load the Media table.

I opened the MSI file with orca and sure enough, there is no Media table in it.  Not sure how to take that, though;  perhaps the table only appears after a record has been written to it.

Another reason to allow multiple CAB files in a single installer?

----------
components: Library (Lib), Windows
messages: 104379
nosy: janssen, loewis
priority: normal
severity: normal
status: open
title: msilib can't create large CAB files
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:56:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 22:56:12 +0000
Subject: [issue1636] Execfile unable to take arguments beyond 255!
In-Reply-To: <1197767959.22.0.840307964309.issue1636@psf.upfronthosting.co.za>
Message-ID: <1272408972.46.0.69828088191.issue1636@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing it as "won't fix": nobody is really interested in working on the problem.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1636>
_______________________________________

From report at bugs.python.org  Wed Apr 28 00:59:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 27 Apr 2010 22:59:07 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <4BD76C38.5020206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Another reason to allow multiple CAB files in a single installer?

I'm still curious as to what the first reason is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Wed Apr 28 01:37:15 2010
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Apr 2010 23:37:15 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1272411435.64.0.0634093659124.issue7833@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

the pywin32 DLLs have 2 heads.  They are Python extension modules as well as regular DLLs.  They are built by distutils and therefore have no manifests - I think many packages use distutils to build their extension modules - it is just that they usually don't have a .dll extension.

I fear that simply adding a manifest to those DLLs will put them in the same position we have before issue4120 was addressed, and these .dlls do need a way to be installed into System32 (or somewhere else on the global PATH) to function as COM servers etc.  I need to experiment with this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Wed Apr 28 01:44:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 23:44:15 +0000
Subject: [issue808164] socket.close() doesn't play well with __del__
Message-ID: <1272411855.64.0.356407583052.issue808164@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, realistically, if you have open sockets at shutdown, there isn't a big difference between closing and not closing them. They will be reaped with the process anyway.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue808164>
_______________________________________

From report at bugs.python.org  Wed Apr 28 01:45:46 2010
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Apr 2010 23:45:46 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1272411946.55.0.990593430088.issue1284316@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Another consideration here will be how distutils will work in a python with restricted permissions - the pattern of "just run 'setup.py install'" will not work unless it is done from an elevated command-prompt.  As I expect this would frustrate people we'd need some story to address this.

My take is still that Python is a tool, not an app.  People writing an app they with to distribute using Python should include Python in their package (ie, not rely on an installed version) and these apps should conform with the guidelines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Wed Apr 28 02:09:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 28 Apr 2010 00:09:37 +0000
Subject: [issue808164] socket.close() doesn't play well with __del__
Message-ID: <1272413377.85.0.0220688181286.issue808164@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

The purpose of calling .close() in __del__ is to close the socket when the owner is destroyed yet the program is still running.

This prevents the socket from staying open if some other part of the program has somehow acquired a reference to it.  telnetlib, urllib, and even the socket module itself contain classes that call .close() within __del__ for this purpose.

Unfortunately, that can result in ugly error messages when the interpreter is exiting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue808164>
_______________________________________

From report at bugs.python.org  Wed Apr 28 02:10:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 00:10:43 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1272413443.44.0.225367398969.issue8404@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Wed Apr 28 02:15:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 00:15:04 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1272413704.5.0.670492598193.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited the patch into small parts:

1 (r80552): fix test_support.py for Python compiled without thread
2 (r80553): regrtest.py -j option requires thread support
3 (r80554): test_doctest: import trace module in test_coverage()
4 (r80555): skip test_multiprocessing if thread support is disabled
5 (r80556, r80569): split Test.test_open() of ctypes/test/test_errno.py
6 (r80564): fix test_hashlib for missing threading module
7 (r80565): simplify threading detection in test_capi
8 (r80566): don't skip the whole test_asynchat if threading is missing
9 (r80568): fix test_xmlrpclib for missing threading module
10 (r80570): test_cmd imports trace module using test_support.import_module()
11 (r80571): fix many tests if thread support is disabled

I created the patch to Jerry Seutter in the Misc/NEWS file.

I'm waiting for the buildbot tests to port the commits to py3k. First commit of Part 5 (r80556) was wrong: I fixed it with a new commit (r80569).

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Wed Apr 28 02:24:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 28 Apr 2010 00:24:10 +0000
Subject: [issue1054967] bdist_deb - Debian packager
In-Reply-To: <1272400738.2.0.520684092469.issue1054967@psf.upfronthosting.co.za>
Message-ID: <4BD78023.20002@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Thanks for clarifying your point.

Note that I had quickly tested dh_make in a near-empty directory before
posting, and the only question I got asked was the type of the package
(library, many libraries, program, etc). But I?ve just realized that I
have two dh_make-related variables set in my environment, plus maybe
config files, so a typical user may have more questions to answer, which
is annoying if the setup.cfg? already has them. And to be honest, the
question about the type of the package is not simple if you?re not
fluent with the Policy, so if Distutils2 can answer that thanks to its
knowledge, all the better. I therefore agree with you :)

One thing I?m attached to: The name of the command should respect
existing conventions. Entirely new concepts get dedicated names (e.g.
?check? and ?test?), but commands fitting in the areas of sdist or bdist
should say so in their name. How about sdist_debian?

It may be useful to precise something at this point: You may read about
both ?debian? and ?Debian? packages. ?debian? or ?.deb? or ?debs? are
binary distributions that use the file formats defined by Debian,
whereas ?Debian? packages are binary distributions that use these
formats, conform to the Debian policy, are tested on lintian.debian.org
and piuparts.debian.org, and most importantly, are scrutinized for
Debian Free Software Guidelines compliance. That?s why I, for one, never
uses third-party deb packages or apt repos: If it?s going to be
installed system-wide, I want a verified Debian package.

HTH

? Not a typo, just an anticipation of PEP 390 ;)

Kind regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Wed Apr 28 02:28:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Apr 2010 00:28:19 +0000
Subject: [issue8551] Start argument for str.rfind used incorrectly
In-Reply-To: <1272406821.86.0.455746879552.issue8551@psf.upfronthosting.co.za>
Message-ID: <1272414499.69.0.99572026245.issue8551@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I thought Benjamin's answer was crazy until I looked at the help for find/rfind.  The optional 'start, end' arguments are interpreted like slice notation, so it does make sense to have the interpretation be the consistent between find and rfind.

----------
nosy: +r.david.murray
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8551>
_______________________________________

From report at bugs.python.org  Wed Apr 28 02:31:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 00:31:21 +0000
Subject: [issue2331] Backport parameter annotations
In-Reply-To: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za>
Message-ID: <1272414681.2.0.120426294309.issue2331@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Can this be closed, either as 'fixed' or 'obsolete' (too late)?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2331>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:12:59 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 28 Apr 2010 01:12:59 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272417179.58.0.547747078017.issue8552@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Ummm, just in case the packager wanted to.

In my case, I was putting the files which were registered as part of the installation in one CAB file, and another set of temporary files which were used by some of the installation scripts, but not part of the installation file set, in a second CAB file.  I've since changed that second package to a zip file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:14:50 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 28 Apr 2010 01:14:50 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272417290.82.0.86518355826.issue8552@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

So, I subclassed msilib.CAB, and re-wrote commit() so that the CAB file is created in a different process, a la Tools/msi/msilib.py.  Still have the same problem, though.  So now I'm thinking it's not a memory problem, but I'm wondering if there's something about the length of the path names in the CAB file, or some such.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:18:32 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 28 Apr 2010 01:18:32 +0000
Subject: [issue8553] 2to3 breaks relative imports
In-Reply-To: <1272417512.55.0.562035321264.issue8553@psf.upfronthosting.co.za>
Message-ID: <1272417512.55.0.562035321264.issue8553@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

2to3, at least the version in the python-2 tree, currently turns

  from . import refactor

into

  from .. import refactor

which breaks the transformation of 2to3 itself.  The attached patch fixes this and tests it.

Once someone's looked this over, where should I commit it? I'm not sure where 2to3 actually lives anymore.

----------
components: Library (Lib)
files: 2to3_fix.patch
keywords: needs review, patch, patch
messages: 104392
nosy: jyasskin
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 breaks relative imports
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17114/2to3_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8553>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:31:32 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 28 Apr 2010 01:31:32 +0000
Subject: [issue8554] suspicious comment in msilib.py/__init__.py
In-Reply-To: <1272418292.04.0.0208509109493.issue8554@psf.upfronthosting.co.za>
Message-ID: <1272418292.04.0.0208509109493.issue8554@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Take a look at the first line of make_id().  What does that comment mean?  Is the wrong line commented out?

def make_id(str, add_num=True):
    #str = str.replace(".", "_") # colons are allowed

----------
components: Library (Lib), Windows
messages: 104393
nosy: janssen, loewis
priority: low
severity: normal
status: open
title: suspicious comment in msilib.py/__init__.py
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8554>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:31:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 28 Apr 2010 01:31:48 +0000
Subject: [issue8553] 2to3 breaks relative imports
In-Reply-To: <1272417512.55.0.562035321264.issue8553@psf.upfronthosting.co.za>
Message-ID: <1272418308.28.0.56016800276.issue8553@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I believe sandbox/trunk/2to3 is the right spot. The patch seems ok to me, but Benjamin will probably want a look.

----------
nosy: +benjamin.peterson, brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8553>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:34:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Apr 2010 01:34:53 +0000
Subject: [issue2331] Backport parameter annotations
In-Reply-To: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za>
Message-ID: <1272418493.71.0.424082870125.issue2331@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2331>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:35:09 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Apr 2010 01:35:09 +0000
Subject: [issue2331] Backport parameter annotations
In-Reply-To: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za>
Message-ID: <1272418509.94.0.449113892154.issue2331@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution: invalid -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2331>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:39:49 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Apr 2010 01:39:49 +0000
Subject: [issue8553] 2to3 breaks relative imports
In-Reply-To: <1272417512.55.0.562035321264.issue8553@psf.upfronthosting.co.za>
Message-ID: <1272418789.23.0.820716681278.issue8553@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please use double quotes and unicode literals. Otherwise, it's fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8553>
_______________________________________

From report at bugs.python.org  Wed Apr 28 03:47:36 2010
From: report at bugs.python.org (py.user)
Date: Wed, 28 Apr 2010 01:47:36 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

[guest at station ~]$ python3
Python 3.1.2 (r312:79147, Apr 28 2010, 11:57:19)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+2
3
>>> import tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.1/tkinter/__init__.py", line 39, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named _tkinter
>>>

----------
components: Tkinter
messages: 104397
nosy: py.user
priority: normal
severity: normal
status: open
title: tkinter doesn't see _tkinter
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8555>
_______________________________________

From report at bugs.python.org  Wed Apr 28 04:01:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 28 Apr 2010 02:01:55 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272420115.25.0.490621592491.issue8555@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Did you compile Python yourself or did this come on your OS? The comment in the traceback pretty much says it all.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8555>
_______________________________________

From report at bugs.python.org  Wed Apr 28 04:13:18 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 02:13:18 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1272420798.61.0.532901537057.issue7511@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tarek, when you set the resolution to 'accepted', did you mean to close this? Resolutions are meant for closed issues.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Wed Apr 28 04:25:22 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 02:25:22 +0000
Subject: [issue4186] type() doesn't accept bases and dict keyword arguments
In-Reply-To: <1224753211.57.0.0760272194538.issue4186@psf.upfronthosting.co.za>
Message-ID: <1272421522.99.0.00887489680597.issue4186@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since 'pending' is not implemented, should this be 'closed'?

----------
nosy: +tjreedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4186>
_______________________________________

From report at bugs.python.org  Wed Apr 28 04:25:52 2010
From: report at bugs.python.org (py.user)
Date: Wed, 28 Apr 2010 02:25:52 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272421552.8.0.313940722608.issue8555@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

I have downloaded Python today (28 Apr) from the site
I have a version under WinXP (it works fine), but I don't use WinXP
When it told this about _tkinter, I even read the README file and compiled it with "make test", and there the same thing, it couldn't find _tkinter
as for Python2.5 it's allright, but it has another Tkinter, so sources are not portable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8555>
_______________________________________

From report at bugs.python.org  Wed Apr 28 04:29:55 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 02:29:55 +0000
Subject: [issue3620] test_smtplib is flaky
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1272421795.46.0.229749977932.issue3620@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3620>
_______________________________________

From report at bugs.python.org  Wed Apr 28 04:32:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 02:32:02 +0000
Subject: [issue2340] Backport PEP 3132 (extended iterable unpacking)
In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za>
Message-ID: <1272421922.95.0.672315912736.issue2340@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Fixed?, Out-of-date? (or in process?)

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2340>
_______________________________________

From report at bugs.python.org  Wed Apr 28 04:33:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 02:33:53 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1272422033.86.0.0722258160784.issue3080@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Apr 28 05:19:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Apr 2010 03:19:54 +0000
Subject: [issue2340] Backport PEP 3132 (extended iterable unpacking)
In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za>
Message-ID: <1272424794.5.0.290770394516.issue2340@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2340>
_______________________________________

From report at bugs.python.org  Wed Apr 28 05:23:46 2010
From: report at bugs.python.org (Robert Coup)
Date: Wed, 28 Apr 2010 03:23:46 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1272425026.78.0.637611004984.issue6312@psf.upfronthosting.co.za>


Changes by Robert Coup <robert at coup.net.nz>:


----------
nosy: +rcoup

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Wed Apr 28 05:29:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 28 Apr 2010 03:29:33 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272425373.99.0.997817301596.issue2810@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

test_changing_value is giving inconsistent results when the _winreg.c patch is not applied. It mostly fails on QueryValue, sometimes on EnumValue, and about 1/10 times the test does not fail at all. Ideally the tests should not use threads -- can the same thing be tested without a thread? It seems like the issue isn't related to concurrency, but maybe I missed something.

With _winreg.c patched, the tests seem to pass, but I haven't run that as much as I have the unpatched version.

winreg_test.pach
- test_changing_value (assuming we need do this as a thread)
-- I'd just use HKEY_CURRENT_USER directly instead of storing it locally
-- done doesn't need to be a list, it could just be the True/False
-- the if/else could be shortened to `s = "x" if short else "x"*2000`

- test_long_key
-- After SetValue I'd just call EnumKey(key, 0) since you can only ever have that value to use. The loop isn't really used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed Apr 28 05:38:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 28 Apr 2010 03:38:09 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1272425889.35.0.554869213294.issue6312@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I can take this up. The HEAD requests does not contain any data, so when the data is None and transfer encoding is chunked, we can return empty value for the next step. No need of attempting to read the chuncked amt. The patch is fine and tests need to be added.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Wed Apr 28 05:47:28 2010
From: report at bugs.python.org (py.user)
Date: Wed, 28 Apr 2010 03:47:28 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272426448.56.0.455648747365.issue8555@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

tryed also:
[root at station python3.1]# cp /usr/lib/python2.5/lib-dynload/_tkinter.so lib-dynload

answer is:
Traceback (most recent call last):
  File "/home/guest/tmp/code/c/eclipse/pytest/src/main.py", line 4, in <module>
    import tkinter
  File "/usr/local/lib/python3.1/tkinter/__init__.py", line 39, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: /usr/local/lib/python3.1/lib-dynload/_tkinter.so: undefined symbol: _Py_ZeroStruct

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8555>
_______________________________________

From report at bugs.python.org  Wed Apr 28 06:00:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 28 Apr 2010 04:00:35 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272427235.34.0.56217803441.issue2810@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

After a quick glance, the _winreg.c changes look ok. I'll try to fit in a review shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed Apr 28 06:08:43 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 28 Apr 2010 04:08:43 +0000
Subject: [issue8553] 2to3 breaks relative imports
In-Reply-To: <1272417512.55.0.562035321264.issue8553@psf.upfronthosting.co.za>
Message-ID: <1272427723.3.0.230272804708.issue8553@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Thanks! Committed as r80573.

----------
keywords:  -needs review
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8553>
_______________________________________

From report at bugs.python.org  Wed Apr 28 06:17:02 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 28 Apr 2010 04:17:02 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272428222.84.0.722116813556.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thank for the feedback.  I'll revise the patch tomorrow based on your code-cleanup suggestions.

To answer your question about the thread and explain why the test sometimes passes:

The goal of test_changing_value is to try to trigger a race condition that exists inside many of these function.  So, yes, the thread is necessary. :) Thankfully the functions call Py_BEGIN_ALLOW_THREADS; otherwise, I'd have to launch another process to try to trigger it.

Sometimes we never manage to hit the race condition and the test passes even though the bug is present.  I can increase the number of attempts to trigger it (currently "for _ in range(100)") to make it more likely to occur every time the test is run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed Apr 28 06:27:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 28 Apr 2010 04:27:59 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272428879.43.0.144001967903.issue8555@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

>From your prompt, it seems you are on Unix based system. make would have informed you about _tkinter not built.

If you are on ubuntu, do a sudo apt-get install tk-dev  and install tk-dev package and its dependencies.
And then do the ./configure;make;sudo make install 
python3.1 will have the tkinter libraries and the _tkinter module installed. If on another distro, just make sure you have latest tk-dev libraries (headers) installed.

I don't see any other problem here, so I am closing this issue.

----------
nosy: +orsenthil
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8555>
_______________________________________

From report at bugs.python.org  Wed Apr 28 06:57:29 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Wed, 28 Apr 2010 04:57:29 +0000
Subject: [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>


New submission from Jeff McNeil <jeff at jmcneil.net>:

I was going through the string formatting examples this evening and noticed this:

print '%(language)s has %(#)03d quote types.' % \
          {'language': "Python", "#": 2}


The example uses a '#' as a map key. This is somewhat misleading as if we had simply left the parenthesis off, the '#' would have been interpreted as an alternate conversion flag. Should be updated to use a more verbose (and less confusing) dictionary key.

----------
assignee: docs at python
components: Documentation
files: stdtypes.rst.2.6.5.patch
keywords: patch
messages: 104410
nosy: docs at python, mcjeff
priority: normal
severity: normal
status: open
title: Confusing string formatting examples
versions: Python 2.6
Added file: http://bugs.python.org/file17115/stdtypes.rst.2.6.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8556>
_______________________________________

From report at bugs.python.org  Wed Apr 28 07:00:39 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Wed, 28 Apr 2010 05:00:39 +0000
Subject: [issue1666318] shutil.copytree doesn't preserve directory permissions
Message-ID: <1272430839.94.0.887360266748.issue1666318@psf.upfronthosting.co.za>


Changes by Jeff McNeil <jeff at jmcneil.net>:


----------
nosy: +mcjeff -j_mcneil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666318>
_______________________________________

From report at bugs.python.org  Wed Apr 28 07:04:46 2010
From: report at bugs.python.org (Jack Miller)
Date: Wed, 28 Apr 2010 05:04:46 +0000
Subject: [issue6091] Curses segfaulting in FreeBSD/amd64
In-Reply-To: <1243044628.32.0.644486843257.issue6091@psf.upfronthosting.co.za>
Message-ID: <1272431086.83.0.15434345129.issue6091@psf.upfronthosting.co.za>


Jack Miller <jack at codezen.org> added the comment:

The rest of my codebase is currently only 2.x compatible, but I saw identical symptoms about a month ago on Fedora/Mandriva when their 2.x packages were linked against non-widechar libraries so I imagine that is indeed the solution.

I'll close the bug when I can either wrap the code for 3.x or get a 2.x FreeBSD build with those changes.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6091>
_______________________________________

From report at bugs.python.org  Wed Apr 28 07:59:11 2010
From: report at bugs.python.org (py.user)
Date: Wed, 28 Apr 2010 05:59:11 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272434351.28.0.474819221528.issue8555@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

ok, thank you
I found that I have no tcl.h and tk.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8555>
_______________________________________

From report at bugs.python.org  Wed Apr 28 08:25:24 2010
From: report at bugs.python.org (py.user)
Date: Wed, 28 Apr 2010 06:25:24 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272435924.15.0.788324282725.issue8555@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

allright I installed two -dev packages and ran tkinter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8555>
_______________________________________

From report at bugs.python.org  Wed Apr 28 08:37:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 28 Apr 2010 06:37:53 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272436673.57.0.444406413209.issue8552@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You could also try to commit the MSI file in-between, which may release memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Wed Apr 28 08:49:53 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 28 Apr 2010 06:49:53 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272437393.71.0.76576624242.issue7865@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

I'm quite surprised it wasn't already covered by the test suite :S

Anyway I'm quite confused about the semantic which is expected from IO operations...

Should a flush on a closed stream fail (at the moment sometimes it does, sometimes doesn't) ? Why is sometimes ValueError used when I'd rather expect an IOError ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Wed Apr 28 09:29:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 28 Apr 2010 07:29:10 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1272439750.05.0.661744431878.issue1368247@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Hi David,
The attached patch for this issue:

+        if isinstance(payload, unicode):
+            payload = payload.encode(msg.get_charset().output_charset or 'us-ascii')

looks fine enough to me. Are you worried about the /or 'us-ascii'/ part of this patch? 

IMHO, the patch may prevent the straight forward Exception for which the issue was raised.

But on a larger scale, it is advisable to document MIMEText usage wth encoding as you mentioned.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368247>
_______________________________________

From report at bugs.python.org  Wed Apr 28 10:04:43 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 28 Apr 2010 08:04:43 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272441883.3.0.992434219017.issue7584@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Is anyone still interested in this? Is there a problem with my patch?
Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Wed Apr 28 10:29:39 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 Apr 2010 08:29:39 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1272443379.56.0.110008204369.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

So, what about 2.7 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Wed Apr 28 10:44:39 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 Apr 2010 08:44:39 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272444279.86.0.32098060193.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks Daniel. I am still interested in this. My Python code as well as your patch doesn't specify that "Z" must be present when time zone offset is unknown or absent, but Atom specification mentions that and I believe this is that most users expect to see. In fact I needed such function for implementing Atom feed for Trac, so in my opinion Z is more clear than -00:00 or +00:00

I also was waiting for a final resolution of issue7582 which discusses the proper way to get UTC offset. The function used to correctly build RFC 3339 timestamp from file modification time evolved to the following code:

def isomtime(fname):
    """Return file modification time in RFC 3339 (ISO 8601 compliant) format"""
    stamp = time.localtime(os.stat(fname).st_mtime)

    # determine UTC offset rounded to minutes
    # (see http://bugs.python.org/issue7582 for discussion)
    #   true if file was modified during active DST
    isdst = stamp.tm_isdst
    utcoffset = -(time.altzone if (time.daylight and isdst) else time.timezone) // 60

    suffix = "%+03d:%02d" % (utcoffset // 60, abs(utcoffset) % 60)
    return time.strftime("%Y-%m-%dT%H:%M:%S", stamp) + suffix

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Wed Apr 28 12:02:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Apr 2010 10:02:11 +0000
Subject: [issue5565] Strange behavior when I logout() with IMAP4_SSL
In-Reply-To: <1238051545.58.0.380777960062.issue5565@psf.upfronthosting.co.za>
Message-ID: <1272448931.6.0.0243964416102.issue5565@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5565>
_______________________________________

From report at bugs.python.org  Wed Apr 28 12:03:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Apr 2010 10:03:31 +0000
Subject: [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1272449011.36.0.979820816654.issue8106@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8106>
_______________________________________

From report at bugs.python.org  Wed Apr 28 12:08:20 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Apr 2010 10:08:20 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1272449300.76.0.989587476739.issue6560@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Apr 28 12:10:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 10:10:44 +0000
Subject: [issue808164] socket.close() doesn't play well with __del__
In-Reply-To: <1272413377.85.0.0220688181286.issue808164@psf.upfronthosting.co.za>
Message-ID: <1272449579.3485.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Unfortunately, that can result in ugly error messages when the
> interpreter is exiting.

The classical solution is to early bind the necessary globals to
argument defaults, such as:

    def __del__(self, _socketclose=_socketclose):
        _socketclose(self._socket)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue808164>
_______________________________________

From report at bugs.python.org  Wed Apr 28 12:44:54 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 28 Apr 2010 10:44:54 +0000
Subject: [issue8557] subprocess portability issue
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

On POSIX systems, the PATH environment variable is always used to
look up directory-less executable names passed as the first argument to Popen(...), but on Windows, PATH is only considered when shell=True is also passed.  

Actually I think it may be slightly weirder than that when
shell=False, because the following holds for me:

C:\>rem ##### Prepare minimal PATH #####
C:\>set "PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem"

C:\>rem ##### Prepare a minimal, clean environment #####
C:\>virtualenv --no-site-packages e:\zzz
New python executable in e:\zzz\Scripts\python.exe
Installing setuptools................done.

C:\>rem ##### Show that shell=True makes the difference in determining whether PATH is respected #####
C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'])
<subprocess.Popen object at 0x0000000001DBE080>
>>> C:\Python26\python.exe

>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'})
<subprocess.Popen object at 0x0000000001F05A90>
>>> C:\Python26\python.exe

>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}, shell=True)
<subprocess.Popen object at 0x0000000001F05B00>
>>> e:\zzz\Scripts\python.exe

That is, it looks like the environment at the time Python is invoked is what counts unless I pass shell=True.  I don't even seem to be able to override this behavior by changing os.environ: you can clear() it and pass env={} and subprocess.Popen(['python']) still succeeds.

This is a very important problem for portable code and one that took me hours to suss out.  I think:

a) the current behavior needs to be documented
b) it needs to be fixed if possible
c) otherwise, shell=True should be the default

----------
assignee: docs at python
components: Documentation
messages: 104422
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: subprocess portability issue
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Wed Apr 28 12:46:46 2010
From: report at bugs.python.org (holger krekel)
Date: Wed, 28 Apr 2010 10:46:46 +0000
Subject: [issue8558] StringIO().truncate causes zero-bytes in getvalue()
In-Reply-To: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>
Message-ID: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Running the attached file with python3.1.1 works fine, all assertions pass.  Running it with 3.1.2 gives me this output: 

$ python3.1.2/bin/python3.1 stringio_fail.py
Traceback (most recent call last):
  File "stringio_fail.py", line 12, in <module>
    assert s == "world", repr(s)
AssertionError: '\x00\x00\x00\x00\x00world'

----------
components: IO
files: stringio_fail.py
messages: 104423
nosy: hpk
priority: normal
severity: normal
status: open
title: StringIO().truncate causes zero-bytes in getvalue()
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17116/stringio_fail.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8558>
_______________________________________

From report at bugs.python.org  Wed Apr 28 12:58:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 10:58:05 +0000
Subject: [issue8558] StringIO().truncate causes zero-bytes in getvalue()
In-Reply-To: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>
Message-ID: <1272452285.34.0.145757065693.issue8558@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a last-minute API change. truncate() was modified not to change the file position anymore. We should probably document it more explicitly.

See the following subthread in python-dev:
http://mail.python.org/pipermail/python-dev/2009-September/092127.html

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8558>
_______________________________________

From report at bugs.python.org  Wed Apr 28 13:11:52 2010
From: report at bugs.python.org (holger krekel)
Date: Wed, 28 Apr 2010 11:11:52 +0000
Subject: [issue8558] StringIO().truncate causes zero-bytes in getvalue()
In-Reply-To: <1272452285.34.0.145757065693.issue8558@psf.upfronthosting.co.za>
Message-ID: <t2yd235cdc41004280411xfe1004d0jbba190f4dc3dba08@mail.gmail.com>


holger krekel <holger.krekel at gmail.com> added the comment:

Ah, thanks for the pointer.  So indeed, for me truncate(0)+seek(0)
works fine for all interpreters i care for (python2.4 - 3.1.X),
previously truncate(0) was enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8558>
_______________________________________

From report at bugs.python.org  Wed Apr 28 13:22:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 11:22:21 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1272437393.71.0.76576624242.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272453874.3485.10.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm quite surprised it wasn't already covered by the test suite :S

Probably an oversight. Do you want to add some tests?

> Should a flush on a closed stream fail (at the moment sometimes it
> does, sometimes doesn't) ?

It probably should, yes.

> Why is sometimes ValueError used when I'd rather expect an IOError ?

Because it's not an IO error at all. No I/O occurs. You are just using
the file wrongly (or the wrong file), hence the ValueError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Wed Apr 28 14:03:51 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 28 Apr 2010 12:03:51 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1272456231.63.0.103774379751.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Patch committed.

trunk (2.7): r80574
2.6: r80575
py3k (3.2): r80576
3.1: r80577

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Wed Apr 28 14:45:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 12:45:10 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1272458710.12.0.863493003657.issue8550@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +heikki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Wed Apr 28 15:19:10 2010
From: report at bugs.python.org (=?utf-8?b?RnJlZHJpayBIw6XDpXJk?=)
Date: Wed, 28 Apr 2010 13:19:10 +0000
Subject: [issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1272460750.61.0.480745753493.issue6662@psf.upfronthosting.co.za>


Fredrik H??rd <fredrik.haard at gmail.com> added the comment:

Confirmed on trunk.
Attached a (what I think is) minimal patch to fix, together with a tweak of existing unit test case to verify it.

----------
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file17117/Issue6662.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Wed Apr 28 15:22:14 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 28 Apr 2010 13:22:14 +0000
Subject: [issue8557] subprocess portability issue
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272460934.44.0.605237847894.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

It's worse than I thought; there isn't even one setting for shell that works everywhere.  This is what happens on POSIX (tested on Mac and Ubuntu):

$ mkdir /tmp/xxx
$ cd /tmp/xxx
xxx $ virtualenv /tmp/zzz
xxx $ python
Python 2.6.5 (r265:79063, Mar 23 2010, 08:10:08) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import *
>>> p = Popen(['python', '-c', 'import sys;print sys.executable'], 
...           stdin=PIPE,stdout=PIPE,stderr=PIPE,
...           env={'PATH':'/tmp/zzz/bin'})
>>> stdout,stderr = p.communicate(None)
>>> print stdout
/tmp/zzz/bin/python

>>> print stderr

>>> p = Popen(['python', '-c', 'import sys;print sys.executable'], shell=True,
...           stdin=PIPE,stdout=PIPE,stderr=PIPE,
...           env={'PATH':'/tmp/zzz/bin'})
>>> stdout,stderr = p.communicate(None)
>>> print stdout

>>> print stderr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Wed Apr 28 15:58:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 28 Apr 2010 13:58:25 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1272463105.02.0.0322853877188.issue7582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

2.7 is now frozen as far as new features go. It's still good for 3.2.

I think this is ready to go, so I'll probably commit it later in the day.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Wed Apr 28 15:58:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 13:58:59 +0000
Subject: [issue8559] test_gdb: test_strings() fails with ASCII locale
In-Reply-To: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>
Message-ID: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/alpha Debian 3.x/builds/67/steps/test/logs/stdio

======================================================================
ERROR: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 230, in test_strings
    self.assertGdbRepr('\u2620')
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 176, in assertGdbRepr
    cmds_after_breakpoint)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 144, in get_gdb_repr
    import_site=import_site)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 120, in get_stack_trace
    out, err = self.run_gdb(*args)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 60, in run_gdb
    args, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/subprocess.py", line 670, in __init__
    restore_signals, start_new_session)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/subprocess.py", line 1115, in _execute_child
    restore_signals, start_new_session, preexec_fn)
UnicodeEncodeError: 'ascii' codec can't encode character '\u2620' in position 4: ordinal not in range(128)

You can try with: "LANG= ./python Lib/test/regrtest.py test_gdb".

We should skip the test if '\u2620' is not encodable to sys.getfileystemencoding(), or maybe use '\\u2620'.

----------
components: Tests, Unicode
messages: 104431
nosy: dmalcolm, haypo, loewis
priority: normal
severity: normal
status: open
title: test_gdb: test_strings() fails with ASCII locale
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8559>
_______________________________________

From report at bugs.python.org  Wed Apr 28 16:12:28 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 28 Apr 2010 14:12:28 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1272463948.81.0.190421830759.issue1813@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Apr 28 16:31:17 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Apr 2010 14:31:17 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1272465077.49.0.575273621793.issue7490@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed for 2.7 in r80578

I'll forward port to 3.2 at some point after the next 2.7 beta is out.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Wed Apr 28 16:39:25 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Apr 2010 14:39:25 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1272465565.62.0.429373668865.issue5516@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think I'll concur with the "this is a mess" assessment.

Given that state of affairs, punting on this until 3.2 (at the earliest).

----------
assignee: ncoghlan -> 
versions: +Python 3.2 -Python 2.4, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed Apr 28 16:58:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Apr 2010 14:58:15 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1272466695.99.0.288197698274.issue8202@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed for 2.7 in r80580 (as it turns out, the hack I remembered was probably from the original pre-runpy 2.4 implementation and has since been replaced by the proper runpy based system. This bug was likely just a lingering remnant of that original hackish approach).

Will forward port to 3.2 after the 2.7 beta is out.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Wed Apr 28 16:59:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Apr 2010 14:59:26 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1272466766.73.0.674303092342.issue5178@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Missed the boat for 2.7 I'm afraid. Definitely one to take another look at for 3.2 though.

----------
assignee: ncoghlan -> 
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Wed Apr 28 17:05:33 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Apr 2010 15:05:33 +0000
Subject: [issue1644818] Allow importing built-in submodules
Message-ID: <1272467133.01.0.539439104673.issue1644818@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll have a closer look at this tomorrow with the aim of getting it into 2.7b2.

(I'm inclined to agree with jd that this is just a bug in the existing implementation, hence the change in the issue type)

----------
type: feature request -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Wed Apr 28 17:08:05 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Apr 2010 15:08:05 +0000
Subject: [issue5251] contextlib.nested inconsistent with, well,
	nested with statements due exceptions raised in __enter__
In-Reply-To: <1234548570.86.0.145574171135.issue5251@psf.upfronthosting.co.za>
Message-ID: <1272467285.53.0.640685135103.issue5251@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5251>
_______________________________________

From report at bugs.python.org  Wed Apr 28 17:13:54 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 28 Apr 2010 15:13:54 +0000
Subject: [issue8557] subprocess portability issue
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272467634.24.0.333126978766.issue8557@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

IMO there's another problem with subprocess portablity---the lack of control over encodings: see issue 6135.

----------
nosy: +mark

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Wed Apr 28 18:29:17 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 28 Apr 2010 16:29:17 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272436673.57.0.444406413209.issue8552@psf.upfronthosting.co.za>
Message-ID: <m2q4b3e516a1004280929l4d4e11c9j784194830191abc8@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Yes, I've tried that.  No joy.  Right now I'm trying an approach which
packages each top-level directory as a separate cab.

What I'm finding is that if I get up around 4200 files, it breaks,
regardless of the file sizes.  Out of curiosity, how many files are in the
Python MSI file?

Bill

On Tue, Apr 27, 2010 at 11:37 PM, Martin v. L??wis <report at bugs.python.org>wrote:

>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> You could also try to commit the MSI file in-between, which may release
> memory.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8552>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17118/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________
-------------- next part --------------
Yes, I&#39;ve tried that. ??No joy. ??Right now I&#39;m trying an approach which packages each top-level directory as a separate cab.<div><br></div><div>What I&#39;m finding is that if I get up around 4200 files, it breaks, regardless of the file sizes. ??Out of curiosity, how many files are in the Python MSI file?<br>
<div><br></div><div>Bill<br><br><div class="gmail_quote">On Tue, Apr 27, 2010 at 11:37 PM, Martin v. L??wis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Martin v. L??wis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<br>
</div>You could also try to commit the MSI file in-between, which may release memory.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue8552" target="_blank">http://bugs.python.org/issue8552</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div></div>

From report at bugs.python.org  Wed Apr 28 18:57:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 Apr 2010 16:57:10 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1272473830.07.0.992096992531.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I still do not understand your policy - it is a tool, it is not a part of standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Wed Apr 28 19:01:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 17:01:45 +0000
Subject: [issue8560] regrtest: add a minimal "progress bar"
In-Reply-To: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>
Message-ID: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

regrtest takes between 10 and 20 minutes to run the full test suite. It would be nice to see the progress of the test suite with a kind of progress bar. Add the test number would be enough:

$ ./python Lib/test/regrtest.py                             
...
test_grammar (1/340)                                             
test_opcodes (2/340)                                             
test_dict (3/340)                                                
test_builtin (4/340)                                             
test_exceptions (5/340)                                          
test_types (6/340)                                               
test_unittest (7/340)                                            
...

Attached patch implements that (classic version and multiprocess version).

----------
files: regrtest_progress-py3k.patch
keywords: patch
messages: 104440
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: add a minimal "progress bar"
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17119/regrtest_progress-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8560>
_______________________________________

From report at bugs.python.org  Wed Apr 28 19:03:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Apr 2010 17:03:16 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1272474196.86.0.919640162603.issue1462525@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462525>
_______________________________________

From report at bugs.python.org  Wed Apr 28 19:23:22 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 28 Apr 2010 17:23:22 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272475402.44.0.810404485445.issue7865@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

>Probably an oversight. Do you want to add some tests?

That's WIP

> Because it's not an IO error at all. No I/O occurs. You are just using
the file wrongly (or the wrong file), hence the ValueError.

Then when you try to wrap a non-readable stream into a readable buffered stream (like BufferedRWPair), it should raise a value error as well, but currently it's rather:
"""if not reader.readable(): raise IOError('"reader" argument must be readable.')"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Wed Apr 28 19:40:10 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 28 Apr 2010 17:40:10 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272476410.08.0.346392568961.issue7584@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> My Python code as well as your patch doesn't specify that "Z" must be
> present when time zone offset is unknown or absent,

Yes, that is because RFC 3339 explicitly says (in 4.3.) that -00:00 is "differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time". It also says that  if "the offset to local time is unknown, this can be represented with an offset of "-00:00"". So I don't think we can write "Z" or "+00:00" if we don't know the UTC offset.

> but Atom
> specification mentions that

It says "an uppercase "Z" character MUST be present in the absence of a numeric time zone offset". Correct me if I'm wrong, but "-00:00" *is* a numeric time zone offset. So it isn't absent.

> and I believe this is that most users
> expect to see.

I think the RFC is clear (but correct me if I'm mistaken): we cannot replace "-00:00" with it. We of course could replace "+00:00" with "Z".

> In fact I needed such function for implementing Atom
> feed for Trac, so in my opinion Z is more clear than -00:00 or +00:00

It may be better than "+00:00", but according to the RFC it simply doesn't mean the same thing as "-00:00".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Wed Apr 28 19:48:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 28 Apr 2010 17:48:22 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1272476902.93.0.713833052493.issue6312@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Whenever the HEAD method is queried, the httplib recognizes it read method and returns an '' empty string as expected.

Fixed in revision 80583, release26-maint: r80584, py3k: r80587 and release31-maint in 80588.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Wed Apr 28 19:52:02 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 28 Apr 2010 17:52:02 +0000
Subject: [issue8295] add unpack_archive to shutil
In-Reply-To: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>
Message-ID: <1272477122.53.0.325855450684.issue8295@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r80589

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8295>
_______________________________________

From report at bugs.python.org  Wed Apr 28 19:57:01 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 28 Apr 2010 17:57:01 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272477421.04.0.377842402681.issue8552@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file17118/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Wed Apr 28 20:03:22 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 28 Apr 2010 18:03:22 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272477802.55.0.408340397773.issue8552@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I've now been able to build my installer.

I applied Travis Oliphant's patch from http://bugs.python.org/issue2399 to Lib/msilib/__init__.py, then added a __del__ method to the Directory class:

    def __del__(self):
        if self._numfiles_wo_commit > 0:
            self.db.Commit()
        self.db = None
        self.keyfiles = None
        self.cab = None
        self.ids = None

This seems to release enough memory that I can deal with a larger number of files.

I don't think there's a good way to write a unit test for this, though.  Success or failure will depend on the machine you're running it on, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Wed Apr 28 20:14:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 18:14:56 +0000
Subject: [issue1909] Backport: Mixing default keyword arguments with *args
In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
Message-ID: <1272478496.22.0.740317577375.issue1909@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Can this be closed as either fixed or out-or-date, as the case may be?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1909>
_______________________________________

From report at bugs.python.org  Wed Apr 28 20:20:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Apr 2010 18:20:29 +0000
Subject: [issue1909] Backport: Mixing default keyword arguments with *args
In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
Message-ID: <1272478829.11.0.273704185987.issue1909@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It should still be done if any one has the time.
Guido approved it long ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1909>
_______________________________________

From report at bugs.python.org  Wed Apr 28 20:21:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 18:21:13 +0000
Subject: [issue5559] IDLE Output Window 's goto fails when path has spaces
In-Reply-To: <1237951372.91.0.474657570766.issue5559@psf.upfronthosting.co.za>
Message-ID: <1272478873.89.0.753525501947.issue5559@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Resolution should only be set when an issue is closed. So should this be closed? or unfixed and the versions updated?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5559>
_______________________________________

From report at bugs.python.org  Wed Apr 28 20:25:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 18:25:31 +0000
Subject: [issue2345] Using an exception variable outside an 'except' clause
	should raise a Py3K warning
In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za>
Message-ID: <1272479131.66.0.989019029829.issue2345@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am assuming that this is an unfixed bug that might still be fixed in 2.7 sometime and that it should not be closed yet, so I am just updating the version.

----------
nosy: +tjreedy
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2345>
_______________________________________

From report at bugs.python.org  Wed Apr 28 20:27:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 18:27:52 +0000
Subject: [issue2380] Raise a Py3K warning for catching nested tuples with
	non-BaseException exceptions
In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za>
Message-ID: <1272479272.91.0.0234735691567.issue2380@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2380>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:11:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Apr 2010 19:11:34 +0000
Subject: [issue1909] Backport: Mixing default keyword arguments with *args
In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
Message-ID: <1272481894.75.0.47028953332.issue1909@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ok, I though 2.7 was in feature freeze.
Updating version.

----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1909>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:14:27 2010
From: report at bugs.python.org (Nate DeSimone)
Date: Wed, 28 Apr 2010 19:14:27 +0000
Subject: [issue8561] Install .exes generated with distutils to not do a CRC
	check
In-Reply-To: <1272482067.44.0.313764636607.issue8561@psf.upfronthosting.co.za>
Message-ID: <1272482067.44.0.313764636607.issue8561@psf.upfronthosting.co.za>


New submission from Nate DeSimone <nateman1352 at gmail.com>:

During network transit, .exe generated with distutils may become corrupted.  The part of the file that is a binary executable is small compared to the full package typically, so it is possible for the installer to run and lay down bad files.  It would be nice if the setup program ran a CRC check on itself before running.

----------
assignee: tarek
components: Distutils
messages: 104451
nosy: Nate.DeSimone, tarek
priority: normal
severity: normal
status: open
title: Install .exes generated with distutils to not do a CRC check
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/issue8561>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:17:45 2010
From: report at bugs.python.org (Nir Aides)
Date: Wed, 28 Apr 2010 19:17:45 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272482265.48.0.291749923851.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

On Wed, Apr 28, 2010 at 12:41 AM, Larry Hastings wrote:

> The simple solution: give up QPC and use timeGetTime() with timeBeginPeriod(1), which is totally 
> reliable but only has millisecond accuracy at best.

It is preferable to use a high precision clock and I think the code addresses the multi-core time skew problem (pending testing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:21:09 2010
From: report at bugs.python.org (Nir Aides)
Date: Wed, 28 Apr 2010 19:21:09 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272482469.8.0.647040158937.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Dave, there seems to be some problem with your patch on Windows:

F:\dev>z:\dabeaz-wcg\PCbuild\python.exe y:\ccbench.py -b
== CPython 3.2a0.0 (py3k) ==
== x86 Windows on 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' ==

--- I/O bandwidth ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 8551.2 packets/s.
CPU threads=1: 26.1 ( 0 %)
CPU threads=2: 26.0 ( 0 %)
CPU threads=3: 37.2 ( 0 %)
CPU threads=4: 33.2 ( 0 %)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:45:41 2010
From: report at bugs.python.org (AdamN)
Date: Wed, 28 Apr 2010 19:45:41 +0000
Subject: [issue8562] hasattr(open,
	'newlines') example gives incorrect results from  PEP0278
In-Reply-To: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>
Message-ID: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>


New submission from AdamN <adam at varud.com>:

This bug from the Ubuntu list is being moved here:

https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/570737

Newlines support is enabled on Ubuntu but the example from:

http://www.python.org/dev/peps/pep-0278/

Does not give the correct results (of True):

    if hasattr(open, 'newlines'):
            print 'We have universal newline support'

I don't know if this is a documentation problem or whether there is another attr that matters here.

----------
assignee: docs at python
components: Documentation, Windows
messages: 104454
nosy: adamnelson, docs at python
priority: normal
severity: normal
status: open
title: hasattr(open,'newlines') example gives incorrect results from  PEP0278
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8562>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:58:21 2010
From: report at bugs.python.org (Bryce Allen)
Date: Wed, 28 Apr 2010 19:58:21 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1272484701.85.0.595865281388.issue7978@psf.upfronthosting.co.za>


Bryce Allen <oss at bda.ath.cx> added the comment:

I encountered this issue when trying to exit cleanly on SIGTERM, which I use to terminate background daemons running serve_forever.

In BaseServer, a threading.Event is used in shutdown, so it can block until server_forever is finished (after checking __serving). Since the SIGTERM interrupts the select system call, the event set is never reached, and shutdown hangs waiting on the event.

I've attached an example of the pattern I was trying to use in my server. There are several ways around the issue, but looking at the API it seems like this _should_ work, and in my experience all servers have clean-up code so it's a very common case.

----------
nosy: +bda
Added file: http://bugs.python.org/file17120/sockServe.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:59:31 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 28 Apr 2010 19:59:31 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272484771.8.0.612183034849.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm not so sure about sdist_debian for the command I'm thinking about because it doesn't actually build a distribution.  It just creates a 'debian' directory so I think I like just 'debian' as the name of the command.  But thanks for the feedback; time to write some code!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:01:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 20:01:36 +0000
Subject: [issue8558] StringIO().truncate causes zero-bytes in getvalue()
In-Reply-To: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>
Message-ID: <1272484896.04.0.57640879244.issue8558@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've updated the doc in r80591. Sorry for the inconvenience!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8558>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:01:42 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 28 Apr 2010 20:01:42 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

compileall.compile_file() creates empty __pycache__ directories for non-.py files.
This problem usually occurs when compileall.compile_file() is called by compileall.compile_dir() and a subdirectory contains non-code files (e.g. locales, images, templates, documentation).
__pycache__ directories also should not be created when generation of .pyc / .pyo files failed due to e.g. SyntaxErrors.
I'm attaching the patch.

$ mkdir test
$ touch test/file
$ tree test
test
??? file

0 directories, 1 file
$ python3.2 -c 'import compileall; compileall.compile_file("test/file")'
$ tree test
test
??? file
??? __pycache__

1 directory, 1 file

----------
components: Library (Lib)
files: compileall.patch
keywords: patch
messages: 104458
nosy: Arfrever, barry
priority: normal
severity: normal
status: open
title: [PEP 3147] compileall.compile_file() creates empty __pycache__ directories for non-.py files
versions: Python 3.2
Added file: http://bugs.python.org/file17121/compileall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:06:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 20:06:19 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1272484701.85.0.595865281388.issue7978@psf.upfronthosting.co.za>
Message-ID: <1272485315.3412.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In BaseServer, a threading.Event is used in shutdown, so it can block
> until server_forever is finished (after checking __serving). Since the
> SIGTERM interrupts the select system call, the event set is never
> reached, and shutdown hangs waiting on the event.

This precise use case is already fixed (in SVN trunk and in the 2.6
branch) since the select() loop is now wrapped in a try..finally.
I just ran your test case and killing -TERM works ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:08:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 20:08:16 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272485296.25.0.692165710428.issue7865@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For what it's worth, I documented the possibility to call close() several times in r80592.

> Then when you try to wrap a non-readable stream into a readable 
> buffered stream (like BufferedRWPair), it should raise a value error as 
> well,

Good point. Unfortunately, it's now a bit late to change this.
(in any case, it's a programming error to do such things and therefore the user will have to fix his/her code, rather than trying to catch the exception)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:11:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 20:11:53 +0000
Subject: [issue1909] Backport: Mixing default keyword arguments with *args
In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
Message-ID: <1272485513.6.0.0976607780136.issue1909@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Besides someone having to produce the patch, it would also need the release manager's approval (Benjamin).

----------
nosy: +benjamin.peterson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1909>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:23:28 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Apr 2010 20:23:28 +0000
Subject: [issue1909] Backport: Mixing default keyword arguments with *args
In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
Message-ID: <1272486208.74.0.84801442233.issue1909@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Wouldn't this imply a full backport of keyword only arguments? That seems unlikely at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1909>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:37:40 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Apr 2010 20:37:40 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272487060.02.0.275136888419.issue7865@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Wed Apr 28 22:41:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Apr 2010 20:41:31 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1272487291.38.0.604975780994.issue5178@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:02:37 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 Apr 2010 21:02:37 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272488557.92.0.419634147039.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> It also says that  if "the offset to local time is unknown, this can
> be
> represented with an offset of "-00:00"". So I don't think we can write
> "Z" or "+00:00" if we don't know the UTC offset.

>> but Atom
>> specification mentions that

> It says "an uppercase "Z" character MUST be present in the absence of
> a numeric time zone offset". Correct me if I'm wrong, but "-00:00" 
> *is* a numeric time zone offset. So it isn't absent.

As quoted earlier, -00:00 is used when time zone is unknown, and "the absence of a numeric time zone offset" or "the absence of offset" is only possible when this time zone is unknown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:32:47 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 28 Apr 2010 21:32:47 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272490367.49.0.851038054649.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a new test-case patch.

----------
Added file: http://bugs.python.org/file17122/winreg_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:34:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 28 Apr 2010 21:34:27 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272490467.7.0.600354986249.issue2810@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file16802/winreg_test.pach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:40:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 Apr 2010 21:40:29 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272490829.4.0.477889166774.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I do not think that -00:00 or +00:00 will be invalid Atom timestamp, but to implement parser of rfc3339 timestamp, Z handling is still needed. I can easily imagine people making wrong assumption that parsing 00:00 at the end would be enough for proper round-tripping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:46:54 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 28 Apr 2010 21:46:54 +0000
Subject: [issue8535] passing optimization flags to the linker required
	for	builds with gcc -flto
In-Reply-To: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>
Message-ID: <1272491214.7.0.428033090125.issue8535@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

LDSHARED not always is compiler and I'm not sure that linkers always accept compiler flags .
After fix of issue xxx about CFLAGS and issues a, b, c, for LDFLAGS now all is passed to python build system and users could set argument to both variables : CFLAGS and LDFLAGS .

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8535>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:47:09 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 28 Apr 2010 21:47:09 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272491229.26.0.432336552428.issue8510@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

You don't need to add source in case of 
   AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])] .. 
when the the test is ..main() { return 0 ;} ...
, posted long time ago as part of issue3754 ( 	minimal cross-compilation support for configure ).
Also thanks for fixing extra comma in after replacement of AC_TRY_COMPILE .

This part is save to be added to 2.7 build.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:51:54 2010
From: report at bugs.python.org (Peter Fein)
Date: Wed, 28 Apr 2010 21:51:54 +0000
Subject: [issue8564] Update documentation on doctest/unittest2 integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>


New submission from Peter Fein <pfein at pobox.com>:

The documentation on integrating doctests in a file of unittests is confusing and out of date.  This patch updates the documentation to use unittest2 test discovery.

----------
assignee: docs at python
components: Documentation
files: doctest_unittest_integration_doc.diff
keywords: patch
messages: 104468
nosy: docs at python, pfein
priority: normal
severity: normal
status: open
title: Update documentation on doctest/unittest2 integration
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file17123/doctest_unittest_integration_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8564>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:52:34 2010
From: report at bugs.python.org (Peter Fein)
Date: Wed, 28 Apr 2010 21:52:34 +0000
Subject: [issue8564] Update documentation on doctest/unittest2 integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272491554.85.0.0959705180793.issue8564@psf.upfronthosting.co.za>


Peter Fein <pfein at pobox.com> added the comment:

See http://lists.idyll.org/pipermail/testing-in-python/2010-April/003039.html for discussion

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8564>
_______________________________________

From report at bugs.python.org  Wed Apr 28 23:57:34 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 28 Apr 2010 21:57:34 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1272491854.62.0.896273087652.issue5553@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Configure could call macro to define inline - cf. autoconf manuals.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5553>
_______________________________________

From report at bugs.python.org  Thu Apr 29 00:13:27 2010
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 28 Apr 2010 22:13:27 +0000
Subject: [issue1574217] isinstance swallows exceptions
Message-ID: <1272492807.85.0.475510899389.issue1574217@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I can confirm that the patch applies cleanly to the 2.6 branch, that the new test fails before rebuilding, and that the test passes afterwards:

 $ hg summary
 parent: 41597:295c02a21979 tip
  [svn r80597] Merged revisions 80596 via svnmerge from
 branch: release26-maint
 commit: (clean)
 update: (current)
 $ ./configure && make
 ...
 $ ./python -E -tt Lib/test/regrtest.py test_isinstance
 test_isinstance
 1 test OK.
 $ patch -p1 < /tmp/issue1574217_dont_mask_errors.patch
 patching file Lib/test/test_isinstance.py
 patching file Objects/abstract.c
 Hunk #1 succeeded at 2854 (offset 619 lines).
 Hunk #2 succeeded at 2878 (offset 600 lines).
 test_isinstance
 test test_isinstance failed -- Traceback (most recent call last):
   File "/home/tseaver/projects/hg-repo/issue1574217/Lib/test/test_isinstance.py", line 94, in test_isinstance_dont_mask_non_attribute_error
    self.assertRaises(RuntimeError, isinstance, c, bool)
 AssertionError: RuntimeError not raised
 
 1 test failed:
     test_isinstance
 $ make
 ...
 $ ./python -E -tt Lib/test/regrtest.py test_isinstance
 test_isinstance
 1 test OK.

----------
nosy: +tseaver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1574217>
_______________________________________

From report at bugs.python.org  Thu Apr 29 00:13:49 2010
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 28 Apr 2010 22:13:49 +0000
Subject: [issue1574217] isinstance swallows exceptions
Message-ID: <1272492829.6.0.650388743564.issue1574217@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1574217>
_______________________________________

From report at bugs.python.org  Thu Apr 29 00:39:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 22:39:42 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1272494382.94.0.515668609408.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ported to py3k (r80600), blocked in 2.6 (r80602) and 3.1 (r80601).

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Thu Apr 29 01:03:25 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 28 Apr 2010 23:03:25 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272495805.59.0.718912743086.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Wow, that is a *really* intriguing performance result with radically different behavior than Unix.  Do you have any ideas of what might be causing it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Apr 29 01:17:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 23:17:02 +0000
Subject: [issue8565] Always run regrtest.py with -bb
In-Reply-To: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>
Message-ID: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

-bb option helps debug because it detects errors earlier (comparing byte and unicode strings looks strange, it should be a bug).

Attached patch re-exec regrtest.py with -bb if -bb was not used.

----------
components: Tests
files: regrtest_bb.patch
keywords: patch
messages: 104474
nosy: haypo
priority: normal
severity: normal
status: open
title: Always run regrtest.py with -bb
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17124/regrtest_bb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8565>
_______________________________________

From report at bugs.python.org  Thu Apr 29 01:52:34 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 28 Apr 2010 23:52:34 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

Sorry for being all curmudgeonly, but we're using 2to3 in the benchmark suite at http://hg.python.org/benchmarks/, and, since many of the non-CPython implementations are still only 2.5-compatible, the version there needs to run under python 2.5. At the same time, we'd like to be able to use the benchmark version of 2to3 to convert benchmarks to python-3, so we can benchmark changes to CPython's py3k branch. To do that, it'd be nice to be able to import the official 2to3 repository to pick up bug fixes. Therefore, it would be nice for the official repository to run under 2.5.

Here's a patch accomplishing that. It passes its test suite under both 2.5 and 2.6, and can convert itself, and then the converted version can reconvert the original version and get the same result.

You can also review the patch at http://codereview.appspot.com/996043.

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_support_2.5.patch
keywords: needs review, patch, patch
messages: 104475
nosy: benjamin.peterson, jyasskin
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 should run under python 2.5
versions: Python 2.5, Python 2.7
Added file: http://bugs.python.org/file17125/2to3_support_2.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8566>
_______________________________________

From report at bugs.python.org  Thu Apr 29 01:53:48 2010
From: report at bugs.python.org (Collin Winter)
Date: Wed, 28 Apr 2010 23:53:48 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272498828.27.0.737356599076.issue8566@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8566>
_______________________________________

From report at bugs.python.org  Thu Apr 29 02:01:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Apr 2010 00:01:46 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1272499306.57.0.591847740568.issue5553@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Py_LOCAL_INLINE is also not used a lot. Usually, the compiler will inline small static functions by itself. Most of the time, we used #defines rather than functions when we want to inline short snippets of code.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5553>
_______________________________________

From report at bugs.python.org  Thu Apr 29 02:04:30 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 29 Apr 2010 00:04:30 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272499470.85.0.427760394124.issue8566@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8566>
_______________________________________

From report at bugs.python.org  Thu Apr 29 03:45:12 2010
From: report at bugs.python.org (Matt Wartell)
Date: Thu, 29 Apr 2010 01:45:12 +0000
Subject: [issue8562] hasattr(open,
	'newlines') example gives incorrect results from  PEP0278
In-Reply-To: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>
Message-ID: <1272505512.71.0.581583733623.issue8562@psf.upfronthosting.co.za>


Changes by Matt Wartell <matt.wartell+pt at gmail.com>:


----------
nosy: +Matt.Wartell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8562>
_______________________________________

From report at bugs.python.org  Thu Apr 29 04:16:19 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 29 Apr 2010 02:16:19 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1272507379.83.0.665248783003.issue1462525@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Should we close this as out-of-date? I was inclined to see it as fixed as urlparse has gone changes in direction as suggested by the issue.

Sorry Paul, for no response.

Regarding this issue, I plan to use the testcases provided in the patch in the stdlib testsuite and fix things there or comment/document it in the code where parsing conflict arises. This will help us keep track too.

I ran the test cases in the patch against the current trunk and i see 4 tests failing (like borderline scenarios of parsing). I shall take it up,commit the test cases to the trunk and fix it.

----------
assignee: facundobatista -> orsenthil
resolution: out of date -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462525>
_______________________________________

From report at bugs.python.org  Thu Apr 29 08:35:59 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 29 Apr 2010 06:35:59 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272522959.78.0.148587342387.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

On Thu, Apr 29, 2010 at 2:03 AM, David Beazley wrote:

> Wow, that is a *really* intriguing performance result with radically different behavior than Unix.  Do you have any ideas of what might be causing it?

Instrument the code and I'll send you a trace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Apr 29 08:40:18 2010
From: report at bugs.python.org (Andrew Straw)
Date: Thu, 29 Apr 2010 06:40:18 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272523218.3.0.869452819059.issue1054967@psf.upfronthosting.co.za>


Andrew Straw <astraw at users.sourceforge.net> added the comment:

Barry, stdeb does much of what you're describing. (Try the "python setup.py sdist_dsc" command.)

I'm not particularly pleased with the stdeb codebase as it stands, but it does work reasonably well, and I'd like to see progress in this domain, but I'm afraid I don't understand the difference between what it offers and what you're proposing. I guess maybe you're not aware of the "sdist_dsc" distutils command it offers?

-Andrew

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 09:02:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 29 Apr 2010 07:02:05 +0000
Subject: [issue8565] Always run regrtest.py with -bb
In-Reply-To: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>
Message-ID: <1272524525.09.0.534269008086.issue8565@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

+1 to force -bb on buildbots
-1 to hack regrtest.

IMHO it should be added to ./Makefile.pre.in and PCbuild/rt.bat, like other warning switches ( "-Wd" "-tt" "-3").

----------
nosy: +flox
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8565>
_______________________________________

From report at bugs.python.org  Thu Apr 29 10:09:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Apr 2010 08:09:21 +0000
Subject: [issue8565] Always run regrtest.py with -bb
In-Reply-To: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>
Message-ID: <1272528561.52.0.532915510398.issue8565@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> +1 to force -bb on buildbots

I think that it's already enabled, but I'm not sure.

> -1 to hack regrtest

Does someone use runtests.sh? We should maybe improve this script instead of regrtest.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8565>
_______________________________________

From report at bugs.python.org  Thu Apr 29 10:26:13 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 29 Apr 2010 08:26:13 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272529573.7.0.929599477952.issue8523@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The whole error handling in rmtree strikes me as something that cannot be used efficiently. (see also #7969).

How can you decide in an isolated function, that can be called anywhere in the tree you want to remove, the proper thing to do ? You don't know the global status of what is going on. 

I think rmtree() should drop these onerror calls and have two different behaviors:

1/ remove all it can in the tree, and return a list of files it couldn't remove, with the error for each file. The developer can then act upon.

2/ analyze the tree to see if the full removal can be done. If it's possible, it does it, if not, it doesn't do anything and return the problems.


For 2/ a possible way to do it could be to copy in a temporary place files that are being removed and copy them back in place in case a problem occurs. This can be long and space consuming though, for big files and big trees. I am not 100% sure 2/ is really useful though...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Thu Apr 29 12:19:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Apr 2010 10:19:12 +0000
Subject: [issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP
	sockets
In-Reply-To: <1265069614.13.0.295096684445.issue7834@psf.upfronthosting.co.za>
Message-ID: <1272536352.25.0.355446144657.issue7834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r80610. Thanks!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7834>
_______________________________________

From report at bugs.python.org  Thu Apr 29 13:10:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 11:10:29 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

http://speleotrove.com/decimal/daexcep.html specifies a precedence for decimal exceptional conditions (scroll right to the bottom of the page):

"""The Clamped, Inexact, Rounded, and Subnormal conditions can coincide with each other or with other conditions. In these cases then any trap enabled for another condition takes precedence over (is handled before) all of these, any Subnormal trap takes precedence over Inexact, any Inexact trap takes precedence over Rounded, and any Rounded trap takes precedence over Clamped.""" 

Currently the decimal module doesn't follow this.  For example, the following should raise decimal.Overflow, not decimal.Inexact:

Python 3.2a0 (py3k:80609, Apr 29 2010, 11:46:22)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> getcontext().traps[Inexact] = True
>>> Decimal('1e100').exp()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dickinsm/Source/py3k/Lib/decimal.py", line 3002, in exp
    ans = ans._fix(context)
  File "/home/dickinsm/Source/py3k/Lib/decimal.py", line 1658, in _fix
    context._raise_error(Inexact)
  File "/home/dickinsm/Source/py3k/Lib/decimal.py", line 3866, in _raise_error
    raise error(explanation)
decimal.Inexact: None


It's also not clear to me exactly which flags should be set in a case like this.

----------
assignee: mark.dickinson
messages: 104484
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: decimal module doesn't respect precedence rules for exceptional conditions
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/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 13:11:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 11:11:25 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272539485.35.0.224503526893.issue8567@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +facundobatista, rhettinger, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 13:45:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 11:45:18 +0000
Subject: [issue8568] Test issue
In-Reply-To: <1272541518.32.0.0725910640112.issue8568@psf.upfronthosting.co.za>
Message-ID: <1272541518.32.0.0725910640112.issue8568@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Test issue:  I just got a 'there was a problem with your submission: tracker maintainers informed' message when submitting issue 8567, though it looks as though the submission succeeded.

Here's a test issue to try to reproduce.

Steps taken:

Click on "Create New" in the Issues menu.
Enter title and nosy fields;  all other fields left unspecified.
In nosy list, specify: "skrah,rhettinger,facundo.batista"  (note that the last entry is misspelled;  it should be "facundobatista").

Hit "Submit New Entry".

This takes me to a new page (URL http://bugs.python.org/issue) with the message:

"""
An error has occurred

A problem was encountered processing your request. The tracker maintainers have been notified of the problem.
"""

After hitting the back button in my browser (Firefox) and trying 'Submit New Entry' again I get the 'Your request is being processed.  Please be patient' message.)

Correcting the nosy list allows the submission to go through.

----------
messages: 104485
nosy: facundobatista, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: Test issue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8568>
_______________________________________

From report at bugs.python.org  Thu Apr 29 13:48:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 11:48:58 +0000
Subject: [issue8568] Test issue
In-Reply-To: <1272541518.32.0.0725910640112.issue8568@psf.upfronthosting.co.za>
Message-ID: <1272541738.09.0.084167791379.issue8568@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8568>
_______________________________________

From report at bugs.python.org  Thu Apr 29 13:56:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 11:56:18 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1272542178.18.0.50347092898.issue7511@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Some committers have been using 'resolution: accepted' as a way to mark issues that are definitely going to be fixed/enhancement added.  For a critical bug I think this is a bit redundant (it is more useful for feature requests), but I'm pretty sure Tarek did it on purpose.

----------
nosy: +r.david.murray
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Thu Apr 29 13:57:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 11:57:54 +0000
Subject: [issue4186] type() doesn't accept bases and dict keyword arguments
In-Reply-To: <1224753211.57.0.0760272194538.issue4186@psf.upfronthosting.co.za>
Message-ID: <1272542274.27.0.921193943109.issue4186@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Seems reasonable.

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4186>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:08:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 12:08:31 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272542911.9.0.31991220272.issue2810@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How much would increasing the loop count slow down the test?  Since if the bug isn't present the loop will run to the end every time, if it is non-trivial it would probably be better to keep it shorter, since Brian said it failed one way or another 9 out of 10 times.  Either way, a note in the test that it may occasionally pass even if the bug is present, but should fail most of the time, would be a good idea.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:12:30 2010
From: report at bugs.python.org (rubenlm)
Date: Thu, 29 Apr 2010 12:12:30 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272543150.8.0.823219084606.issue8523@psf.upfronthosting.co.za>


rubenlm <ruben at libhertz.com> added the comment:

Do you really need the global status? I wrote an onerror that seems to works fine after I modified rmtree with the "return" suggested by r.david.murray. It assumes that: 

if os.listdir fails: the user doesn't have read permissions in the dir;
if os.remove or os.rmdir fails: the user doesn't have write permissions in the dir that contains the file/dir being removed.

There are other reasons it can fail (attributes, acl, readonly filesystem, ...) but having access to the global status doesn't seem to be of much help anyway.

I don't like your fix 2/ because it can fail to copy files if you don't have read permissions for the file but have write permissions in the directory (so you can delete the file). Besides, the behaviour doesn't seem useful.

/1 seems ok to me but to make use of the global status it provides the user must write a somewhat complex recovery code.

All in all it seems the current behaviour of having an onerror function is more user friendly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:12:41 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 12:12:41 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272543161.34.0.656500796088.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi Andrew,

Yes, I've played with sdist_dsc, and it's nice in that it takes a non-Debianized source tree and turns it into a source package that can be uploaded.  What I'm looking for is something that can take a non-Debianized source tree and turn it into a native package, essentially by pre-filling a debian/ directory like dh_make does, but including additional metadata available in the setup.py.

I've started taking a crack at this:

https://launchpad.net/setupdebian

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:17:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 29 Apr 2010 12:17:59 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1272543479.4.0.771858804532.issue8084@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'd prefer to have this resolved before the next 2.7 beta.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:30:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 12:30:09 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272544209.85.0.30708750396.issue8567@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:32:09 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 29 Apr 2010 12:32:09 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272544329.13.0.0691505683923.issue8523@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> /1 seems ok to me but to make use of the global status it provides 
> the user must write a somewhat complex recovery code.

The onerror() code you did is as complex as a global function working with a sequence returned by rmtree, since it is used *everywhere* in rmtree, and not only for os.listdir issues. IOW, if you didn't handle other possible failures than os.listdir errors, it will fail if rmtree calls it for other APIs like os.remove, etc..

If we state that onerror() is not used as a fallback in rmtree(), and do whatever it wants to do on its side, in an isolated manner, then I find it simpler that this function works will a list of paths rmtree() failed to removed, at the end of the rmtree() process. 

I'd be curious to see your onerror() function btw: if it's here just to silent permission errors, 1/ would make it even simpler: don't deal with the error list returned by rmtree() that's all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:33:12 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 29 Apr 2010 12:33:12 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1272544392.57.0.185052605505.issue8084@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:37:11 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 29 Apr 2010 12:37:11 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1272544631.74.0.466994193626.issue7511@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes I used 'accepted' to mark this issue as something I am working on.

I am confused about the resolution flag, I think it is a bit overlapping with the status flag, and overcomplex. 

Maybe we should replace "closed" with various flags like: "fixed", "wontfix",  "rejected". (My 2 cents of course ;) )

----------
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:44:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 12:44:36 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272545076.05.0.428274011386.issue8567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Regarding the flags that should be set, the relevant portion of the specification is at the top of the page mentioned above:

"""
For each condition, the corresponding signal in the context is given, along with the defined result. The value of the trap-enabler for each signal in the context determines whether an operation is completed after the condition is detected or whether the condition is trapped and hence not necessarily completed (see IEEE 754 ?7 and ?8).
"""

Reading between the lines, I think this means that it's okay for an exception resulting from a trap to leave the flag state undefined, at least for those flags that would have been raised by the operation.  (But flags that were already set before the operation should remain set;  while flags corresponding to the signals that would not have been raised by the operation should not be changed.)

Section 8 if IEEE 754 backs this up to some extent.  Python's decimal traps effectively provide what IEEE 754 section 8.3 calls "Immediate transfer associated with a block", a form of "immediate exception handling".  Note 2 in that section says:

"""
[...] If the indicated exception is signaled in the associated block, causing execution of the handler block or transfer of control, then the state of the corresponding status flag might not be deterministic.
"""

This doesn't *exactly* apply here, since it's really talking about a sequence of primitive operations rather than a single primitive operation, but it's close.  (One might reasonably ask that primitive operations be regarded as atomic, so act as though all relevant flags are set, and only *then* are any relevant traps raised.  This would not be a trivial change, however.)

In spite of this indeterminacy, it would still be nice to have clear rules about what Python's decimal module actually does, even if those rules are only for developer consumption.

The simplest (and closest to what's already implemented) would be the following:

- any particular operation (i.e. operands + function) determines uniquely some set of signals;  the decimal specification gives us an ordering on those signals.

- the result of the operation should be as if we go through those signals one-by-one in order, and for each signal:

   (a) if the signal is trapped, raise the corresponding exception
   (b) else set the corresponding flag, and move on to the next signal.

Example to clarify these rules: the overflow example above produces the signals [Overflow, Inexact, Rounded] in that order.  If 'Overflow' is trapped, the Overflow exception is raised and no flags are set.  Otherwise, if 'Inexact' is trapped, the Inexact exception is raised and the 'Overflow' flag is set.  Otherwise, if 'Rounded' is trapped, the Rounded exception is raised and the 'Overflow' and 'Inexact' flags will have been set.  Otherwise, no exception is raised and all three flags are set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:46:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 12:46:37 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272545197.98.0.0552633845647.issue8567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raising priority:  I'd like to get the precedence fix into 2.7.

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:48:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Apr 2010 12:48:35 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I don't know how official installers are built, but the standard build procedure with the Visual Studio files uses a custom checkout of OpenSSL 0.9.8l. OpenSSL is now at version 1.0.x, which adds security fixes and improvements.

I'd suggest upgrade the "custom checkout" to use the latest OpenSSL version, at least for dev branches (it may be too disruptive for the bugfix branches, since OpenSSL seems to have a history of changing behaviour a bit even between what look like minor versions). I don't have an idea how to do this myself, Linux being my development platform.

----------
components: Build, Windows
messages: 104496
nosy: brian.curtin, christian.heimes, loewis, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: Upgrade OpenSSL in Windows builds
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Thu Apr 29 14:55:49 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 29 Apr 2010 12:55:49 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1272545749.81.0.911211731978.issue8569@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

http://www.openssl.org/news/secadv_20100324.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

New Windows builds of any versions of CPython which are still receiving security updates should be released.

----------
nosy: +exarkun
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:00:44 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 29 Apr 2010 13:00:44 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1272546044.14.0.350080587783.issue7852@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

test failures have been fixed a while back.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7852>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:02:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Apr 2010 13:02:11 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1272546131.32.0.0821778241245.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

In the updated patch I uploaded yesterday, I increased the loop count from 100 to 1000 and it still runs virtually instantly.  I also added a comment stating that the test is trying to trigger a race condition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:02:27 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 29 Apr 2010 13:02:27 +0000
Subject: [issue8476] build-installer fix for setIcon when no script path
	specified
In-Reply-To: <1271804262.14.0.282161229164.issue8476@psf.upfronthosting.co.za>
Message-ID: <1272546147.92.0.198129527697.issue8476@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The patch looks good, I will apply it over the weekend.

Thanks for looking into this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8476>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:21:29 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 29 Apr 2010 13:21:29 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272547289.39.0.754345476889.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> You don't need to add source in case of 
>   AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])] .. 
> when the the test is ..main() { return 0 ;} ...

is there a version of the cross configure patch for 3.x?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:23:51 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Apr 2010 13:23:51 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272547431.92.0.985648381868.issue8567@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark,

I'm very short of time today, so I hope I don't miss anything that you
wrote.

The model of decNumber (and libmpdec) is to accumulate any status
(flags) that occurs in a function, regardless of whether a signal
is trapped or not. 

Only at function exit the traps are checked. If multiple exceptions
could be raised, the order of precedence applies. All status that
has been accumulated in the function remains in the context.


This would be backed up by:

http://speleotrove.com/decimal/damodel.html

  ==>  flags and trap-enablers:

  ==> "For each of the signals, the corresponding flag is set to 1
       when the signal occurs. It is only reset to 0 by explicit
       user action."


So, in your example, in cdecimal I get:
>>> from cdecimal import *
>>> getcontext().traps[Inexact] = True
>>> Decimal('1e100').exp()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
cdecimal.Overflow: [<class 'cdecimal.Overflow'>, <class 'cdecimal.Inexact'>]


In the square brackets I list all signals that occurred _and_ are
trapped.





 

  "

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:29:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 13:29:21 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272547761.73.0.893557002268.issue8567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Stefan.  The cdecimal and decnumber behaviour sounds like the ideal one to me.

I'm not sure how easy it would be to adopt this behaviour for decimal: it could require some significant rewriting, so we may have to leave decimal as it is and call the flag situation undefined.

I'll take a proper look sometime (soon, I hope);  Decimal._fix is the main place that's going to need fixes.  The hard part is tracking down all the other places where a signal is raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:33:51 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Apr 2010 13:33:51 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272548031.32.0.888450881524.issue8540@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> Were you thinking of any deviations in particular?

More or less a commentary on what is listed here:

http://speleotrove.com/decimal/dascope.html

  ==> Restrictions


I only have a draft of IEEE754, but for instance I can't find a power
or remainder-near function there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:42:14 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 29 Apr 2010 13:42:14 +0000
Subject: [issue8535] passing optimization flags to the linker required
	for	builds with gcc -flto
In-Reply-To: <1272281239.09.0.0884151930706.issue8535@psf.upfronthosting.co.za>
Message-ID: <4BD98CB3.9090203@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Matthias Klose wrote:
> 
> Matthias Klose <doko at debian.org> added the comment:
> 
>> It's probably better to just pass OPT to the linker instead.
> 
> not enough, because -fno-strict-aliasing might be passed in BASE_CFLAGS.

Shouldn't -fno-strict-aliasing be added to OPT instead of
BASE_CFLAGS ? After all, it's an optimization settings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8535>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:43:47 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Apr 2010 13:43:47 +0000
Subject: [issue1644818] Allow built-in packages and submodules as well as
	top-level modules
Message-ID: <1272548627.45.0.110281650566.issue1644818@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, reassessing with brain fully engaged this time: the current patch is incorrect, and this request is more complicated than one might initially think :)

It appears that since the patch was originally tried out only on Windows, a Modules/Setup based system based system like mine can't even build a patched tree. The current incarnation of the Modules/makesetup script won't allow the use of a dotted name for a module named in Modules/Setup.

Anyway, I'm uploading a more fleshed out test case which explicitly details some of the module namespace invariants that built-in packages would need to support (and changing the issue type and title accordingly).

Even beyond these stricter tests, pkgutil and importlib would need to be checked to make sure they also support the new behaviour. 

Since I can't build the patch as it currently stands, I don't know how well it actually fairs against the stronger set of invariants. However, just looking at the patch I'm pretty confident that it doesn't include the necessary work to make sure that the parent package actually looks like a package from the interpreter's point of view.

----------
components:  -Build
stage:  -> needs patch
title: Allow importing built-in submodules -> Allow built-in packages and submodules as well as top-level modules
type: behavior -> feature request
versions:  -Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17126/test_builtin_submodule.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:44:02 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Apr 2010 13:44:02 +0000
Subject: [issue1644818] Allow built-in packages and submodules as well as
	top-level modules
Message-ID: <1272548642.43.0.440856804016.issue1644818@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:48:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Apr 2010 13:48:32 +0000
Subject: [issue1644818] Allow built-in packages and submodules as well as
	top-level modules
Message-ID: <1272548912.53.0.71503153481.issue1644818@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unassigning - this idea needs a lot more specification work to be done before actually implementing it becomes a good idea.

(e.g. IronPython and Jython should be looked at to see how they handle the naming schemes in the standard libraries for their respective runtime environments)

----------
assignee: ncoghlan -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Thu Apr 29 15:50:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 13:50:22 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272549022.03.0.968035490698.issue8523@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, I don't think removing the current onerror support is a viable option for backward compatibility reasons, so we might as well fix it.  

I agree that (2) sounds tricky to get reliably right, while I don't see how (1) is an improvement over onerror.  It seems to me that the list is either really a tree, in which case the error handler has to reimplement most of rmtree's logic in order to do a recover, or it is a list of error filepath pairs, in which case the error handler would be in most cases simply be iterating over the list and branching based on the error flag...which is no different than what onerror allows, but onerror doesn't need the loop code.  Actually, it's less capable than what onerror allows, since if onerror successfully removes a problem file, rmtree will remove the directory, whereas a (1) style handler will have to have its own error logic for dealing with the successive removals (and the (1) style list will have to be guaranteed to be sorted in the correct bottom up order).

I guess I don't see how knowing the global state (which in this case appears to mean the total list of files and directories where removal failed) is useful very often, if ever.  It feels like it is a more complicated API that provides little benefit.  Do you have some use cases in mind, Tarek?

On the other hand, it seems to me that a nice improvement to onerror would be for it to accept an object, and call an error-case-specific method for each different error case, perhaps even checking for method existence first and doing its normal error handling for that case if the method isn't defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:08:11 2010
From: report at bugs.python.org (rubenlm)
Date: Thu, 29 Apr 2010 14:08:11 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272550091.33.0.48068239749.issue8523@psf.upfronthosting.co.za>


rubenlm <ruben at libhertz.com> added the comment:

Here is my current error handler:

def handleRmtreeError(func, path, exc):
  excvalue = exc[1]
  if excvalue.errno == errno.EACCES:
    if func in (os.rmdir, os.remove):
      parentpath = path.rpartition('/')[0]
      os.chmod(parentpath, stat.S_IRWXU) # 0700
      func(path)
    elif func is os.listdir:
      os.chmod(path, stat.S_IRWXU) # 0700
      rmtree(path=path, ignore_errors=False, onerror=handleRmtreeError)
  else:
      raise

Looking back to this code there is an infinite recursion bug if os.chmod fails for some reason in the os.listdir condition. I don't see an easy way to solve this...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:09:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 29 Apr 2010 14:09:38 +0000
Subject: [issue8442] Broken zipfile with  python 3.2 on osx
In-Reply-To: <1271603737.34.0.035153225146.issue8442@psf.upfronthosting.co.za>
Message-ID: <1272550178.93.0.436715597414.issue8442@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I cannot reproduce this behavior on my MacBook running OSX 10.6.2.

$ ./python.exe Lib/test/test_distutils.py 
...
----------------------------------------------------------------------
Ran 168 tests in 3.850s

OK (skipped=4)

Also, cp437 appears to be a valid encoding:

Python 3.2a0 (py3k:80615M, Apr 29 2010, 10:00:45) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> b"".decode('cp437')
''
>>> b"abcde".decode('cp437')
'abcde'

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8442>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:11:27 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 29 Apr 2010 14:11:27 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272550287.4.0.257254435171.issue8523@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> Well, I don't think removing the current onerror support is a viable 
> option for backward compatibility reasons, 
> so we might as well fix it.  

The options could be deprecated since the new behavior would *return* errors.

> Do you have some use cases in mind, Tarek?

What I have in mind is robustness and simplicity: 

robustness because rmtree() will stop calling third party code that can possibly fail and blow the whole process, while working at removing the tree. 

Simplicity because, if it fails at removing some files using the usual os.* APIs, it will just return these errors.

Having this two phases-process will ensure that rmtree() did all that was possible to remove files.

And as I said previously, I am curious to know what is going to be done in the onerror() function when something fails in rmtree(). I doubt any third-party code will do better.

This statement "I couldn't copy this file, try it yourself" seems doomed to complexity.

If the only use case for onerror() is to silent failures, returning these failures seem quite enough. Ala smtp when you get back a list of mails that couldn't be send: it doesn't ask you to send them by yourself, just informs you.

Now maybe we do miss some APIs to check for a file tree sanity, like:

- are the permissions the same throughout the tree ?
- is there any link that will make rmtree() fail ? 
- etc/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:14:02 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 29 Apr 2010 14:14:02 +0000
Subject: [issue8442] Broken zipfile with  python 3.2 on osx
In-Reply-To: <1271603737.34.0.035153225146.issue8442@psf.upfronthosting.co.za>
Message-ID: <1272550442.52.0.246756387423.issue8442@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

There were some other build problems at the time, I haven't verified yet if the fixes for those problems also fixed this issue. I will do so over the weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8442>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:21:32 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 29 Apr 2010 14:21:32 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272550892.71.0.428028235324.issue8523@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Looking at your example rubenlm, it appears like a case that is missing in rmtree().

You are trying to chmod your tree if a file in there cannot be removed because of the permissions. This sounds like something we need to add in rmtree() directly, for example under a "force_permissions" flag that would handle permission failures by trying to chmod.

I think rmtree() should not try to delegate the hard work to third party code, and should try to handle as much failures as possible, 
and just return errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:22:13 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 29 Apr 2010 14:22:13 +0000
Subject: [issue8564] Update documentation on doctest/unittest2 integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272550933.66.0.0309865927335.issue8564@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Looks like a good addition to the documentation to me.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8564>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:25:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 29 Apr 2010 14:25:01 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1272551101.3.0.172141226541.issue8569@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Tools/buildbot/external-common.bat does the checkout of OpenSSL 0.9.8l from svn.python.org/projects/external. What does it take to put a new 1.x version out there?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:48:01 2010
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 29 Apr 2010 14:48:01 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272552481.16.0.614433098087.issue8552@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Another bit of info.  It's the frequent commits that seem to fix the problem; when I comment those out of the __del__ method, it fails as before.  I also notice that the finished installer is about twice the size of the two data files in it (the CAB file and my zip file).  Seems like a lot of overhead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:50:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 29 Apr 2010 14:50:30 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1272552630.83.0.484666678633.issue8404@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

The patch looks fine.  I verified that the new tests pass on trunk and py3k.  I am attaching a patch for py3k with a forward port of set opereations and repr tests.

----------
nosy: +Alexander.Belopolsky
Added file: http://bugs.python.org/file17127/issue8404_tests_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu Apr 29 16:57:21 2010
From: report at bugs.python.org (rom16384)
Date: Thu, 29 Apr 2010 14:57:21 +0000
Subject: [issue8570] 2to3 crashes with "AttributeError: 'int' object has no
	attribute 'startswith'"
In-Reply-To: <1272553040.84.0.60116015533.issue8570@psf.upfronthosting.co.za>
Message-ID: <1272553040.84.0.60116015533.issue8570@psf.upfronthosting.co.za>


New submission from rom16384 <rom16384 at yahoo.com>:

The attached file crashes 2to3 with traceback:

Traceback (most recent call last):
  File "/usr/bin/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/usr/lib/python2.6/lib2to3/main.py", line 129, in main
    rt.refactor(args, options.write, options.doctests_only)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 196, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 235, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 260, in refactor_string
    self.refactor_tree(tree, name)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 294, in refactor_tree
    self.traverse_by(self.post_order_heads, tree.post_order())
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 316, in traverse_by
    results = fixer.match(node)
  File "/usr/lib/python2.6/lib2to3/fixes/fix_numliterals.py", line 18, in match
    (node.value.startswith("0") or node.value[-1] in "Ll"))
AttributeError: 'int' object has no attribute 'startswith'


The code is from a version of pupynere, trimmed to reveal the traceback.
Python 2.6.4, OS: Ubuntu 9.10 (Karmic).

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_crash.py
messages: 104518
nosy: rom16384
priority: normal
severity: normal
status: open
title: 2to3 crashes with "AttributeError: 'int' object has no attribute 'startswith'"
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17128/2to3_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8570>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:18:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 29 Apr 2010 15:18:57 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1272554337.23.0.944753816065.issue8413@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am not sure fixing this quirk of %-formatting is worth the trouble given that one simply use new style {}-formatting:

$ python-c 'import sys; print("{}.{}.{}-{}-{}".format(*sys.version_info))'
3.2.0-alpha-0

or a work-around

$ python -c 'import sys; print("%s.%s.%s-%s-%s" % tuple(sys.version_info))'
3.2.0-alpha-0

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:20:14 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 29 Apr 2010 15:20:14 +0000
Subject: [issue8535] passing optimization flags to the linker required
	for	builds with gcc -flto
In-Reply-To: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>
Message-ID: <1272554414.26.0.979060528122.issue8535@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

my understanding is that the builder is allowed to overwrite OPT, but not BASE_CFLAGS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8535>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:22:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Apr 2010 15:22:27 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1272554547.35.0.133366718485.issue8413@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the problem is that it's a regression from 2.6.
It also shows why these "fancy" structs aren't necessarily a good idea.
I agree fixing in py3k is less important, though it would be nice too.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:35:57 2010
From: report at bugs.python.org (Denis Dmitriev)
Date: Thu, 29 Apr 2010 15:35:57 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>


New submission from Denis Dmitriev <dmitriev at deshaw.com>:

There's a bug in python's zlibmodule.c that makes it raise SystemError whenever it tries to decompress a chunk larger than 1GB is size. Here's an example of this in action:

dmitriev at ...:~/moo/zlib_bug> cat zlib_bug.py 
import zlib

def test_zlib(size_mb):
    print "testing zlib with a %dMB object" % size_mb
    c = zlib.compressobj(1)
    sm = c.compress(' ' * (size_mb*1024*1024)) + c.flush()
    d = zlib.decompressobj()
    dm = d.decompress(sm) + d.flush()

test_zlib(1024)
test_zlib(1025)

dmitriev at ...:~/moo/zlib_bug> python2.6 zlib_bug.py 
testing zlib with a 1024MB object
testing zlib with a 1025MB object
Traceback (most recent call last):
  File "zlib_bug.py", line 11, in <module>
    test_zlib(1025)
  File "zlib_bug.py", line 8, in test_zlib
    dm = d.decompress(sm) + d.flush()
SystemError: Objects/stringobject.c:4271: bad argument to internal function

dmitriev at ...:~/moo/zlib_bug>

A similar issue was reported in issue1372; however, either this one is different, or the issue still exists in all versions of Python 2.6 that I tested, on both Solaris and Mac OS X. These are all 64-bit builds and have no problem manipulating multi-GB structures, so it's not an out-of-memory condition:

dmitriev at ...:~/moo/zlib_bug> python2.6   
Python 2.6.1 (r261:67515, Nov 18 2009, 12:21:47) 
[GCC 4.3.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> len(' ' * (6000*1024*1024))
6291456000
>>>

----------
components: Library (Lib)
messages: 104522
nosy: ddmitriev
priority: normal
severity: normal
status: open
title: zlib causes a SystemError when decompressing a chunk >1GB
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:36:53 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Apr 2010 15:36:53 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1272555413.32.0.62037353344.issue8413@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The other thing to do would be to convince PyTuple_Check that PyStructSequences are tuples, but that would no doubt come with its own set of regressions.

Since this problem is 1) hard to fix and 2) probably of minimal impact, I think the best course is to do nothing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:37:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 29 Apr 2010 15:37:03 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1272555423.12.0.113794032938.issue8413@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

The recommended way to check that an object is an instance of a namedtuple  is to check for the _fields attribute.  See issue7796, msg99869.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:43:38 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Apr 2010 15:43:38 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1272555818.36.0.426692397837.issue8413@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Yes, but sys.version_info isn't a namedtuple (which are in fact tuples), it's the (sort-of) C equivalent, which isn't a real tuple.

>>> from collections import namedtuple
>>> x = namedtuple('x', 'a b c')
>>> '%s %s %s' % x(1, 2, 3)
'1 2 3'

Hmm, but sys.version_info is a tuple:
>>> isinstance(sys.version_info, tuple)
True

I'll have to check if PyTuple_Check returns true or not. Maybe the problem is in the mapping check.

I'll investigate more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:45:44 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 29 Apr 2010 15:45:44 +0000
Subject: [issue8464] tarfile creates tarballs with execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1272555944.65.0.202204628889.issue8464@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I applied the patch and added a test case (see r80616-r80619). Thanks for the report.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8464>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:49:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 15:49:46 +0000
Subject: [issue8557] subprocess PATH semantics
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272556186.05.0.921459405394.issue8557@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Changing the default value of shell is not an option anyway.

The behavior you describe is exactly what one should expect: the environment in which the executable is located is the environment of the process calling Popen, not the environment passed to Popen.  The environment passed to Popen is the environment in which the subprocess executes.  When using shell=True, this is the environment in which the shell executes, and the *shell* then looks up the executable in that new environment.  As far as I know this behavior is the same on both Windows and Unix, and thus is not a portability issue.  (How the shell works can be a portability issue, though.)

I'm not sure that this needs to be documented explicitly, as it is a logical consequence of how subprocesses work, but if you want to suggest a doc update I'll take a look at it.

I suspect your Unix example is about the fragility of the rules for computing sys.executable (there's an issue in the tracker about that...you may get a different result on trunk), but I haven't checked it.

----------
nosy: +r.david.murray
title: subprocess portability issue -> subprocess PATH semantics

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:49:54 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 15:49:54 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272556194.8.0.61468970062.issue8563@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for finding this bug.  I'm not sure about the second chunk of your diff (the one that removes __pycache__).  In the future, it would help to include a unittest case that illustrates the problem.  Here's a patch that includes a test for that specific problem, along with a narrowed down patch.  Can you explain why the other chunk is necessary (preferably with a unittest)?

----------
Added file: http://bugs.python.org/file17129/8563.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:50:02 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 15:50:02 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272556202.43.0.38070768027.issue8563@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:52:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 29 Apr 2010 15:52:35 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1272556355.61.0.123238514121.issue8413@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

IIRC, there is an open ticket to make structseq inherit from tuple to avoid just this kind of problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:56:20 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Apr 2010 15:56:20 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1272556580.85.0.0484925305772.issue8413@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Looks like that's issue 1820.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:56:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 29 Apr 2010 15:56:30 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1272556355.61.0.123238514121.issue8413@psf.upfronthosting.co.za>
Message-ID: <z2xd38f5331004290856oe2c4fb73kdb0460673f854592@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Thu, Apr 29, 2010 at 11:52 AM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> IIRC, there is an open ticket to make structseq inherit from tuple to avoid just this kind of problem.
>

Indeed, see issue1820.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:57:13 2010
From: report at bugs.python.org (Walter Woods)
Date: Thu, 29 Apr 2010 15:57:13 +0000
Subject: [issue8572] httplib getheader() does not work as documented
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>


New submission from Walter Woods <woodswalben at gmail.com>:

Calling HTTPResponse.getheader('Testabnew', 'Default') throws an exception rather than returning default, python 3.1.2.  Problem code appears to be line 601 of client.py:


    def getheader(self, name, default=None):
        if self.headers is None:
            raise ResponseNotReady()
-        return ', '.join(self.headers.get_all(name, default))

Which should probably changed to:

+        result = self.headers.get_all(name, None)
+        if result:
+            return ', '.join(result)
+        else:
+            return default

Not as elegant, but what appears to happen is if default is not an array, then get_all returns it, and the string join fails with a TypeError.

----------
messages: 104532
nosy: Walter.Woods
priority: normal
severity: normal
status: open
title: httplib getheader() does not work as documented
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 17:57:41 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 29 Apr 2010 15:57:41 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272556661.45.0.749553623518.issue8563@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Here's an example, which shows that an empty __pycache__ has been created:

$ mkdir test
$ echo ":" > test/file.py
$ tree test
test
??? file.py

0 directories, 1 file
$ python3.2 -c 'import compileall; compileall.compile_file("test/file.py")'
Compiling test/file.py ...
***   File "test/file.py", line 1
    :
    ^
SyntaxError: invalid syntax

$ tree test
test
??? file.py
??? __pycache__

1 directory, 1 file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:01:42 2010
From: report at bugs.python.org (Walter Woods)
Date: Thu, 29 Apr 2010 16:01:42 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272556902.58.0.0958473553866.issue8572@psf.upfronthosting.co.za>


Changes by Walter Woods <woodswalben at gmail.com>:


----------
title: httplib getheader() does not work as documented -> httplib getheader() throws error instead of default

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:08:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 16:08:02 +0000
Subject: [issue8560] regrtest: add a minimal "progress bar"
In-Reply-To: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>
Message-ID: <1272557282.14.0.120226116076.issue8560@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

-1

IMO it just makes the output messier and less readable, and I personally am fine with judging the progress by the filenames.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8560>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:24:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 16:24:15 +0000
Subject: [issue5559] IDLE Output Window 's goto fails when path has spaces
In-Reply-To: <1237951372.91.0.474657570766.issue5559@psf.upfronthosting.co.za>
Message-ID: <1272558255.12.0.714592711698.issue5559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the issue is still open waiting for a unit test.  On the other hand, how likely is it that someone is going to write one at this point?  If someone doesn't speak up soon I think you can close it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5559>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:44:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 16:44:00 +0000
Subject: [issue8565] Always run regrtest.py with -bb
In-Reply-To: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>
Message-ID: <1272559440.83.0.384552704979.issue8565@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There are currently (at least) two places where regrtest is invoked by the buildbots, one for unix and one for windows.  The flags used are not always in sync, but probably should be.

I think it is probably better to not hack regrtest for this, since that would actually reduce its flexibility, but I'm open to argument on that. I'm going to set myself up an alias for running the tests:

   alias pytest="./python -E -tt -bb -Wd -3 -m test.regrtest"

That form for running regrtest should probably be added to the dev docs as a recommendation.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8565>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:50:31 2010
From: report at bugs.python.org (Denis Dmitriev)
Date: Thu, 29 Apr 2010 16:50:31 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1272559831.56.0.188129924553.issue8571@psf.upfronthosting.co.za>


Denis Dmitriev <dmitriev at deshaw.com> added the comment:

Alright, I think this is caused by the following:

static PyObject *
PyZlib_objdecompress(compobject *self, PyObject *args)
{
    int err, inplen, old_length, length = DEFAULTALLOC;
    int max_length = 0;

The problem is that inplen, length, old_length, and max_length are all ints, whereas they should be Py_ssize_t. I think replacing them should make the bug go away. (I can't test it right now though because I'm having trouble compiling zlibmodule on my current machine)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:53:17 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Apr 2010 16:53:17 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272559997.51.0.949239184963.issue7079@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file15076/fileobject.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:53:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Apr 2010 16:53:22 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272560002.06.0.380372584277.issue7079@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file15077/crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:54:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 16:54:16 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1272560056.29.0.729538621809.issue8084@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since you want it before the next beta, I'm promoting it to release blocker.  Benjamin can reduce it if needed when we get down to the wire.

----------
nosy: +r.david.murray
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:54:48 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Apr 2010 16:54:48 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272560088.94.0.222758839247.issue7079@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Added file: http://bugs.python.org/file17130/file_close_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:55:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Apr 2010 16:55:08 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272560108.21.0.963329142272.issue7079@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Added file: http://bugs.python.org/file17131/file_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Thu Apr 29 18:57:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Apr 2010 16:57:08 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1272560228.95.0.605471441155.issue7079@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I reworked my test script into a unit test.  Thanks for pointing me to test_file2k.py.  I leveraged the infrastructure that was already there.

I've also uploaded a new patch that uses tabs instead of spaces, to match the rest of fileobject.c.

----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:04:09 2010
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 29 Apr 2010 17:04:09 +0000
Subject: [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272560649.71.0.0467818229847.issue8552@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Ah, found the size problem -- I was measuring something in 512 blocks not 1KB blocks.  Never mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8552>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:20:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 17:20:30 +0000
Subject: [issue8570] 2to3 crashes with "AttributeError: 'int' object has no
	attribute 'startswith'"
In-Reply-To: <1272553040.84.0.60116015533.issue8570@psf.upfronthosting.co.za>
Message-ID: <1272561630.41.0.919512777079.issue8570@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8570>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:26:39 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Apr 2010 17:26:39 +0000
Subject: [issue808164] socket.close() doesn't play well with __del__
Message-ID: <1272561999.12.0.631641271959.issue808164@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

How do I write a unit test to check that socket.__del__ doesn't refer to any globals?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue808164>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:27:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Apr 2010 17:27:09 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1272562029.61.0.233214246707.issue1820@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:36:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:36:01 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1272562561.85.0.447672431557.issue2715@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would close this, but I am not sure what the resolution should be.

----------
nosy: +tjreedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:38:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:38:02 +0000
Subject: [issue770280] PyMarshal_ReadLastObjectFromFile
Message-ID: <1272562682.32.0.794839852049.issue770280@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Can this be closed as either out-of-date or rejected?

----------
nosy: +tjreedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue770280>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:40:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:40:15 +0000
Subject: [issue3328] When PyObject_CallMethod fails, refcount is incorrect
In-Reply-To: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>
Message-ID: <1272562815.3.0.5411200792.issue3328@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3328>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:42:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:42:43 +0000
Subject: [issue3536] case conversion problems in Turkish
In-Reply-To: <1218369992.36.0.178922687211.issue3536@psf.upfronthosting.co.za>
Message-ID: <1272562963.32.0.9706278362.issue3536@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3536>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:43:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:43:54 +0000
Subject: [issue3957] [contextlib] Reverse order of locking
In-Reply-To: <1222268463.82.0.912581539287.issue3957@psf.upfronthosting.co.za>
Message-ID: <1272563034.28.0.262877387024.issue3957@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3957>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:44:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:44:36 +0000
Subject: [issue4262] import and compile() do not treat trailing whitespace the
	same
In-Reply-To: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za>
Message-ID: <1272563076.72.0.687468703128.issue4262@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4262>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:46:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:46:13 +0000
Subject: [issue3433] Mac, 3.0 framework install error with fink cp
In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
Message-ID: <1272563173.3.0.439635708311.issue3433@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3433>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:48:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:48:36 +0000
Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1
In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za>
Message-ID: <1272563316.34.0.112244703387.issue4025@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the absence of further complaints, this appears to really be fixed. Should it be closed as such?

----------
nosy: +tjreedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4025>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:50:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 17:50:51 +0000
Subject: [issue770280] PyMarshal_ReadLastObjectFromFile
Message-ID: <1272563451.45.0.484444746876.issue770280@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this is superseded by issue 7332, which is now fixed in trunk (but not in 2.6).

----------
nosy: +mark.dickinson, pitrou
resolution: remind -> out of date
status: open -> closed
superseder:  -> python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue770280>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:52:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:52:00 +0000
Subject: [issue1178510] configure: refuses setgroups
Message-ID: <1272563520.49.0.368194825364.issue1178510@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Closing this pending 2.4 Irix issue as out of date.
Martin, reopen if you object.

----------
nosy: +tjreedy
resolution:  -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1178510>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:53:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:53:08 +0000
Subject: [issue5407] Broken Py3.1 release build in Visual Studio 2005
In-Reply-To: <1236031704.37.0.216105327736.issue5407@psf.upfronthosting.co.za>
Message-ID: <1272563588.24.0.0347920820782.issue5407@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5407>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:53:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:53:43 +0000
Subject: [issue5494] Failure in test_httpservers on Linux
In-Reply-To: <1237124527.44.0.964288018613.issue5494@psf.upfronthosting.co.za>
Message-ID: <1272563623.02.0.422579375145.issue5494@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5494>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:54:16 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:54:16 +0000
Subject: [issue785031] MacPython installer fails on UFS filesystem
Message-ID: <1272563656.36.0.289571981726.issue785031@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue785031>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:54:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:54:38 +0000
Subject: [issue1004810] Carbon.File fails if server vol is mounted after launch
Message-ID: <1272563678.05.0.177187073729.issue1004810@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1004810>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:54:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 17:54:56 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1272563696.22.0.271204604717.issue2715@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as fixed.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:55:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 17:55:05 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1272563705.95.0.24429923827.issue2715@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:55:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:55:28 +0000
Subject: [issue1473979] test test_capi crashed -- thread.error: can't allocate
	lock
Message-ID: <1272563728.71.0.593821099599.issue1473979@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1473979>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:56:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:56:06 +0000
Subject: [issue658693] cPickle does relative import
Message-ID: <1272563766.43.0.961876686835.issue658693@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue658693>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:57:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:57:52 +0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1272563872.0.0.458014235457.issue2016@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is everything fixed, so this can be closed?

----------
nosy: +tjreedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:58:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:58:34 +0000
Subject: [issue1367628] use PyOS_ReadlineFunctionPointer in non-interractive
	input
Message-ID: <1272563914.64.0.452441890016.issue1367628@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367628>
_______________________________________

From report at bugs.python.org  Thu Apr 29 19:59:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 17:59:46 +0000
Subject: [issue1027] uudecoding (uu.py) does not supprt base64, patch attached
In-Reply-To: <1188155058.19.0.438776826235.issue1027@psf.upfronthosting.co.za>
Message-ID: <1272563986.69.0.312264788223.issue1027@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1027>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:00:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 29 Apr 2010 18:00:02 +0000
Subject: [issue8570] 2to3 crashes with "AttributeError: 'int' object has no
	attribute 'startswith'"
In-Reply-To: <1272553040.84.0.60116015533.issue8570@psf.upfronthosting.co.za>
Message-ID: <1272564002.38.0.546519118841.issue8570@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8570>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:00:18 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 18:00:18 +0000
Subject: [issue6788] codecs.open on Win32 does not force binary mode
In-Reply-To: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
Message-ID: <1272564018.46.0.111125855324.issue6788@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6788>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:02:30 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 29 Apr 2010 18:02:30 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1272564150.95.0.257687449702.issue8569@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:02:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 18:02:31 +0000
Subject: [issue6883] OptionParser.allow_interspersed_args is undocumented
In-Reply-To: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>
Message-ID: <1272564151.43.0.891135625101.issue6883@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Skip, can we close this?

----------
nosy: +tjreedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6883>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:03:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 18:03:03 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1272564183.38.0.575740409504.issue6941@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:05:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 18:05:58 +0000
Subject: [issue1756343] Python 2.5.1 fails to build on AIX
Message-ID: <1272564358.67.0.253129920398.issue1756343@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1756343>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:07:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 18:07:12 +0000
Subject: [issue1155] Carbon.CF memory management problem
In-Reply-To: <1189617951.85.0.870438592148.issue1155@psf.upfronthosting.co.za>
Message-ID: <1272564432.13.0.370417869534.issue1155@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Should this be closed? As out of date?

----------
nosy: +tjreedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1155>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:07:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 18:07:24 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272564444.78.0.40629400119.issue8572@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For backward compatibility this would have to be something more like:

    if not isinstance(default, list):
        if isinstance(default, string):
           default = [default]
        else:
           default = list(default)
    return ', '.join(self.headers_get_all(name, default))

Care to work up a patch, including unit test (it looks like the unit tests live in test_httplib)?

----------
components: +Library (Lib)
keywords: +easy
nosy: +r.david.murray
stage:  -> unit test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:08:50 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 18:08:50 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272564530.74.0.955460085377.issue8563@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hmm. I'm not sure that getting a SyntaxError is grounds for removing the __pycache__ directory.  I think I will commit the fix without that change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:09:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 18:09:05 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1272564545.23.0.204068468102.issue2571@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Too late for new 2.7 features.

----------
nosy: +tjreedy
resolution:  -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:09:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 18:09:38 +0000
Subject: [issue6306] filecmp.cmp can not compare two files from different OS
	with the same content
In-Reply-To: <1245321374.99.0.206303396049.issue6306@psf.upfronthosting.co.za>
Message-ID: <1272564578.33.0.689126315667.issue6306@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6306>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:13:38 2010
From: report at bugs.python.org (Walter Woods)
Date: Thu, 29 Apr 2010 18:13:38 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272564818.66.0.941161243794.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

Good point.  Yeah, I could do that within a week or two at the latest.  Just attach a .patch here when done?  And, what should the base be for the patch . . . the Lib/http directory?  Never submitted anything to python before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:16:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 18:16:04 +0000
Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1
In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za>
Message-ID: <1272564964.31.0.059129655173.issue4025@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sure.  It can always be reopened if the OP comes back and says it isn't fixed.  I'm closing it out of date because there are no references to checkins that fixed it.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4025>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:16:39 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 29 Apr 2010 18:16:39 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272564999.78.0.798226128853.issue8563@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

__pycache__ directory could be removed only when os.mkdir(cache_dir) has succeeded. Empty __pycache__ directory existing before call to compileall.compile_file() wouldn't be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:19:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 29 Apr 2010 18:19:32 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272565172.87.0.418773218776.issue8572@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Walter, have a look at http://www.python.org/dev/ document. It is really easy and attach it when its ready.
1) Create a patch against trunk (or py3k).
2) Patch against trunk/ or (py3k/ if its py3k only)
3) Lib/test/test_httplib.py might have similar tests, so build on top of  some existing test.
4) NEWS if applicable.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:21:46 2010
From: report at bugs.python.org (Andrew Straw)
Date: Thu, 29 Apr 2010 18:21:46 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272565306.8.0.156427459786.issue1054967@psf.upfronthosting.co.za>


Andrew Straw <astraw at users.sourceforge.net> added the comment:

Barry, I'm sorry I still don't understand what you think is the essential distinction. A debian source package (.dsc, .orig.tar.gz, and .diff.gz files) is simply made from a (patched) source directory, including the debian/ directory, and an upstream tarball. To build this sdist_dsc must of course make the debian/ directory. Thus, it "takes a non-Debianized source tree and turn it into a native [Debian source] package, essentially by pre-filling a debian/ directory like dh_make does, but including additional metadata available in the setup.py". Then, once it done this, it calls "dpkg-buildpackage -S" to turn this filesystem structure into the actual source package. If your final goal is simply the filesystem structure rather than the Debian source package (.dsc, .orig.tar.gz and .diff.gz), then it seems like it would be easier to refactor stdeb to stop before calling dpkg-buildpackage rather than writing a whole new alternate way of generating the debian/ directory based on the contents of setup.py.

So I'm afraid I still don't understand what you want setupdebian to do that stdeb does not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:21:48 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 29 Apr 2010 18:21:48 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1272565308.49.0.713722557283.issue1820@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

See also issue 8413, which would be addressed by this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:24:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 18:24:13 +0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1272565453.77.0.378207594254.issue2016@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It was merged to py3k in r73623, 3.1 in r73625, but not, as far as I can see, to 2.6.

----------
nosy: +r.david.murray
stage: patch review -> commit review
versions:  -Python 2.5, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:27:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 18:27:34 +0000
Subject: [issue6883] OptionParser.allow_interspersed_args is undocumented
In-Reply-To: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>
Message-ID: <1272565654.36.0.171167533781.issue6883@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since he hasn't proposed a patch, we close it :)

Skip can always reopen it if he wants.

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6883>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:34:18 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 29 Apr 2010 18:34:18 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1272566058.35.0.271124881854.issue1820@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I agree that the priority is higher now that we have a demonstrable regression.

Getting structseq to subclass from tuple will take some effort (tuples have many methods that would need to be overriden).

----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:41:18 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 18:41:18 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272566478.46.0.0325432642179.issue8563@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I guess I don't see the point in removing __pycache__ when the only .py file in the package directory has a SyntaxError.  I think that will be a rare case. Won't there usually be other .py files that compile just fine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:43:25 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 18:43:25 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272566605.05.0.928936923271.issue8563@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r80626

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:46:11 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 18:46:11 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272566771.48.0.548971120765.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi Andrew,

I want debian/ to be created in . (aka, cwd, the directory containing setup.py), not in ./deb_dist/package-version

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:47:13 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 29 Apr 2010 18:47:13 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272566833.44.0.360453081198.issue8563@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

compileall might be used to check if given package supports Python 3. There can be many .py files and all of them can contain syntax specific to Python 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:52:20 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 18:52:20 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272567140.17.0.17284788872.issue8563@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hmm.  In that case, I think you'd be expecting possible errors and would either have to clean up __pycache__ yourself or turn on legacy mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 20:57:58 2010
From: report at bugs.python.org (Walter Woods)
Date: Thu, 29 Apr 2010 18:57:58 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272567478.73.0.315297756291.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

David: Your example tests specifically for a string, but what about just converting default to a string always if it's not a list?  Otherwise the string join is just going to fail anyway (suppose an integer is passed, which is the case with couchdb-python).  Wouldn't


if not isinstance(default, list):
    default = [str(default)]

Be safer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:02:18 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 29 Apr 2010 19:02:18 +0000
Subject: [issue8563] [PEP 3147] compileall.compile_file() creates empty
	__pycache__ directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272567738.27.0.663645222922.issue8563@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I think that compilation of a single file should try to be an atomic operation, which doesn't leave an empty directory after failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8563>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:12:34 2010
From: report at bugs.python.org (Andrew Straw)
Date: Thu, 29 Apr 2010 19:12:34 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272568354.99.0.383490760965.issue1054967@psf.upfronthosting.co.za>


Andrew Straw <astraw at users.sourceforge.net> added the comment:

I see. So is copying the debian/ directory into its desired location a possibility for you, either manually or via a new distutils commands that shares 99% of its code with sdist_dsc? It doesn't seem like enough of a difference to start a new project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:23:56 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 19:23:56 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272569036.34.0.0721961314704.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Manual moving/copying is what I want to avoid.  I'd be totally happy with not reinventing the wheel if you think this would be easy to add to stdeb!  Specifically: just create debian/ in place and do not build package.

I have a few other minor suggestions, though if you think this isn't the best place to track them, please let me know where to submit them.

* Add setup.py entry_points so you don't have to use --command-packages
* Package: shouldn't change dots to dashes.  E.g. flufl.enum should be called python-flufl.enum
* Update to Standards-Version: 3.8.3

I'm happy to test whatever you come up with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:26:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Apr 2010 19:26:03 +0000
Subject: [issue1054967] bdist_deb - Debian packager
In-Reply-To: <1272543161.34.0.656500796088.issue1054967@psf.upfronthosting.co.za>
Message-ID: <4BD9DD15.9060504@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

tree and turns it into a source package that can be uploaded.  What I'm
looking for is
something that can take a non-Debianized source tree and turn it into a
native package,
essentially by pre-filling a debian/ directory like dh_make does, but
including additional
metadata available in the setup.py.
> 
> I've started taking a crack at this:

Barry, what do you mean with ?native package?? In Debian parlance, a
native package is a piece of software that isn?t released outside of
Debian and thus has no hyphen in the version number (a hyphen is
normally used to separate the upstream version number from a
debian-packaging-specific number, e.g. ?0.2-1?). I don?t know stdeb (I
avoid Setuptools), so I don?t understand the difference you make.

On a related note, I?ve seen in your setupdebian code that you
unconditionally remove some files under the debian directory, but some
of them may be useful, especially for building multiple binary packages
(i.e. separate installable .deb packages) out of one source package,
e.g. to split architecture-independent modules from arch-dependent C
extensions (like mercurial and mercurial-common). More info:
- how to build multiple binary packages: http://wiki.debian.org/PkgSplit
http://lists.debian.org/debian-python/2009/09/msg00091.html
- questioning usefulness of PEP 345 for automation of deb packaging:
http://lists.debian.org/debian-python/2009/11/msg00076.html
- extensions to Distutils that may meet some debian packaging needs:
http://bazaar.launchpad.net/~python-distutils-extra-hackers/python-distutils-extra/debian/files
- rough proposal by myself for support in Distutils2:
http://wiki.python.org/moin/Distutils/Proposals/SplitAndCompoundDistributions

HTH

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:28:53 2010
From: report at bugs.python.org (Ken Ganong)
Date: Thu, 29 Apr 2010 19:28:53 +0000
Subject: [issue1343] XMLGenerator: nice <empty/> elements
In-Reply-To: <1193492035.12.0.0580891111126.issue1343@psf.upfronthosting.co.za>
Message-ID: <1272569333.88.0.857403739895.issue1343@psf.upfronthosting.co.za>


Ken Ganong <ken.ganong at gmail.com> added the comment:

This bug is tagged as easy and appears to already have a patch and a test posted from two years ago. What is still to be done here?

----------
nosy: +ken.ganong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1343>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:34:20 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 29 Apr 2010 19:34:20 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272569660.28.0.859851219243.issue7865@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


Removed file: http://bugs.python.org/file17077/no_swallow_on_close2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:35:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Apr 2010 19:35:24 +0000
Subject: [issue1343] XMLGenerator: nice <empty/> elements
In-Reply-To: <1193492035.12.0.0580891111126.issue1343@psf.upfronthosting.co.za>
Message-ID: <1272569724.41.0.0368090464228.issue1343@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I added the ?needs review? keyword, to make this easy to find for reviewers, changed the version (new features don?t go in older versions; check if your patches still apply), and added MvL as nosy, since he?s listed as expert for the xml package in py3k/Misc/maintainers.rst

----------
keywords: +needs review
nosy: +loewis, merwok
stage:  -> patch review
versions: +Python 3.3 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1343>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:35:27 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 19:35:27 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272569727.29.0.818992050397.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Eric, you're right, "native" isn't exactly what I was getting at.  I want the debian/ directory created right next to the setup.py, as I've described in some follow ups.

As far as what you see in setupdebian, this is just preliminary experiments using test-driven development.  I had intended to support switches for other types of packaging options, but first things first.  Since Andrew is willing, I'd rather work with him to get some of the features I'd like to see rather than continue with a separate package, so if that proves fruitful, I'll abandon setupdebian.

BTW, have you seen the python-debian package?  It seems to have a lot of useful stuff for manipulating changelogs, control files and such.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:47:51 2010
From: report at bugs.python.org (hhas)
Date: Thu, 29 Apr 2010 19:47:51 +0000
Subject: [issue1155] Carbon.CF memory management problem
In-Reply-To: <1189617951.85.0.870438592148.issue1155@psf.upfronthosting.co.za>
Message-ID: <1272570471.54.0.591112909696.issue1155@psf.upfronthosting.co.za>


hhas <hhas at users.sourceforge.net> added the comment:

The Carbon extensions are deprecated in Python 2.6 and absent in Python 3, and PyObjC provides a far better alternative. I'd be surprised if this issue affects any users at this point (chances are I'm the only one who was ever bothered by it, and I eliminated all Carbon extension dependencies from my code in 2008). So I would recommend closing it as won't fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1155>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:50:35 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 29 Apr 2010 19:50:35 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272570635.56.0.544978624012.issue7865@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Here is a code/test patch which *should* fix the multiple close() case, and ensure flush() raise an error on closed file. 

All IO test suites pass on my win32 (except test_largefile that I skip due to lack of hdd space).


I've noticed that the detach() semantic was quite different between _pyio and _io, by the way: C code raises valueerror when we try to access the stream after detaching it, whereas python lets attribute errors be raised. But maybe this is not so important, as these are programming errors anyway.

One thing I'm still wondering : why couldn't we obtain these C extension by cythonizing _pyio ? Are there features that cython lacks, or optimization considerations I'm not aware of ? Cython-generated extensions seem soooo easier to maintain...

----------
Added file: http://bugs.python.org/file17132/no_swallow_on_close3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Thu Apr 29 21:55:55 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 29 Apr 2010 19:55:55 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272570955.08.0.801360748845.issue7584@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> I do not think that -00:00 or +00:00 will be invalid Atom timestamp,
> but to implement parser of rfc3339 timestamp, Z handling is still
> needed. I can easily imagine people making wrong assumption that
> parsing 00:00 at the end would be enough for proper round-tripping.

I can't follow you. This issue and my patch is about creating a string in RFC 3339 format, not *parsing*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:16:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Apr 2010 20:16:16 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272572176.27.0.4493226767.issue7865@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But maybe this is not so important, as these are programming errors
> anyway.

Agreed :)

> One thing I'm still wondering : why couldn't we obtain these C
> extension by cythonizing _pyio ? Are there features that cython lacks, 
> or optimization considerations I'm not aware of ? Cython-generated
> extensions seem soooo easier to maintain...

Several reasons:
- we don't want to depend on an external tool such as cython; the interpreter and its most critical modules just need a C compiler and a reasonably standard C library
- the language cython implements is not Python: it is both a superset and (more annoyingly) a subset of Python
- cython will not allow us, I think, to do as many optimizations as we do in the C version of the io library; the algorithms used are not the same as in the Python version, since raw C allows some much more efficient constructs (especially for handling memory buffers)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:16:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Apr 2010 20:16:28 +0000
Subject: [issue1054967] bdist_deb - Debian packager
In-Reply-To: <1272569727.29.0.818992050397.issue1054967@psf.upfronthosting.co.za>
Message-ID: <4BD9E904.3000509@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Barry, IIUC you want the ?debian? command to create a debian source
package, which can be converted to debian binary package(s), checked and
uploaded with standard tools. Perfect.

Andrew, I am uncomfortable with stdeb. (Trying to express respectful
constructive critique, not just picking on your project.) The version in
Debian testing, 0.5.1-1, still requires setuptools (actually only
pkg_resources, which is split into another package in Debian, for space
or politic reasons). The py2dsc script seems to be obsoleted by the
to-be ?debian? command. The pypi-install script seems dangerous to me,
because downloading unverified software and putting it into the system
seems a rather bad idead (a.k.a. ?sudo ./setup.py install considered
harmful?).

python-debian provides useful support code for generating and reading
debian formats. A quick read show the code would benefit from some 2.6
modernizing (i.e. gain in simplicity and readability by using modern
idioms and stdlib functions). Would using this package in stdeb /
distutils2.command.debian instead of shelling out bring anything?

(Sorry about the badly wrapped paragraph I forgot to remove in my
previous message. And sorry to write so much words instead of code ;)

acute-accent-ly yours

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:21:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 20:21:43 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1272572503.75.0.806052426447.issue2211@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This looks like it would be a worthwhile cleanup, and the issue contains useful info to that end, so I'm marking it languishing rather than closing it, in the hopes that someone will pick it up some day.  I also think this could be a nice bug day task for someone, (though it might take all day :), so I'm adding the easy keyword.

(From the sounds of Jamie's second post, he may have thought he uploaded a patch, but didn't...)

Note: I suspect the logic of having 'unset' keys return an empty string is that a Morsel is supposed to have a "fixed set" of keys (and thus those keys should always be there).  I'm not sure that should be changed.

----------
keywords: +easy
nosy: +r.david.murray
stage:  -> unit test needed
status: pending -> languishing
versions: +Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:27:42 2010
From: report at bugs.python.org (Tres Seaver)
Date: Thu, 29 Apr 2010 20:27:42 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1272572862.95.0.886983732931.issue2091@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I can confirm that:

- the patch applies cleanly to the release26-maint branch, with the
  exception of the Misc/NEWS portion::

  $ hg branch
  release26-maint
  $ ./python -E -tt Lib/test/regrtest.py test_file
  test_file
  1 test OK.
  $ patch -p0 < /tmp/issue2091.diff 
  patching file Objects/fileobject.c
  Hunk #1 succeeded at 209 (offset 54 lines).
  Hunk #2 succeeded at 2269 (offset 194 lines).
  patching file Misc/NEWS
  Hunk #1 FAILED at 12.
  1 out of 1 hunk FAILED -- saving rejects to file Misc/NEWS.rej
  patching file Lib/test/test_file.py
  Hunk #1 succeeded at 176 (offset 55 lines).

- the added test fails before rebuilding Objects/fileobject.c::

  $ ./python -E -tt Lib/test/regrtest.py test_file
  test_file
  test test_file failed -- Traceback (most recent call last):
    File "/home/tseaver/projects/hg-repo/py-2.6/Lib/test/test_file.py", line 181, in testModeStrings
      f = open(TESTFN, mode)
  IOError: [Errno 2] No such file or directory: '@test'
  
  1 test failed:
      test_file

- the added test passes after rebuilding Objects/fielobject.c::

  $ make
  gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Objects/fileobject.o Objects/fileobject.c
  ...
  $ ./python -E -tt Lib/test/regrtest.py test_file
  test_file
  1 test OK.

----------
nosy: +tseaver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:30:29 2010
From: report at bugs.python.org (Longpoke)
Date: Thu, 29 Apr 2010 20:30:29 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>


New submission from Longpoke <longpoke at gmail.com>:

This function in asyncore is buggy:

def _strerror(err):
    res = os.strerror(err)
    if res == 'Unknown error':
        res = errorcode[err]
    return res

- os.strerror may throw ValueError depending on the os, or return a string saying something like: "Unknown error 1234".
- os.strerror never returns "Unknown error" for me, so "Unknown error <err>" is always returned for me (Linux 2.6.32)
- if os.strerrror failed, it's likely that it wont be in errno.errcode either

Maybe it should be written like this:
def _strerror(err):
    try:
        return strerror(err)
    except ValueError:
        return "Unknown error {0}".format(err)

----------
components: Library (Lib)
messages: 104583
nosy: q94IjzUfnNoyv4c75mMw
priority: normal
severity: normal
status: open
title: Buggy _strerror in asyncore
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:32:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 29 Apr 2010 20:32:32 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1272573152.14.0.891111794971.issue8569@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IIUC, Python is not affected by this security issue. 'short' is a 16-bit integer, so it only affects 0.9.8m, which isn't being used by Python. Therefore, from a security point of view, no action needs to be taken.

I don't think upgrading OpenSSL is appropriate for 2.7 at this point, so removing it from the version list.

For updating OpenSSL for 3.2, multiple occurrences must be changed; external-common is not the only place. At a minimum, PCbuild/pyproject.vsprops and PCbuild/readme.txt need to change as well. The OpenSSL tree needs to be imported into the externals repository, and our custom changes need to be reapplied. Whether further changes need to be applied to the source, can only be determined in testing. As all of this is a rather tedious procedure, we should be certain to only perform it once before the release of 3.2 (i.e. if we upgrade now, we shouldn't upgrade again three months from now).

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:32:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Apr 2010 20:32:51 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1272573171.57.0.316241046133.issue2091@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:33:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 29 Apr 2010 20:33:17 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1272573197.54.0.889901617014.issue8569@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:40:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Apr 2010 20:40:56 +0000
Subject: [issue1155] Carbon.CF memory management problem
In-Reply-To: <1189617951.85.0.870438592148.issue1155@psf.upfronthosting.co.za>
Message-ID: <1272573656.84.0.156749324451.issue1155@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1155>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:43:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 20:43:41 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272573821.29.0.869459686927.issue8572@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, because my code is a backward compatibility hack.  Currently if someone is passing a default successfully they must be doing it by passing in a list or tuple consisting of one or more strings.  So your code would result in something like:

  >>> ', '.join([str(['abc'])])
  "['abc']"

However, you are correct that if default is some object other than a list, it is either going to work in the ', ' or it isn't, so there's no need to call list on it.  So my code should be simplified to:

    if isinstance(default, string):
       default = [default]
    return ', '.join(self.headers_get_all(name, default))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:52:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 29 Apr 2010 20:52:17 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272574337.0.0.835347500297.issue8572@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

And also, the code which is using getheader of HTTPResponse object would mostly (but incorrectly in py3k) be passing a string as default. The HTTP headers have been a dict with key,values as strings. Counchdb-python - does this make HTTP reqs? I am not sure if having int-values in the header values is proper.

So, David's last e.g seems just fine. Check if it is string and for the code's requirement, make it a list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:52:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 29 Apr 2010 20:52:59 +0000
Subject: [issue8543] asynchat documentation issues
In-Reply-To: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>
Message-ID: <1272574379.04.0.456854243253.issue8543@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

As per discussion with Josiah I'm leaving fifo class alone as it can still be used also with the newer producer_fifo implementation (changed in Python 2.6).
The other changes described in my comments above still hold.
Committed in r80631 (2.7), r80632 (2.6), r80633 (3.2) and r80634 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8543>
_______________________________________

From report at bugs.python.org  Thu Apr 29 22:55:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 20:55:20 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1272574520.06.0.0406782514274.issue8573@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +giampaolo.rodola, josiahcarlson
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Thu Apr 29 23:05:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 21:05:39 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272575139.45.0.254354691034.issue8572@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@senthil: I'm not quite sure what your sentence referencing couchdb is getting at, but the headers that are being queried are in an email.Message object, and contain only string values unless some code is misusing the API and setting new non-string values after the initial header parse is has been done.

Regardless, though, my suggested change makes the code work with the documented API (which strongly implies that default is a string) while continuing to accept any previously working values that existing code may be passing in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 23:07:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Apr 2010 21:07:47 +0000
Subject: [issue8570] 2to3 crashes with "AttributeError: 'int' object has no
	attribute 'startswith'"
In-Reply-To: <1272553040.84.0.60116015533.issue8570@psf.upfronthosting.co.za>
Message-ID: <1272575267.14.0.670940630371.issue8570@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the report. Fixed in r80637.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8570>
_______________________________________

From report at bugs.python.org  Thu Apr 29 23:13:19 2010
From: report at bugs.python.org (Walter Woods)
Date: Thu, 29 Apr 2010 21:13:19 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272575599.71.0.170919903893.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

couchdb-python makes http requests, yes.  

Passing in a number might be mildly inappropriate, BUT I'd like to point out that the default might be used to find out if the header is not set (hence its default value of None).  

It should not assume that a string is the proper input; any sentinel value should work (especially as python is dynamic, and the default parameter is not actually used for the function's logic).

Which goes back to the original patch, unless a list or tuple is provided, in which case the list is comma joined for backwards compatibility as suggested by David.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 23:19:24 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Apr 2010 21:19:24 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272575964.46.0.246028173584.issue1054967@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

?ric, sorry about missing that accent.  /me needs a bigger font. :)

RE: python-debian modernization.  We'd have to check with the authors to see what version of Python they need to remain compatible with.  If it's 2.6, then I'm all for modernizing.

I'm not a huge fan of shelling out to get the debian directory, but dh_make seems to be what people want to emulate.  I was planning on using python-debian to fill out e.g. debian/control with information that dh_make couldn't easily be convinced to create.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Apr 29 23:20:04 2010
From: report at bugs.python.org (Walter Woods)
Date: Thu, 29 Apr 2010 21:20:04 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272576004.31.0.53610443176.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

Little more info:

The actual snippet from couchdb-python is:

  if int(resp.getheader('content-length', sys.maxsize)) < CHUNK_SIZE:

Which should be valid python . . . calling int() on an integer should work, and calling int() on a string expected to be an integer should work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Thu Apr 29 23:24:41 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 29 Apr 2010 21:24:41 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1272576281.14.0.196088572282.issue8573@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Good catch. I modified your patch a little bit including a catch for OverflowError exception and a last attempt to look up into errno.errorcode:

def _strerror(err):
    try:
        return strerror(err)
    except (ValueError, OverflowError):
        if err in errorcode:
            return errorcode[err]
        return "Unknown error %s" %err

Josiah, what do you think?

----------
assignee:  -> giampaolo.rodola
keywords: +easy
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Fri Apr 30 00:24:42 2010
From: report at bugs.python.org (Tres Seaver)
Date: Thu, 29 Apr 2010 22:24:42 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1272579882.94.0.293677484972.issue1285086@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I'm uploading a saner version of the speed test which uses timeit's support for passing a callable as a statement:  it is much easier to
see what the test is actually doing.

On my machine, running against the release26-maint branch, my version runs anywhere from 67% to 85% faster on the cases where no quoting actually needs to be done.  In production use, where urlib.quote is used as a safety check, these cases far outweigh the cases which actually require quoting.

----------
Added file: http://bugs.python.org/file17133/urllib_better_speed_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Fri Apr 30 00:29:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 29 Apr 2010 22:29:37 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1272580177.29.0.656981550817.issue1641@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Assuming this is still desirable I'd really like to move forward with this issue.
The current situation is that we have two patches.

My patch
========

pros: 
 * affects asyncore.py only
 * (imho) cleaner, as it just adds one class
 * stable, as it has been used in pyftpdlib for over 3 years now

cons:
 * significantly slower compared to Josiah's "paired-heap" approach 


Josiah's patch
==============

pros:
 * significantly faster

cons:
 * affects asyncore.py and sched.py
 * sched.py is modified quite heavily, also it's not clear whether that has been done in a fully retro-compatible way or not, so a full review from someone who has experience with this module would be needed
 * it seems that sched.py gains brand new functionnalities which are not necessarily related with asyncore, hence tests and documentation should be added. Furthermore, belonging them to sched.py, maybe they should be treated in a separate issue


Both patches should no longer apply cleanly so they should be adjusted a little and the missing parts (full tests, documentation including example usage, etc...) completed.
It seems we both agree on the API, which is both simple and has the extra advantage of being the same as Twisted's.
Now it's only a matter of deciding what to do about the internal implementation.

----------
nosy: +pitrou, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Fri Apr 30 01:43:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Apr 2010 23:43:56 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Many tests of the Python test suite depends on the availability of websites, especially www.python.org. Python.org has some troubles since some days, and many buildbots failed (test_robotparser failure).

I propose to use a default timeout of 60 seconds in transient_internet(), and then use transient_internet() in tests using the internet.

Patches:
 - transient_internet.py: set temporary the defalt socket timeout to 60 seconds (and then restore the previous default value), and catch also weird IOError (which contain in socket.error as the 2nd argument) from urllib
 - test_robotparser_transient_internet.py: use "with transient_internet():" to do not hung anymore (for 1800 seconds!) if a website is down

On Linux, you can use "iptables -I OUTPUT -p tcp --dport 80 -j DROP" (drop all outgoing packets) to simulate a network failure, and set the default timeout value of transient_internet() to 3 seconds.

----------
files: transient_internet.patch
keywords: patch
messages: 104596
nosy: haypo
priority: normal
severity: normal
status: open
title: transient_internet() (test_support): use socket.setdefaulttimeout() and test_robotparser failure
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17134/transient_internet.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Fri Apr 30 01:44:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Apr 2010 23:44:05 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272584645.45.0.33509984224.issue8574@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17135/test_robotparser_transient_internet.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Fri Apr 30 01:59:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Apr 2010 23:59:41 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272585581.87.0.0174853095279.issue8574@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, transient_internet.patch doesn't catch socket.error(errno.ETIMEDOUT, ...). Fixed by patch version 2.

----------
Added file: http://bugs.python.org/file17136/transient_internet-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Fri Apr 30 01:59:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Apr 2010 23:59:47 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272585587.1.0.612486963449.issue8574@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17134/transient_internet.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:00:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:00:21 +0000
Subject: [issue8499] Set a timeout in test_urllibnet
In-Reply-To: <1271948172.1.0.95585075241.issue8499@psf.upfronthosting.co.za>
Message-ID: <1272585621.83.0.527983983954.issue8499@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8574.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8499>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:00:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:00:29 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272585629.42.0.489608282028.issue8574@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8499.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:17:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:17:02 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272586622.92.0.767617540729.issue8574@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 3 to prepare a patch for #8499: don't change socket default timeout if the timeout argument is None.

----------
Added file: http://bugs.python.org/file17137/transient_internet-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:17:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:17:09 +0000
Subject: [issue8574] transient_internet() (test_support): use
	socket.setdefaulttimeout() and test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272586629.47.0.138134193766.issue8574@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17136/transient_internet-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8574>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:19:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:19:33 +0000
Subject: [issue8499] Set a timeout in test_urllibnet
In-Reply-To: <1271948172.1.0.95585075241.issue8499@psf.upfronthosting.co.za>
Message-ID: <1272586773.38.0.774700402417.issue8499@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch to use transient_internet() context manager: the patch requires transient_internet-xxx.patch of issue #8574.

----------
dependencies: +transient_internet() (test_support): use socket.setdefaulttimeout() and test_robotparser failure
keywords: +patch
Added file: http://bugs.python.org/file17138/test_urllibnet_transient_internet.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8499>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:30:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:30:26 +0000
Subject: [issue8560] regrtest: add a minimal "progress bar"
In-Reply-To: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>
Message-ID: <1272587426.75.0.028970478543.issue8560@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I personally am fine with judging the progress by the filenames

The new displayed test names only inform you that regrtest is not blocked, but you don't know how many tests remain if:
 - you use -j option (which shuffle the list at little bit)
 - you use -r (random): I think that the buildbots use them. If a buildbot hang, it's not easy to see how many tests were executed (and how many remain)
 - you specify a list of test names on the command line

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8560>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:33:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:33:09 +0000
Subject: [issue8560] regrtest: add a minimal "progress bar"
In-Reply-To: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>
Message-ID: <1272587589.45.0.0981564718542.issue8560@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Higher/lower bounds for me:
 - Quad core @ 2.5 GHz with -j4: 2 min 40 sec
 - Pentium4 @ 3 GHz (hyperthreading) without -j: 11 min 21 sec

Sometimes I forget to use -j, and sometimes I cannot use it (eg. see my last patches to support --without-threads ;-)).

When it takes more than 30 seconds, I would like a progress bar to estimate (myself) the remaing time :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8560>
_______________________________________

From report at bugs.python.org  Fri Apr 30 02:54:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 00:54:44 +0000
Subject: [issue8559] test_gdb: test_strings() fails with ASCII locale
In-Reply-To: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>
Message-ID: <1272588884.68.0.187711874274.issue8559@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch using raw string instead of the unicode character directly to avoid the locale issue. I'm not sure that we really test unicode support of the gdb library using my patch.

I also get another error: << AssertionError: "'\\\\U0001D121'" did not equal expected "'\\U0000d834\\U0000dd21'" >>. The problem is that test_gdb tests sys.maxunicode whereas gdb may use a different Python library (eg. Python2 whereas we are using Python3) not using the same unicode option (narrow vs wide unicode). The test should ask gdb for its sys.maxunicode value.

----------
keywords: +patch
Added file: http://bugs.python.org/file17139/test_gdb_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8559>
_______________________________________

From report at bugs.python.org  Fri Apr 30 03:01:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 01:01:04 +0000
Subject: [issue8559] test_gdb: test_strings() fails with ASCII locale
In-Reply-To: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>
Message-ID: <1272589264.12.0.829922033344.issue8559@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The test should ask gdb for its sys.maxunicode value.

Ok, done in a new version of the patch.

test_gdb now pass with and without locale (utf8 and ascii).

The patch is for py3k. test_gdb in Python trunk doesn't test has the unicode tests in test_strings() function.

----------
Added file: http://bugs.python.org/file17140/test_gdb_unicode-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8559>
_______________________________________

From report at bugs.python.org  Fri Apr 30 03:01:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 01:01:08 +0000
Subject: [issue8559] test_gdb: test_strings() fails with ASCII locale
In-Reply-To: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>
Message-ID: <1272589268.56.0.871519523605.issue8559@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17139/test_gdb_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8559>
_______________________________________

From report at bugs.python.org  Fri Apr 30 03:05:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 01:05:53 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1272589553.23.0.930535231139.issue8390@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

lars: Do you have an opinion about this suggestion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8390>
_______________________________________

From report at bugs.python.org  Fri Apr 30 03:16:03 2010
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 30 Apr 2010 01:16:03 +0000
Subject: [issue775964] fix test_grp failing on RedHat 6.2
Message-ID: <1272590163.13.0.847664408297.issue775964@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I don't have a host where I actually use netgroups in /etc/groups, and so can't provoke the bug::

  $ hg branch
  release26-maint
  $ make
  ...
  $ ./python -E -tt Lib/test/regrtest.py test_grp
  test_grp
  1 test OK.

I can verify that the patch still applies to the 'release26-maint' branch::

  $ patch -p0 < /tmp/grp.diff 
  patching file Modules/grpmodule.c
  Hunk #1 succeeded at 134 (offset 12 lines).

and that the tests still pass aftewards::

  $ make
  ...
  $ ./python -E -tt Lib/test/regrtest.py test_grp
  test_grp
  1 test OK.

----------
nosy: +tseaver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Fri Apr 30 03:55:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Apr 2010 01:55:54 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272592554.53.0.227983318188.issue8572@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I seem to have been missing some context here.  I now understand that this is a regression relative to Python 2.x.  It seems to me that the translation from rfc822.Message to email.Message was done incorrectly.  In the 2.x code getheader returns only the value of the first header with the given name, in the 3.x code it returns the comma separated concatenation of the values of all headers with that name, and breaks the handling of default.

Any idea which handling of header values is actually the correct behavior vis-a-vis the http protocol?

Either way, the translation broke 'default', and that should be fixed, especially since we know there is 2.x code depending on the documented behavior, and the documented behavior hasn't changed in 3.x.  Since it is a regression, I'm inclined to think we can get away with fixing it without preserving backward compatibility with 3.1.2 (ie: it's a bug, and no one is likely to have written code to work around the bug, they'd report it instead as Walter did). But my opinion on that should perhaps be verified by appeal to python-dev, once we've agreed on what the correct behavior of the routine should be given multiple headers with the same name.

I'm adding hdiogenes and barry as nosy since they were the principle people involved in the translation, but they may not remember why this particular change was made.  As far as I can see the change is in the patch Barry applied but not in hdiogenes' original patch in the relevant issue (issue 2848), so there is probably some discussion missing from the issue.

----------
nosy: +barry, hdiogenes
priority: normal -> high
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Fri Apr 30 04:26:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 30 Apr 2010 02:26:06 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272592554.53.0.227983318188.issue8572@psf.upfronthosting.co.za>
Message-ID: <20100430022554.GA15689@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Fri, Apr 30, 2010 at 01:56:01AM +0000, R. David Murray wrote:
> 
> I seem to have been missing some context here. 

I was referring to Walter's comment on default being an int, like
HTTPResponse.getheader('Fake-Content-Length',default=42). It was
surprising to me, but the he provided a sample snippet and pointed out
that default value can be None. So, yes, just checking of string value
might not give the correct results in all circumstances (esp
default=None case which is strong).

>In the 2.x code getheader returns only the value of the first header
>with the given name, in the 3.x code it returns the comma separated
>concatenation of the values of all headers with that name, and breaks
>the handling of default.
> 
> Any idea which handling of header values is actually the correct
> behavior vis-a-vis the http protocol?

I believe, 2.x version is proper. I was surprised at get_all() method
introduced too, instead of getheader (if its present in Message)

Headers is a simply a dict and getheader is similar to dict.get(key,
default). I shall look up the HTTP RFC and confirm what should be done
if multiple values exists for same header.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Fri Apr 30 04:39:15 2010
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 30 Apr 2010 02:39:15 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1272595155.16.0.764651452625.issue4180@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

The attached patch fixes the OP's use case on the Python side by re-ordering the tests, such that "always" prevents the short-circuit from firing::

 $ ./python 
 Python 2.6.5+ (release26-maint, Apr 29 2010, 21:24:12) 
 [GCC 4.3.3] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import warnings as o_warnings
 >>> import sys
 >>> sys.modules['_warnings'] = 0
 >>> del sys.modules['warnings']
 >>> import warnings as py_warnings
 >>> def f():
 ...     py_warnings.warn('foo')
 ... 
 >>> f()
 __main__:2: UserWarning: foo
 >>> f()
 >>> py_warnings.simplefilter('always')
 >>> f()
 __main__:2: UserWarning: foo
 >>> f()
 __main__:2: UserWarning: foo

----------
components: +Library (Lib) -Interpreter Core
nosy: +tseaver
type: behavior -> 
Added file: http://bugs.python.org/file17141/issue4180-py_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Fri Apr 30 04:47:59 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Fri, 30 Apr 2010 02:47:59 +0000
Subject: [issue8557] subprocess PATH semantics
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272595679.26.0.00752879784443.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I wrote a Python script (enclosed) to methodically test how these things work, that doesn't rely on peculiarities of sys.executable.  The tests did reveal some notable differences on *nix and 'doze:

* When shell=False on windows you must launch the process using a full filename (e.g. "foo.exe", not just "foo", pass --invoke-filename to the script to enable that).  This may seem obvious to you, but for me it was surprising that one executable lookup function (looking in PATH) is in effect but not the other (extending unqualified executable names).  This should be spelled out in the docs.

* On *nix, with shell=False and the executable is neither in the PATH in the environment at the time of Python's launch nor in os.environ at the time of Popen, passing Popen an explicit env whose PATH includes the executable is enough to cause it to be found.  Not so on 'doze. 

* On 'doze, when the executable is in the PATH of os.environ but not in that of Popen's explicit env argument, even with shell=False, no Exception is raised (but returncode is nonzero)

----------
Added file: http://bugs.python.org/file17142/probe.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Fri Apr 30 06:15:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 04:15:24 +0000
Subject: [issue8575] Update/reorganize _winreg documentation
In-Reply-To: <1272600924.34.0.491501715071.issue8575@psf.upfronthosting.co.za>
Message-ID: <1272600924.34.0.491501715071.issue8575@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

This patch cleans up the use of a few external MSDN links, adds a bunch of constants which were previously undocumented, and reorganizes a table to fit in with those constants.

Patch uploaded to http://codereview.appspot.com/969045 for review.

----------
assignee: brian.curtin
components: Documentation, Windows
files: winreg_doc_update.diff
keywords: needs review, patch, patch
messages: 104612
nosy: brian.curtin, ezio.melotti
priority: normal
severity: normal
stage: patch review
status: open
title: Update/reorganize _winreg documentation
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17143/winreg_doc_update.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8575>
_______________________________________

From report at bugs.python.org  Fri Apr 30 10:24:05 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 30 Apr 2010 08:24:05 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272615845.67.0.502026603127.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Dave, 

The behavior of your patch on Windows XP/2003 (and earlier) might be related to the way Windows boosts thread priority when it is signaled. 

Try to increase priority of monitor thread and slice size. Another thing to look at is how to prevent Python CPU bound threads from (starving) messing up scheduling of threads of other processes. Maybe increasing slice significantly can help in this too (50ms++ ?).

XP/NT/CE scheduling and thread boosting affect all patches and the current GIL undesirably (in different ways). Maybe it is possible to make your patch work nicely on these systems:
http://www.sriramkrishnan.com/blog/2006/08/tale-of-two-schedulers-win_115489794858863433.html

Vista and Windows 7 involve CPU cycle counting which results in more sensible scheduling:
http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Apr 30 11:18:06 2010
From: report at bugs.python.org (Paul Moore)
Date: Fri, 30 Apr 2010 09:18:06 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

test_support.find_unused_port attempts to find an unused port to use. The approach is fragile (as noted in the docstring) in certain cases. In particular, it appears that Windows takes a short time to free the socket after it is closed, meaning that when the caller tries to open a socket on the returned port number, it gets permission issues.

A sleep(0.1) just before returning the port number appears to address the issue, but this is not a proper solution.

http://msdn.microsoft.com/en-us/library/ms737582%28v=VS.85%29.aspx describes the SO_LINGER and SO_DONTLINGER socket options, which may be related, but in my initial tests I haven't been able to get these to work.

----------
components: Tests, Windows
keywords: buildbot
messages: 104614
nosy: pmoore
priority: normal
severity: normal
status: open
title: test_support.find_unused_port can cause socket conflicts on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8576>
_______________________________________

From report at bugs.python.org  Fri Apr 30 11:19:03 2010
From: report at bugs.python.org (Paul Moore)
Date: Fri, 30 Apr 2010 09:19:03 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272619143.11.0.98432617006.issue8576@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8576>
_______________________________________

From report at bugs.python.org  Fri Apr 30 12:00:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Apr 2010 10:00:42 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272621642.48.0.355434922262.issue8576@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, exarkun, tim.golden
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/issue8576>
_______________________________________

From report at bugs.python.org  Fri Apr 30 12:18:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 30 Apr 2010 10:18:30 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272622710.69.0.5674036365.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The point is that your implementation doesn't allow people to generate 'Z'-ending timestamp if they need a subset of rfc3339.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Fri Apr 30 12:40:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 10:40:04 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

When I build the trunk with srcdir != builddir test_distutils fails when running tests.

To reproduce:
* Create a checkout of the trunk and chdir into this
* mkdir build
* cd build
* ../configure
* make test

This results in a failure for test_distutils

----------
assignee: tarek
components: Distutils, Library (Lib)
messages: 104616
nosy: ronaldoussoren, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils fails if srcdir != builddir
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:05:43 2010
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 30 Apr 2010 11:05:43 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1272625543.65.0.345479514344.issue4180@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

This patch tidies up the FilterWarnings tests to nomalize use of 'self.assertEquals' (matching the rest of the module) and make the 'test_always' assertions meaningful.

----------
Added file: http://bugs.python.org/file17144/issue4180-test_janitorial.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:07:41 2010
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 30 Apr 2010 11:07:41 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1272625661.03.0.409847047039.issue4180@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

This patch adds tests for the 'error', 'ignore', and 'always' filters being applied *after* the default warning has been issued, and therefore the registry populated.  It causes failures for the 'error' and 'always' on both the Python and C sides.

----------
Added file: http://bugs.python.org/file17145/issue4180-test_filter_after_default.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:10:31 2010
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 30 Apr 2010 11:10:31 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1272625831.12.0.494520707231.issue4180@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

This patch replaces my earlier 'py_warnings' patch.  It revamps the Python side to check filters before deciding not to emit the warning based on the registry.  The new "<filter>_after_default" tests pass on the Python side with this patch.

----------
Added file: http://bugs.python.org/file17146/issue4180-py_warnings2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:14:46 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 11:14:46 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272626086.34.0.572563581138.issue8577@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

distutils.sysconfig.get_python_inc() uses  "os.path.dirname(os.path.abspath(sys.executable))" to find the srcdir.

I'll change it to "sysconfig.get_config_var('srcdir')"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:21:55 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 11:21:55 +0000
Subject: [issue3646] MacOS X framework install to non-standard directory fails
In-Reply-To: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
Message-ID: <1272626515.15.0.313253304845.issue3646@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

In r80647 (trunk) you can use "configure --enable-framework=$HOME/Library/Frameworks" to get the right situation:

- Framework in ~/Library/Frameworks
- Apps in ~/Applications/Python 2.7
- Command-line tools in ~/bin

I will port this to 3.2 later on, but won't backport to 2.6 and 3.1.

----------
resolution:  -> fixed
versions: +Python 2.7, Python 3.2 -Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3646>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:22:30 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 11:22:30 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272626550.22.0.445909538227.issue8577@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Mmm, the problem is that srcdir is given by the Makefile. So I need to find the Makefile. I don't know how to get these info from a python built in another directory. Investigating...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:27:58 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 11:27:58 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272626878.58.0.520488234615.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

get_config_var('srcdir') should work, with should then be combined with the path to the Makefile, something like:

os.path.join(
   os.path.dirname(os.path.abspath(
      _get_makefile_filename(), get_config_var('srcdir')))

The path.join is necessary because srcdir is most likely a relative path (in my example the value is 'srcdir')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:34:18 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 11:34:18 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272627258.37.0.436683644593.issue8577@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This won't work because in the build dir, srcdir is set to ".." in the Makefile located in the buildir, and the tests are run into a subdir : /build/test_python_xxx, so you can't rely on a relative path.


For this to work we would need an absolute path for "srcdir" in the Makefile.

We need to find a way to locate the srcdir with an aboslute path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:42:30 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 11:42:30 +0000
Subject: [issue3646] MacOS X framework install to non-standard directory fails
In-Reply-To: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
Message-ID: <1272627750.39.0.351547931291.issue3646@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Als committed this for 3.2: r80648.

----------
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3646>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:45:32 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 11:45:32 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272627932.22.0.0922585787312.issue8577@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ah, found a way:

buildir = os.path.dirname(sys.executable)
srcdir = os.path.abspath(os.path.join(buildir, get_config_var('srcdir')))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:49:53 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 11:49:53 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272628193.74.0.164197686211.issue8577@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:50:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 11:50:40 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272628240.16.0.337537022746.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

It does work just fine, see the attached patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:51:28 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 11:51:28 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272628288.97.0.565282833019.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Actually attaching the patch might help.

With this patch test_distutils passes, without it it doesn't.

----------
keywords: +patch
Added file: http://bugs.python.org/file17147/issue8577.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:54:41 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 11:54:41 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272628481.87.0.339766948639.issue8577@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes it's pretty similar to what I've done in my earlier message.

No need to call os.path.dirname(get_makefile_filename()),
os.path.dirname(sys.executable) is enough.

I guess the patch part concerning unixcompiler is unrelated to this issue, right ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 13:57:07 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 11:57:07 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272628627.73.0.743187730714.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Yes, sorry about that. The patch in unixcompiler is for issue #7724.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 14:05:58 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 30 Apr 2010 12:05:58 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1272629158.17.0.0182107347575.issue7584@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> The point is that your implementation doesn't allow people to generate
> 'Z'-ending timestamp if they need a subset of rfc3339.

That is exactly right. Do you have any suggestion, how to do that? Maybe an optional argument to the rfcformat method? Something like:

def new_rfcformat(self, default_utcoffset='-00:00'):
    if we_know_the_utc_offset:
        return self.rfcformat() # the method in my current patch
    else:
        return self.isoformat() + default_utcoffset

This way, if somebody want 'Z' instead of '-00:00', just calls the method like this:

d.new_rfcformat('Z')

Though this way '+00:00' wouldn't get replaced by 'Z'. 
Any suggestions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Fri Apr 30 14:11:43 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 12:11:43 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272629503.14.0.610007492692.issue8577@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 14:25:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 30 Apr 2010 12:25:29 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272630329.57.0.195289059599.issue8540@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Fri Apr 30 14:33:26 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Apr 2010 12:33:26 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272630806.96.0.958438327984.issue8577@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed in r80649, r80650 

I'll merge in the py3k branch once I've reverted distutils there

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Fri Apr 30 15:20:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Apr 2010 13:20:33 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1272633633.63.0.0340083379776.issue1641@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with the points raised against Josiah's patch. I'm not sure O(n) cancellation is really a concern. The main focus of optimization should be the scheduler's loop itself, and both approaches have an O(log n) complexity there AFAICT. Also, the cancellation optimization could be backported into Giampaolo's patch.

One area tests should check for is when scheduling operations are done from a delayed call. Especially, a delayed call rescheduling itself.

By the way, it's too late for 2.7, so this is only for 3.2 now.

----------
stage:  -> patch review
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Fri Apr 30 15:58:21 2010
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 30 Apr 2010 13:58:21 +0000
Subject: [issue8578] PyWeakref_GetObject
In-Reply-To: <1272635901.2.0.350528689181.issue8578@psf.upfronthosting.co.za>
Message-ID: <1272635901.2.0.350528689181.issue8578@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

PyWeakref_GetObject(wref) returns a borrowed reference, but that's rather dangerous.  The fact that wref stays alive does not prevent the returned object from being collected (by definition -- wref is a weak reference).  That means that either we must explicitly and immediately do a Py_INCREF() (and later Py_DECREF()) on the result of the function, or we must use it for a very short time.

As an example of why this interface encourages buggy behavior, the sole user of PyWeakref_GetObject() in Module/* is Module/_sqlite/connection.c, which does

    statement = PyWeakref_GetObject(weakref);

and then call some functions passing 'statement' as argument.  The called functions can do anything (because they release the GIL).  So in particular they can cause 'statement' to be freed while still in use, either directly or indirectly via the cycle-GC.

This should be fixed; I suggest deprecating PyWeakref_GetObject() and adding another C API function that does not return a borrowed reference.

----------
components: Interpreter Core
messages: 104634
nosy: arigo
priority: normal
severity: normal
status: open
title: PyWeakref_GetObject
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8578>
_______________________________________

From report at bugs.python.org  Fri Apr 30 15:58:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Apr 2010 13:58:27 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <201004261400.08237.victor.stinner@haypocalc.com>
Message-ID: <4BDAE1FD.6020307@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Le lundi 26 avril 2010 13:06:48, vous avez ?crit :
>> I don't see what environment variables have to do with the file
>> system.
> 
> A POSIX system only offers *one* function about the encoding: 
> nl_langinfo(CODESET) and Python3 uses it for the filenames, environment 
> variables and the command line arguments.
> 
> Are you suggesting that Python3 should support a encoding different for 
> environment variables and the file system? How would the user configure it?

It's better to let the application decide how to solve this problem
and in order to allow for this, the encodings must be adjustable.

By using fsencode() and fsdecode() in stdlib functions, you basically
prevent this kind of adjustment, since they hardcode the use of
a single encoding which is guessed by looking at nl_langinfo(CODESET).

Note that application may well use completely different encodings
in the environment and for things like pipes than what the user
setup for her GUI environment.

In the end, this will only lead to the same kind of mess we've
had with sys.setdefaultencoding() in Python 2.x, only this
time with sys.setfilesystemencoding() and I'd like to avoid that.

> Since Python3 choosed to store environment variables as unicode string on 
> Windows and POSIX, in this specific case you should reconvert the value to 
> byte strings using fsencode() and then manipulate byte strings. Because 
> Python3 uses surrogateescape, you will get the original byte string values.

Well, yes, but that's a cludge isn't it ?

If you know that e.g. your environment variables are going to have
Latin-1 data (say some content-type variable has this information),
but the user's default LANG setting is UTF-8, Python will fetch the
data as broken Unicode data, you then have to convert it back to bytes
and then back to Unicode using the correct Latin-1 encoding.

It would be a lot better to have the application provide the
encoding to the os.getenv() function and have Python do the
correct decoding right from the start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri Apr 30 16:10:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Apr 2010 14:10:56 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1272636656.77.0.535001817977.issue1285086@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Tres, can you update your patch against SVN trunk?
Also, please do an unified diff, we are mostly used to this format.

----------
stage: unit test needed -> patch review
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Fri Apr 30 16:13:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Apr 2010 14:13:30 +0000
Subject: [issue8578] PyWeakref_GetObject
In-Reply-To: <1272635901.2.0.350528689181.issue8578@psf.upfronthosting.co.za>
Message-ID: <1272636810.33.0.715738578031.issue8578@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This should be fixed; I suggest deprecating PyWeakref_GetObject() and
> adding another C API function that does not return a borrowed reference.

Another possibility is to document the fact that Py_INCREF() should be called in most cases. It would be much lighter than a new API + deprecation process.

In the meantime, the sqlite issue should be fixed of course.

----------
components: +Library (Lib)
nosy: +ghaering, haypo, loewis, pitrou
priority: normal -> high
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8578>
_______________________________________

From report at bugs.python.org  Fri Apr 30 16:18:33 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 30 Apr 2010 14:18:33 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272637113.41.0.159215955822.issue8576@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

find_unused_port is the wrong approach altogether.  Uses of it should be replaced by bind_port and then find_unused_port should be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8576>
_______________________________________

From report at bugs.python.org  Fri Apr 30 16:48:21 2010
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 30 Apr 2010 14:48:21 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1272638901.31.0.303785245369.issue1285086@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

Updated patch against the trunk attached.

Note that I prefer unidiff myself, but was following a bit of guidance that Guido (used to, anyway) prefer context diffs.

The updated speed test run against the stdlib with this patch shows only a 12% to 16% hit against my simpler version (which didn't handle cases where the 'safe' argument was not the default "/").

----------
Added file: http://bugs.python.org/file17148/issue1285086-updated.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Fri Apr 30 16:49:46 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 30 Apr 2010 14:49:46 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1272638986.21.0.129713662644.issue1641@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I like the idea of leveraging the sched module.  It encapsulates the priority queue, allowing the user to be agnostic to the underlying data structure.  If someday we have a data structure in the collections module that provides an efficient delete-key operation, we can switch.  Giampaolo's patch forever ties us to heapq.

That said, I believe Josiah's patch could be simplified considerably.  Here are two ideas, which can be evaluated separately:

- The performance improvements to sched should be part of a separate patch and listed under a separate issue in the tracker.

- Let the user leverage the existing scheduler API.  Cut out scheduled_task and call_later, which just wraps the scheduler API.  The user can simply call scheduled_tasks.enter() or scheduled_tasks.cancel().  It's one less API for them to learn and one less for us to maintain.

Also, fix one small bug:

- Add a function to create a sched.scheduler().  Several functions take an optional "tasks" parameter, but there's no way to allocate a scheduler without peeking at the implementation and duplicating how it allocates the global one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:00:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 30 Apr 2010 15:00:09 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1272639609.49.0.268627512085.issue5553@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a patch.  

The diff to configure is just what autoconf produces as a result of the diff to configure.in.

With the patch, pyconfig.h will:
- do nothing if the compiler supports the "inline" keyword
- #define inline to __inline or __inline__ if that's the compiler supports
- #define inline to nothing if the compiler doesn't support inlining

The patch also updates pyport.h and _sre.c appropriately.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17149/inline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5553>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:01:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 15:01:47 +0000
Subject: [issue8476] build-installer fix for setIcon when no script path
	specified
In-Reply-To: <1271804262.14.0.282161229164.issue8476@psf.upfronthosting.co.za>
Message-ID: <1272639707.07.0.330920775934.issue8476@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in r80653 (trunk), r80654 (2.6), r80655 (3.2) and r80656 (3.1)

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8476>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:03:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 15:03:40 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <1272639820.81.0.598358522976.issue1677@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Unassigning this issue from myself as I cannot reproduce the issue on OSX.

----------
assignee: ronaldoussoren -> 
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1677>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:06:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 30 Apr 2010 15:06:36 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1272639996.8.0.418401318857.issue5553@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I should add that the patch is against the py3k branch, since it's too late for performance improvements to land in trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5553>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:14:02 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 15:14:02 +0000
Subject: [issue7107] Missing uninstallation instructions for mac
In-Reply-To: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>
Message-ID: <1272640442.61.0.342753619978.issue7107@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've added some notes to Mac/README.

r80657 (trunk)
r80658 (2.6)
r80659 (3.2)
r80660 (3.1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7107>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:14:17 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 15:14:17 +0000
Subject: [issue7107] Missing uninstallation instructions for mac
In-Reply-To: <1255291198.67.0.155699939308.issue7107@psf.upfronthosting.co.za>
Message-ID: <1272640457.16.0.647505205737.issue7107@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7107>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:30:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Apr 2010 15:30:46 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272641446.86.0.281480786895.issue8557@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it seems I was mistaken when I thought I knew how this worked :)
Checking the os.exec documentation linked from the subprocess page, I see that when an environment is supplied PATH is indeed checked in it.  The documentation for CreateProcess, however, indicates that PATH is ignored, and any extension must be supplied explicitly.

At the very least the docs should be updated to clarify that execvpe is used when an environment is passed on posix, and to link to the CreateProcess docs.  A discussion of PATH could perhaps be put in a note or footnote (probably footnote, there are enough notes already in those docs!)

I'm not sure how one creates a good portability story out of these pieces.  It doesn't seem as though there is any way to harmonize the two, since we are dealing with the semantics of system calls over which we have no control.

For reference, here is (a?) link to CreateProcess docs that I found via Google:

http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx

It doesn't look like the kind of link that one could trust to be stable, though, so I'm not sure if we should include it in the docs.

I'm adding Brian Curtin as nosy to see if he knows whether or not there are permalink-like links to the relevant Microsoft documentation that we could use.

----------
nosy: +brian.curtin
stage:  -> needs patch
title: subprocess PATH semantics -> subprocess PATH semantics and portability
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Fri Apr 30 17:49:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 15:49:10 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272642550.0.0.575398445181.issue8557@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You could take the "(VS8.5)" part out of the link which will give the latest version, which may not always be the relevant version (although I doubt this specific API would change).

That's about the best permalink-like feature you'll find, but overall, leaving the link as-is is pretty safe in my experience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Fri Apr 30 18:05:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 16:05:29 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <4BDAE1FD.6020307@egenix.com>
Message-ID: <201004301805.18230.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 30 avril 2010 15:58:28, vous avez ?crit :
> It's better to let the application decide how to solve this problem
> and in order to allow for this, the encodings must be adjustable.

On POSIX, use byte strings to avoid encoding issues. Examples:

   subprocess.call(['env'], {b'TEST: b'a\xff-'}) # env
   subprocess.call(['echo', b'a\xff-']) # command line
   open('a\xff-') # filename
   os.getenv(b'a\xff-') # get env (result as unicode)

Are you talking about issues on Windows?

> By using fsencode() and fsdecode() in stdlib functions, you basically
> prevent this kind of adjustment, ...

Not if you use byte strings. On POSIX, an unicode string is always converted 
at the end for the system call (using sys.getfilesystemencoding()).

> If you know that e.g. your environment variables are going to have
> Latin-1 data (say some content-type variable has this information),
> but the user's default LANG setting is UTF-8, Python will fetch the
> data as broken Unicode data, you then have to convert it back to bytes
> and then back to Unicode using the correct Latin-1 encoding.
> 
> It would be a lot better to have the application provide the
> encoding to the os.getenv() function and have Python do the
> correct decoding right from the start.

You mean that os.getenv() should have an optionnal argument? Something like:

  def getenv(key, default=None, encoding=None):
     value = environ.get(key, default)
     if encoding:
        value = value.encode(sys.getfileystemencoding(), 'surrogateescape')
        value = value.decode(encoding, 'surrogateescape')
     return value

There are many indirect calls to os.getenv() (eg. by using os.environ.get()):
 - curses uses TERM
 - webbrowser uses PROGRAMFILES (path)
 - distutils.msvc9compiler uses "VS%0.f0COMNTOOLS" % version (path)
 - wsgiref.util uses HTTP_HOST, SERVER_NAME,  SCRIPT_NAME, ... (url)
 - platform uses PROCESSOR_ARCHITEW6432
 - sysconfig uses PYTHONUSERBASE, APPDATA, ... (path)
 - idlelib.PyShell uses IDLESTARTUP and PYTHONSTARTUP (path)
 - ...

How would you specify the correct encoding in indirect calls?

If your application gets variables in *mixed* encoding, I think that your 
program should start by reencoding variables:

  for name, encoding in (('PATH', 'latin1'), ...):
     value = os.getenv(name)
     value = value.encode(sys.getfileystemencoding(), 'surrogateescape')
     value = value.decode(encoding, 'surrogateescape')
     os.setenv(name, value)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri Apr 30 18:06:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 16:06:35 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272643595.93.0.498081241141.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: subprocess: support bytes program name -> subprocess: support bytes program name (POSIX)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Fri Apr 30 18:08:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 16:08:56 +0000
Subject: [issue8432] buildbot: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1272643736.97.0.688007236403.issue8432@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: build: test_send_signal of test_subprocess failure -> buildbot: test_send_signal of test_subprocess failure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8432>
_______________________________________

From report at bugs.python.org  Fri Apr 30 18:14:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 16:14:34 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1272644074.33.0.421101193127.issue8211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Sorry but i don't really understand the problem of my patch, and I don't want to spend time of this. Revert my patch if you think that it introduced a regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Fri Apr 30 18:15:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 16:15:26 +0000
Subject: [issue8565] Always run regrtest.py with -bb
In-Reply-To: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>
Message-ID: <1272644126.4.0.759096462683.issue8565@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8565>
_______________________________________

From report at bugs.python.org  Fri Apr 30 18:25:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Apr 2010 16:25:40 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <201004301805.18230.victor.stinner@haypocalc.com>
Message-ID: <4BDB047F.209@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Le vendredi 30 avril 2010 15:58:28, vous avez ?crit :
>> It's better to let the application decide how to solve this problem
>> and in order to allow for this, the encodings must be adjustable.
> 
> On POSIX, use byte strings to avoid encoding issues. Examples:
> 
>    subprocess.call(['env'], {b'TEST: b'a\xff-'}) # env
>    subprocess.call(['echo', b'a\xff-']) # command line
>    open('a\xff-') # filename
>    os.getenv(b'a\xff-') # get env (result as unicode)
> 
> Are you talking about issues on Windows?

The issues normally occur on the way in, not the way out of Python,
so I don't see how using bytes would help.

>> By using fsencode() and fsdecode() in stdlib functions, you basically
>> prevent this kind of adjustment, ...
> 
> Not if you use byte strings. On POSIX, an unicode string is always converted 
> at the end for the system call (using sys.getfilesystemencoding()).

Right and that's a problem since the file system encoding
doesn't need to have anything to do with what you have in
the environment.

>> If you know that e.g. your environment variables are going to have
>> Latin-1 data (say some content-type variable has this information),
>> but the user's default LANG setting is UTF-8, Python will fetch the
>> data as broken Unicode data, you then have to convert it back to bytes
>> and then back to Unicode using the correct Latin-1 encoding.
>>
>> It would be a lot better to have the application provide the
>> encoding to the os.getenv() function and have Python do the
>> correct decoding right from the start.
> 
> You mean that os.getenv() should have an optionnal argument? Something like:

Yes.

>   def getenv(key, default=None, encoding=None):
>      value = environ.get(key, default)
>      if encoding:
>         value = value.encode(sys.getfileystemencoding(), 'surrogateescape')
>         value = value.decode(encoding, 'surrogateescape')
>      return value

No, you store the environment data as bytes and only
decode in getenv() based on the given encoding or using
the file system encoding or default encoding (UTF-8)
as default.

It would probably also worthwhile adding the encoding
parameter to os.environ.get().

> There are many indirect calls to os.getenv() (eg. by using os.environ.get()):
>  - curses uses TERM
>  - webbrowser uses PROGRAMFILES (path)
>  - distutils.msvc9compiler uses "VS%0.f0COMNTOOLS" % version (path)
>  - wsgiref.util uses HTTP_HOST, SERVER_NAME,  SCRIPT_NAME, ... (url)
>  - platform uses PROCESSOR_ARCHITEW6432
>  - sysconfig uses PYTHONUSERBASE, APPDATA, ... (path)
>  - idlelib.PyShell uses IDLESTARTUP and PYTHONSTARTUP (path)
>  - ...
> 
> How would you specify the correct encoding in indirect calls?

In all of the above cases, the application (in this case the
various modules) knows which encoding to expect and can
add the right encoding parameter to the os.getenv() call.

E.g. the cgi module can use the content-type passed in as
environment parameter to determine the encoding, most other
modules will just use ASCII or the file system encoding
if they are dealing with paths or file names.

> If your application gets variables in *mixed* encoding, I think that your 
> program should start by reencoding variables:
> 
>   for name, encoding in (('PATH', 'latin1'), ...):
>      value = os.getenv(name)
>      value = value.encode(sys.getfileystemencoding(), 'surrogateescape')
>      value = value.decode(encoding, 'surrogateescape')
>      os.setenv(name, value)

Which is a cludge as I mentioned in my previous comment:

    value = os.getenv(name, encoding=encoding)
    my_environ[name] = value

reads much better.

Also note that os.setenv() won't work since that'll use the
file system encoding for encoding the value back into the C
process environment array. You'd end up with mojibake in
your C environment array.

The point I want to make is that adding fsencode() and
fsdecode() will help refactor the code a bit, but it
shouldn't be used as excuse for not making the encoding
explicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri Apr 30 18:30:31 2010
From: report at bugs.python.org (Paul Moore)
Date: Fri, 30 Apr 2010 16:30:31 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272645031.52.0.704390831849.issue8576@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

OK. I've attached a patch which removes the use of get_unused_port for test_smtplib and test_multiprocessing. It doesn't use bind_port as both cases test classes that create their own port internally, rather I've used port 0 and then introspected the actual port assigned.

The same process could probably be used for the remaining uses of get_unused_port, but I haven't tackled them yet.

Tested on my local PC and on the buildbot where I see the bug. Both tests run fine in both cases. I'm running the full test suite now.

----------
keywords: +patch
Added file: http://bugs.python.org/file17150/unused1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8576>
_______________________________________

From report at bugs.python.org  Fri Apr 30 19:16:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 17:16:07 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272647767.62.0.263893496115.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> No, you store the environment data as bytes and only
> decode in getenv() ...

Yes, this is the best solution for POSIX. We need maybe also a os.getenvb()->bytes function, maybe only on POSIX.

But I think that Windows should continue to use unicode environment variables. Should os.getenv(key, encoding=...) reencode the value on Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri Apr 30 19:34:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Apr 2010 17:34:19 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1272644074.33.0.421101193127.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BDB1495.1060104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Sorry but i don't really understand the problem of my patch, and I don't want to spend time of this. Revert my patch if you think that it introduced a regression.

See the new implementation for what I meant...

r80665 - in python/trunk: configure configure.in
r80666 - in python/branches/py3k: configure	configure.in

[issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS

Only override the AC_PROG_CC determined CFLAGS if they were set by the user.
This restores the default behavior in the common case of not having CFLAGS
defined when running configure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Fri Apr 30 19:35:28 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Apr 2010 17:35:28 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1272648928.74.0.0140542503192.issue8211@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee:  -> lemburg
priority: release blocker -> normal
resolution:  -> fixed
status: open -> closed
title: configure: ignore AC_PROG_CC hardcoded CFLAGS -> configure: allow user-provided CFLAGS to override AC_PROG_CC defaults

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Fri Apr 30 19:48:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Apr 2010 17:48:26 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272647767.62.0.263893496115.issue8514@psf.upfronthosting.co.za>
Message-ID: <4BDB17E7.9080302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> No, you store the environment data as bytes and only
>> decode in getenv() ...
> 
> Yes, this is the best solution for POSIX. We need maybe also a os.getenvb()->bytes function, maybe only on POSIX.

Yes, plus a os.setenvb() function to pass the data back to the C level
array.

> But I think that Windows should continue to use unicode environment variables. Should os.getenv(key, encoding=...) reencode the value on Windows?

Good idea. That would make applications more easily portable between
Windows and POSIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri Apr 30 20:02:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 18:02:31 +0000
Subject: [issue8579] Add missing tests for FlushKey, LoadKey,
	and SaveKey in winreg
In-Reply-To: <1272650551.21.0.0191974450566.issue8579@psf.upfronthosting.co.za>
Message-ID: <1272650551.21.0.0191974450566.issue8579@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Per the comment at the top of Lib/test/test_winreg.py, FlushKey, LoadKey, and SaveKey are currently untested.

I have a minimal patch worked up. I'll expand on it and upload shortly.

----------
assignee: brian.curtin
components: Extension Modules, Windows
messages: 104655
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Add missing tests for FlushKey, LoadKey, and SaveKey in winreg
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/issue8579>
_______________________________________

From report at bugs.python.org  Fri Apr 30 20:52:42 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Fri, 30 Apr 2010 18:52:42 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1272653562.39.0.511349142389.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Fri Apr 30 21:10:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Apr 2010 19:10:26 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1272654626.5.0.812306081121.issue8525@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.5 is frozen. 2.6 and 3.1 are in bug-fix mode only, and 2.7 is in beta so new features are unlikely there. So I recommend doing a patch against 3.1 or even the 3.2 trunk. And of course, make sure this proposal makes sense for 3.x.

----------
nosy: +tjreedy
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Fri Apr 30 21:22:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Apr 2010 19:22:55 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1272655375.27.0.839916949855.issue8525@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your work, Rob. To get reviews and comments, you?ll need to submit a patch (a diff) instead of the whole file. This makes it easier to see your changes than looking for a special comment :)

This short doc should contain all the information you?ll need: http://www.python.org/dev/patches

As Terry said, 2.6 and 3.1 only get bug fixes, 2.7 and 3.2 are in beta stage and don?t get new features, so you?ll want to port your changes to the py3k branch (the trunk for the 3.x series).

Regards

----------
components: +Library (Lib)
nosy: +merwok
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Fri Apr 30 21:24:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 19:24:10 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1272655450.33.0.00596817810093.issue8525@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Minor correction to the last comment: 3.2 is not in beta nor feature freeze.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Fri Apr 30 21:32:16 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 30 Apr 2010 19:32:16 +0000
Subject: [issue8547] unittest test discovery can fail when package under test
	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1272655936.97.0.180747640314.issue8547@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

FWIW checking if an imported module really comes from a certain location and erroring out is also how py.test does it.

----------
nosy: +hpk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8547>
_______________________________________

From report at bugs.python.org  Fri Apr 30 21:33:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 30 Apr 2010 19:33:55 +0000
Subject: [issue8547] unittest test discovery can fail when package under test
	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1272656035.1.0.591236869832.issue8547@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sounds like the right approach then. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8547>
_______________________________________

From report at bugs.python.org  Fri Apr 30 21:42:54 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 30 Apr 2010 19:42:54 +0000
Subject: [issue8564] Update documentation on doctest/unittest2 integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272656574.83.0.682738948674.issue8564@psf.upfronthosting.co.za>


Changes by holger krekel <holger.krekel at gmail.com>:


----------
nosy: +hpk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8564>
_______________________________________

From report at bugs.python.org  Fri Apr 30 22:13:56 2010
From: report at bugs.python.org (Jorge Bosch)
Date: Fri, 30 Apr 2010 20:13:56 +0000
Subject: [issue8580] Problem urllib2.URLError
In-Reply-To: <1272658436.51.0.144833703939.issue8580@psf.upfronthosting.co.za>
Message-ID: <1272658436.51.0.144833703939.issue8580@psf.upfronthosting.co.za>


New submission from Jorge Bosch <jorgebosch86 at gmail.com>:

hello. Im new on this kind of programation. Well it could sound newbie...but I have this error and I dont know how to fix it.

Well its related with an AutoUpdater for a Online Game (GTLegends, Altbierbude software) but no one manage to solve it..

Here is the Log of the error:

Traceback (most recent call last):
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 134, in <module>
    main()
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 93, in main
    the_app.myconfig = GetAppConfig(source_url, config_filename)
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 52, in GetAppConfig
    cfg_data = GetUrlData(url+filename)
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 31, in GetUrlData
    url_handle = opener.open( url )
  File "C:\Python26\lib\urllib2.py", line 389, in open
    response = self._open(req, data)
  File "C:\Python26\lib\urllib2.py", line 407, in _open
    '_open', req)
  File "C:\Python26\lib\urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "C:\Python26\lib\urllib2.py", line 1146, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "C:\Python26\lib\urllib2.py", line 1121, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno 10061] No se puede establecer una conexi?n ya que el equipo de destino deneg? expresamente dicha conexi?n>

----------
messages: 104661
nosy: m_enanos
priority: normal
severity: normal
status: open
title: Problem urllib2.URLError
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8580>
_______________________________________

From report at bugs.python.org  Fri Apr 30 22:34:33 2010
From: report at bugs.python.org (Jason Baker)
Date: Fri, 30 Apr 2010 20:34:33 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

The logging handler does not handle double-closing very well:

>>> from logging import StreamHandler
>>> h = StreamHandler()
>>> h.close()
>>> h.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/logging/__init__.py", line 705, in close
    del _handlers[self]
KeyError: <logging.StreamHandler instance at 0xb7609c8c>

There are two possible approaches to this:

 1. Raise a better error.
 2. Ignore the duplicate close.

This patch takes option 2 as this is likely not indicative of any kind of programmer error, but it shouldn't be too difficult to take option 1 instead.

----------
components: Library (Lib)
messages: 104662
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: Logging handlers do not handle double-closing very well
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8581>
_______________________________________

From report at bugs.python.org  Fri Apr 30 22:36:21 2010
From: report at bugs.python.org (Jason Baker)
Date: Fri, 30 Apr 2010 20:36:21 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272659781.97.0.842638460207.issue8581@psf.upfronthosting.co.za>


Jason Baker <amnorvend at gmail.com> added the comment:

Adding patch

----------
keywords: +patch
Added file: http://bugs.python.org/file17151/logging.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8581>
_______________________________________

From report at bugs.python.org  Fri Apr 30 22:58:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Apr 2010 20:58:33 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272661113.77.0.572947547106.issue8581@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8581>
_______________________________________

From report at bugs.python.org  Fri Apr 30 23:06:37 2010
From: report at bugs.python.org (Jason Gross)
Date: Fri, 30 Apr 2010 21:06:37 +0000
Subject: [issue8582] urllib.urlretrieve fails with ValueError: Invalid format
	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>


New submission from Jason Gross <jasongross9 at gmail.com>:

When calling urllib.urlretrieve with a data:image/png url (possibly with other urls too) and a local file name, it fails with
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    urlretrieve(url, file_name)
  File "D:\Python26\Lib\urllib.py", line 93, in urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File "D:\Python26\Lib\urllib.py", line 237, in retrieve
    fp = self.open(url, data)
  File "D:\Python26\Lib\urllib.py", line 205, in open
    return getattr(self, name)(url)
  File "D:\Python26\Lib\urllib.py", line 596, in open_data
    time.gmtime(time.time())))

This can be fixed by replacing %T on line 595 with %H : %M : %S (which I found as the definition of %T on http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html)

----------
components: Library (Lib)
messages: 104664
nosy: Jason.Gross
priority: normal
severity: normal
status: open
title: urllib.urlretrieve fails with ValueError: Invalid format string
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8582>
_______________________________________

From report at bugs.python.org  Fri Apr 30 23:08:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Apr 2010 21:08:14 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272661694.2.0.911114215725.issue8566@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Your patch will break test_parser on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8566>
_______________________________________

From report at bugs.python.org  Fri Apr 30 23:08:52 2010
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Fri, 30 Apr 2010 21:08:52 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272661732.63.0.589094580334.issue1054967@psf.upfronthosting.co.za>


Changes by Piotr O?arowski <piotr at debian.org>:


----------
nosy: +piotr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Fri Apr 30 23:19:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Apr 2010 21:19:27 +0000
Subject: [issue8580] Problem urllib2.URLError
In-Reply-To: <1272658436.51.0.144833703939.issue8580@psf.upfronthosting.co.za>
Message-ID: <1272662367.57.0.183301771125.issue8580@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The bug tracker is for bugs in Python itself, and isn't a good place to look for help on getting an application program to work.  You should try the python email list/newsgroup.  (You can find links to the newsgroup and other resources under the 'help' link on the left hand side menu on the python home page).

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8580>
_______________________________________

From report at bugs.python.org  Fri Apr 30 23:23:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Apr 2010 21:23:59 +0000
Subject: [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1272662639.82.0.611843511918.issue8556@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the suggestion. Two things:
1. Please provide a unified diff, as explained in http://www.python.org/dev/
2. I think ?number? would be a better placeholder.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8556>
_______________________________________

From report at bugs.python.org  Fri Apr 30 23:57:36 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 30 Apr 2010 21:57:36 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272664656.99.0.720853550107.issue8581@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santa.ant at me.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8581>
_______________________________________

From report at bugs.python.org  Fri Apr 30 23:59:12 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 30 Apr 2010 21:59:12 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272664752.48.0.966034556849.issue8566@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

In what way will my patch break test_parser on Windows? I preserved the behavior of re-opening the file in text mode after determining the encoding. Do I need to add 'U' to open()'s mode string?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8566>
_______________________________________