From report at bugs.python.org  Thu Dec  1 00:06:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Nov 2011 23:06:58 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1322694418.14.0.884527191988.issue13455@psf.upfronthosting.co.za>


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

Something else such docs could cover is how to manage remote Hg repos such that the "Create Patch" button does the right thing.

Basically, you need to make sure an appropriate CPython version is found in the ancestors of the tip your working branch. This is most easily achieved either by working directly on the default branch in your remote repo, or else by merging directly from default to your feature branch (i.e. not via another feature branch).

If you don't follow this rule, the generated patch will occasionally incorrectly revert changes in CPython that you didn't intend to affect.

(see http://psf.upfronthosting.co.za/roundup/meta/issue428 for some background)

----------

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

From report at bugs.python.org  Thu Dec  1 00:18:36 2011
From: report at bugs.python.org (Nebelhom)
Date: Wed, 30 Nov 2011 23:18:36 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1322695116.72.0.295239556637.issue13491@psf.upfronthosting.co.za>


Changes by Nebelhom <nebelhom at googlemail.com>:


Added file: http://bugs.python.org/file23823/sqlite_code_update.patch

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

From report at bugs.python.org  Thu Dec  1 00:22:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Nov 2011 23:22:05 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <E1RVtTY-0006T5-If@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6cde416ef03b by Nadeem Vawda in branch 'default':
Credit Per ?yvind Karlsen for the initial implementation of the lzma module (issue #6715).
http://hg.python.org/cpython/rev/6cde416ef03b

----------

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

From report at bugs.python.org  Thu Dec  1 00:22:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 30 Nov 2011 23:22:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322695340.04.0.900517517289.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> As the docs for zlib, gzip, bz2, lzma, zipfile and tarfile are in the
> archiving subsection, there?s already a link to the subsection index,
> so I just removed the ?See also zlib, etc.? lines (except for the link
> from zlib to gzip).  I added a link from archiving.rst to shutil and
> more links and reST targets in shutil.

Looks good to me.

> The entry in Misc/ACKS, Doc/whatsnew/3.3.rst and the commit message
> should be enough.  Lately I?ve noticed some attributions in NEWS, but
> it?s usually not done (as redundant).

According to Doc/whatsnew/3.3.rst:

   "The maintainer will go through Misc/NEWS periodically and add
    changes; it's therefore more important to add your changes to
    Misc/NEWS than to this file."

> what about a mention in lzmamodule.c?

Done and committed.

----------

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

From report at bugs.python.org  Thu Dec  1 00:23:23 2011
From: report at bugs.python.org (Vincent Danen)
Date: Wed, 30 Nov 2011 23:23:23 +0000
Subject: [issue13512] ~/.pypirc created insecurely
Message-ID: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>


New submission from Vincent Danen <vdanen at linsec.ca>:

A bug was reported in python's distutils in that ~/.pypirc was created insecurely by first creating and writing user/password information to the file, then chmod'ing it to 0600.

Perhaps the file should be created (empty), chmod'd, and then written to or perhaps tempfile.mkstemp() could be used to create the file and then move it in-place.

On systems where /home/user is 0700 by default this isn't a problem, but there is a race condition that could possibly (although the window would be small) to expose credentials in a home directory that is 0755, for instance.

I searched and couldn't find a similar report here, so decided to make upstream aware of the bug reported to Debian.

References:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650555
https://bugzilla.redhat.com/show_bug.cgi?id=758905

----------
assignee: tarek
components: Distutils
messages: 148697
nosy: Vincent.Danen, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: ~/.pypirc created insecurely
type: security
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  1 01:38:48 2011
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 01 Dec 2011 00:38:48 +0000
Subject: [issue10364] IDLE: make .py default added extension on save
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1322699928.42.0.229530307912.issue10364@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Thu Dec  1 01:43:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2011 00:43:31 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1322700211.81.0.4501034069.issue11870@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Gregory's patches to sanitize threading's lock should have fixed this

The subprocess hang still occurs something, it just happened:

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/4898/steps/test/logs/stdio

[110/363] test_threading
Timeout (1:00:00)!
Thread 0x404888c0:
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1513 in _communicate_with_poll
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1438 in _communicate
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 850 in communicate
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py", line 32 in _assert_python
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py", line 50 in assert_python_ok
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 441 in _run_and_join
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 497 in test_3_join_in_forked_from_thread
...

----------

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

From report at bugs.python.org  Thu Dec  1 02:07:01 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Thu, 01 Dec 2011 01:07:01 +0000
Subject: [issue13512] ~/.pypirc created insecurely
In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>
Message-ID: <1322701621.99.0.985716721195.issue13512@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Something along these lines (untested) should do it. 2.6 and 3.x need the fix as well

----------
keywords: +patch
nosy: +pjenvey
Added file: http://bugs.python.org/file23824/pypirc-secure.diff

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

From report at bugs.python.org  Thu Dec  1 02:09:47 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Thu, 01 Dec 2011 01:09:47 +0000
Subject: [issue13512] ~/.pypirc created insecurely
In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>
Message-ID: <1322701787.09.0.101778028884.issue13512@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

It probably still needs to catch OSErrors which my patch doesn't do

----------

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

From report at bugs.python.org  Thu Dec  1 05:24:09 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 04:24:09 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1322655604.23.0.598398075147.issue13097@psf.upfronthosting.co.za>
Message-ID: <CAK1QoordVB_7SRiK0kFZ8QSCLsqruF7F+FaKEGmhQN+UTERPUw@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Wed, Nov 30, 2011 at 6:20 AM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:

> Right, alloca() could be replaced by some malloc(), but is it really useful? ?After all, when a C function calls back to Python, all arguments needs to be > pushed to the stack anyway.

The case is somewhat pathological.  However, there are *four* 'alloca'
calls in '_ctypes_callproc', three of which are proportional to
'argcount'.  And as you point out there is an additional stack
allocation inside of 'libffi' when the callback is actually called
(also using 'alloca').

I see two reasons switching to 'malloc' might be beneficial: (1) by
shifting some of the allocation to dynamic allocation we may reduce
the chance that we blow the stack at all.  Keep in mind that this gets
more likely if the C ffi function is called from a deep in a call tree
and *not* necessarily with just a huge number of parameters.  (2) if
resources are exhausted, then we can exit more gracefully.  Out of
dynamic memory errors can actually be handled as opposed to an
'alloca' call that ends up allocating more than is left.

That being said, if this does get changed it is low priority.

----------

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

From report at bugs.python.org  Thu Dec  1 05:24:55 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 04:24:55 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za>
Message-ID: <1322713495.23.0.406217801203.issue13097@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
priority: normal -> low

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

From report at bugs.python.org  Thu Dec  1 05:59:05 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 04:59:05 +0000
Subject: [issue13513] IOBase docs incorrectly link to the GNU readline module
Message-ID: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

The current IOBase documentation [1] reads:

"""
IOBase (and its subclasses) support the iterator protocol, meaning that an IOBase object can be iterated over yielding the lines in a stream. Lines are defined slightly differently depending on whether the stream is a binary stream (yielding bytes), or a text stream (yielding character strings). See readline() below.
"""

Currently the 'readline' link in the last sentence is linking to the GNU readline interface, which is wrong.  Patch attached.

[1] http://docs.python.org/dev/library/io.html?highlight=readlines#io.IOBase

----------
assignee: docs at python
components: Documentation
files: IOBase.readline-doc.patch
keywords: patch
messages: 148702
nosy: docs at python, meador.inge
priority: normal
severity: normal
stage: patch review
status: open
title: IOBase docs incorrectly link to the GNU readline module
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23825/IOBase.readline-doc.patch

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

From report at bugs.python.org  Thu Dec  1 06:12:29 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 05:12:29 +0000
Subject: [issue13510] Clarify that readlines() is not needed to iterate over a
	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1322716349.26.0.421059956417.issue13510@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I am skeptical that such a note will help.  The iterator behavior is clearly pointed out in the Python Tutorial [1] and in the IOBase documentation [2].  I suspect this bad code pattern is just being copied and pasted from other sources without folks ever even looking at the Python documentation.

[1] http://docs.python.org/dev/tutorial/inputoutput.html?highlight=readlines#methods-of-file-objects
[2] http://docs.python.org/dev/library/io.html#io.IOBase

----------
nosy: +meador.inge

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

From report at bugs.python.org  Thu Dec  1 06:23:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 05:23:25 +0000
Subject: [issue13510] Clarify that readlines() is not needed to iterate over a
	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1322717005.66.0.908101980062.issue13510@psf.upfronthosting.co.za>


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

FWIW I've seen several persons using "for line in file.readlines(): ..." or even "while 1: line = file.readline()".  IMHO it's a good idea to document that "without sizehint, it's equivalent to list(file)" and that "for line in file: ..." can be used directly.  Even if some people don't read the doc, the ones who do will benefit from this.  The same note might also be added to the docstring (I think it's somewhat common to learn about readlines() through dir(file) + help(file.readlines)).

----------

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

From report at bugs.python.org  Thu Dec  1 06:26:01 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 05:26:01 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1322717161.26.0.787133185294.issue13120@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Ilya, I agree.  Thanks for the test patch.  These two patches look OK to me.  Georg OK with you?

----------

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

From report at bugs.python.org  Thu Dec  1 07:33:08 2011
From: report at bugs.python.org (Paul Sladen)
Date: Thu, 01 Dec 2011 06:33:08 +0000
Subject: [issue13514] PIL does not support iTXt PNG chunks [patch]
Message-ID: <1322721188.29.0.647458278211.issue13514@psf.upfronthosting.co.za>


New submission from Paul Sladen <python at paul.sladen.org>:

The Python Imaging Library does not support handling of UTF-8 'iTXt' key:value chunks in PNG files:

  http://www.w3.org/TR/PNG/#11iTXt

Such support is necessary for successful extraction of key:value pairs of UTF-8 encoded data, stored in an PNG 'iTXt' comment chunk.

The following example file (from British GCHQ) demonstrates such a record in a PNG file.  Based on this evidence, it is highly likely that GCHQ hide all of their important secrets using this kind of steganography, and likely necessary that spies from the rest of the world are requiring similar access to GCHQ secrets.  Inclusion of a working chunk_iTXt() PIL/PNG support function will enable more harmonious and effective eavesdropping.  Example image:

  http://www.canyoucrackit.co.uk/images/cyber.png

(The attached .py file is not a directly apply-able patch, but contains a working implementation for chunk_iTXt() and a demonstrative test function for inserting it).

----------
components: Installation
files: chunk_iTXt.py
messages: 148706
nosy: sladen
priority: normal
severity: normal
status: open
title: PIL does not support iTXt PNG chunks [patch]
type: feature request
Added file: http://bugs.python.org/file23826/chunk_iTXt.py

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

From report at bugs.python.org  Thu Dec  1 07:41:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 06:41:14 +0000
Subject: [issue13514] PIL does not support iTXt PNG chunks [patch]
In-Reply-To: <1322721188.29.0.647458278211.issue13514@psf.upfronthosting.co.za>
Message-ID: <1322721674.92.0.881949521397.issue13514@psf.upfronthosting.co.za>


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

You should report this to the PIL bug tracker.  PIL is not part of the Python standard library.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec  1 07:44:58 2011
From: report at bugs.python.org (Paul Sladen)
Date: Thu, 01 Dec 2011 06:44:58 +0000
Subject: [issue13514] PIL does not support iTXt PNG chunks [patch]
In-Reply-To: <1322721188.29.0.647458278211.issue13514@psf.upfronthosting.co.za>
Message-ID: <1322721898.19.0.277766127691.issue13514@psf.upfronthosting.co.za>


Paul Sladen <python at paul.sladen.org> added the comment:

Thank you Ezio.  I could not see a separate bug tracker listed on:

  http://www.pythonware.com/products/pil/

could you help me by providing a link to where it /should/ be filed correctly for PIL itself.

----------

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

From report at bugs.python.org  Thu Dec  1 07:52:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 06:52:49 +0000
Subject: [issue13514] PIL does not support iTXt PNG chunks [patch]
In-Reply-To: <1322721188.29.0.647458278211.issue13514@psf.upfronthosting.co.za>
Message-ID: <1322722369.66.0.938761811689.issue13514@psf.upfronthosting.co.za>


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

You could try submitting your patch to the image-sig ML (http://mail.python.org/mailman/listinfo/image-sig).

----------

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

From report at bugs.python.org  Thu Dec  1 08:53:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2011 07:53:37 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
Message-ID: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>


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

This issue proposes that we adopt and apply some standard practices when documenting modules that have potential security implications and other cross-cutting errors that may affect multiple interfaces within the module.

Accordingly, the main target is the "Documenting Python" meta-docs, proposing the addition of a new subsection to the Style Guide, with an update to the subprocess module documentation serving as the exemplar of a new recommended style:

======================
2.6 Security Considerations (and Other Concerns)
------------------------------------------------

Some modules provided with Python are inherently exposed to security issues (e.g. shell injection vulnerabilities) due to the purpose of the module (e.g. subprocess invocation). Littering the documentation of these modules with red warning boxes for problems that are due to the task at hand, rather than specifically to Python's support for that task, doesn't make for a good reading experience.

Instead, these security concerns should be gathered into a dedicated "Security Considerations" section within the module's documentation, and cross-referenced from the documentation of affected interfaces with in-line text similar to "Please refer to the :ref:`security-considerations` section for important information on how to avoid common mistakes".

Similarly, if there is a common error that affects many interfaces in a module (e.g. OS level pipe buffers filling up and stalling child processes), these can be documented in a "Common Errors" section and cross-referenced rather than repeated for every affected interface.
======================


(based on the thread at http://mail.python.org/pipermail/python-dev/2011-December/114717.html)

----------
assignee: docs at python
components: Documentation
messages: 148710
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Consistent documentation practices for security concerns and considerations

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

From report at bugs.python.org  Thu Dec  1 09:08:51 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 01 Dec 2011 08:08:51 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322726931.3.0.460141637471.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23827/2a7dedf6a65e.diff

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

From report at bugs.python.org  Thu Dec  1 09:09:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 01 Dec 2011 08:09:05 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322726945.41.0.566241538352.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23814/3968bb3e698f.diff

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

From report at bugs.python.org  Thu Dec  1 09:10:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 08:10:22 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322727022.11.0.935606226368.issue13515@psf.upfronthosting.co.za>


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

Grouping the common warnings in a "Security Considerations" section sounds OK, but the warnings should still be visible IMHO.

In my experience, people:
 1) jump right to the doc for the function they are using;
 2) read the example and try to figure out how it works;
 3) if that fails, they read the text.

An inline text with a simple link might then pass unnoticed.  OTOH littering the doc with red boxes is far too noticeable.  Maybe we should use something in between (e.g. a "lighter" CSS for the warnings or a small warning icon).

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Thu Dec  1 09:11:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2011 08:11:10 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za>
Message-ID: <1322727070.74.0.529182027643.issue13097@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Is there really an use case where you need 2 ** 20 (1,048,576) arguments? If yes, I'm not against the torture in this case :-) If no, why not raising an error if there are too many arguments? E.g. limit to 1,024 arguments or maybe just 10?

----------

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

From report at bugs.python.org  Thu Dec  1 09:20:22 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 01 Dec 2011 08:20:22 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322727622.82.0.863839152006.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The stack walker helper now supports unicode too. This was quite difficult!.

The patch is functionally complete.

Current patch is pretty final. It was easy and painless EXCEPT the stackhelper, because the "idea" of "PyCompactUnicodeObject" that GCC and DTRACE have are different. Current code includes a couple of "magic numbers". This can be fragile. But if it breaks, the only missing functionality would be the augmented stack dump. No crashed, because DTRACE probes are safe (for the program being monitored).

I guess the best idea would be to generate a ".h" at compile time, with the right magic constants.

I have tried to create global variables and import them from the stackhelper. That works... unless you use the "-c" DTrace argument. I guess I am hitting some bug in DTrace.

Pending: performance analysis. The performance hit should be very small.

Please, do a preliminar review.

----------

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

From report at bugs.python.org  Thu Dec  1 09:37:24 2011
From: report at bugs.python.org (python_hu)
Date: Thu, 01 Dec 2011 08:37:24 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322728644.1.0.599350878862.issue13493@psf.upfronthosting.co.za>


python_hu <nari_hu at 163.com> added the comment:

-> void* handle = dlopen("/usr/local/lib/python2.7/lib-dynload/time.so", 2);
this code can work well,but when the code run to :
PyRun_SimpleString("from time import time,ctime\nprint 'Today is',ctime(time())\n");

it dumped, i think it make be because of there are two python handle running,one is main thread ,anthother is the  time.so.

----------

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

From report at bugs.python.org  Thu Dec  1 11:16:24 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Thu, 01 Dec 2011 10:16:24 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1322734584.24.0.650141013145.issue12612@psf.upfronthosting.co.za>


Zhiping Deng <kofreestyler at gmail.com> added the comment:

It works for me!

----------
nosy: +Zhiping.Deng

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

From report at bugs.python.org  Thu Dec  1 11:38:22 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 01 Dec 2011 10:38:22 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1322735902.81.0.11599662823.issue5689@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I will be happy to, but my spare time is limited right now, so this could take about a week. If this is a problem, please go ahead.

----------

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

From report at bugs.python.org  Thu Dec  1 12:46:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2011 11:46:58 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322740018.11.0.0577605414654.issue13515@psf.upfronthosting.co.za>


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

While I acknowledge the point (it's the reason I *didn't* remove those warnings in my recent major update to the subprocess docs), Raymond's right that scattering warnings everywhere in the docs for modules like subprocess isn't the right answer either. For a lot of things people use those modules for (i.e. private scripts with no untrusted user input) the warnings are excessive.

There's only so much we can do to protect novice programmers being given tasks beyond their experience, and only so much readability we should sacrifice in the name of educating people about general programming issues that aren't specific to Python.

----------

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

From report at bugs.python.org  Thu Dec  1 13:12:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 12:12:50 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322741570.72.0.0455048089177.issue13515@psf.upfronthosting.co.za>


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

I think we are mixing a few different things here:
1) the content of the warning(s);
2) the position of the warning(s);
3) the style of the warning(s);

Duplicating the same content in each warning is bad, so a specific section that summarizes the problem is good.
Having at least a note with a link to the "Security consideration" section in each affected function is good too, because without them people won't notice it.
Having big red scary boxes is bad, because people are scared of big red things (especially scary ones), and our goal here is to warn, not to scare.

I think the problem with the subprocess doc is that there are many warnings and that they are big and red (and scary).  IMHO changing the style of the warning would already be a step forward the "clean look" advocated by Raymond.  Grouping redundant text and possibly rephrasing it a bit would do the rest.

----------

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

From report at bugs.python.org  Thu Dec  1 13:47:36 2011
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 01 Dec 2011 12:47:36 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1322743656.32.0.362759600867.issue11060@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag
Added file: http://bugs.python.org/file23828/issue11060_test_v1.diff

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

From report at bugs.python.org  Thu Dec  1 14:14:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Dec 2011 13:14:47 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322745287.44.0.582922546296.issue13515@psf.upfronthosting.co.za>


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

I agree 100% with Ezio here.

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

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

From report at bugs.python.org  Thu Dec  1 14:28:48 2011
From: report at bugs.python.org (chris)
Date: Thu, 01 Dec 2011 13:28:48 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1322746128.78.0.435304184759.issue8668@psf.upfronthosting.co.za>


Changes by chris <chris at emerge-life.de>:


----------
nosy: +chris

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

From report at bugs.python.org  Thu Dec  1 14:37:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2011 13:37:15 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322746635.05.0.461667410876.issue13515@psf.upfronthosting.co.za>


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

Yep, using notes rather than simple inline links would also be fine with me. So, with "in-line text" changed to "a ReST note", what do people otherwise think about the proposed style guide addition?

----------

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

From report at bugs.python.org  Thu Dec  1 14:38:14 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 01 Dec 2011 13:38:14 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1322746694.37.0.954413764277.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[Amaury]
> Overall, I think that the "mpd" C library should be better separated from the
> _decimal module (a bit like _ctypes, with the libffi library): its own configure
> & makefile, its own test suite... which are not necessarily related to Python.

Except for its own directory libmpdec has all that (See LIBTEST.txt). Library
tests are in the tests/ directory, python tests in the python/ directory.

Are you suggesting to build a static library and then use that to build
the module? I remember this didn't work on Windows (not to mention AIX and such).

----------

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

From report at bugs.python.org  Thu Dec  1 15:00:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Dec 2011 14:00:53 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1322748053.81.0.71043868929.issue11060@psf.upfronthosting.co.za>


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

Hi Berker Peksag, thanks for your interest in contributing.  Your patch is not what I had in mind: In test_command_sdist, a test should create an sdist and check that it fails with an error message, not instantiate a version object.  Distutils2 has many layers; at the base, version needs to reject an incorrect version with a Python exception (and we should test that in test_version), at the top, commands like check, sdist and bdist should catch that exception and display a user-friendly error message (and their tests should create Python files and run the command).  Does this help?

----------
assignee: tarek -> eric.araujo
stage:  -> test needed
versions: +Python 3.3

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

From report at bugs.python.org  Thu Dec  1 15:11:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Dec 2011 14:11:23 +0000
Subject: [issue12307] Inconsistent formatting of section titles in PEP 0
In-Reply-To: <1307685038.6.0.993227913919.issue12307@psf.upfronthosting.co.za>
Message-ID: <1322748683.57.0.95225534941.issue12307@psf.upfronthosting.co.za>


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

Plain text PEPs actually have an HTML title, it?s only PEP 0 that does not.  I?ll fix that when I get a minute.

----------

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

From report at bugs.python.org  Thu Dec  1 15:12:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Dec 2011 14:12:41 +0000
Subject: [issue13512] ~/.pypirc created insecurely
In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>
Message-ID: <1322748761.63.0.949686220656.issue13512@psf.upfronthosting.co.za>


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

Thanks for the report Vincent.  Philip, your patch looks good, except that the code cannot use the with statement due to PEP 291 (I?ll take care of that).  2.5 is also affected (the code is in the distutils.command.register module).

I don?t think we can write a test for this bug.

Barry, Martin, do you think this important enough for the versions in security mode?  (I?ve forgotten whether 2.5 is still in security mode or not, and can?t find the info online).

----------
assignee: tarek -> eric.araujo
nosy: +barry, loewis
stage:  -> patch review
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Dec  1 15:14:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Dec 2011 14:14:32 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322748872.36.0.894527699172.issue1040439@psf.upfronthosting.co.za>


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

I did a review on Rietveld.

----------

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

From report at bugs.python.org  Thu Dec  1 16:27:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Dec 2011 15:27:11 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <E1RW8XV-0004R3-G6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7e37598a25a6 by Mark Dickinson in branch 'default':
Issue #9530: Fix undefined behaviour due to signed overflow in Python/formatter_unicode.c.
http://hg.python.org/cpython/rev/7e37598a25a6

----------

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

From report at bugs.python.org  Thu Dec  1 18:03:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Dec 2011 17:03:10 +0000
Subject: [issue5302] Allow package_data specs/globs to match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1322758990.56.0.462242674775.issue5302@psf.upfronthosting.co.za>


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

As a first step for this, I moved around some things in the test file to ease coming additions.  Can someone test this patch for the distutils2 repo on Windows?

----------
keywords: +patch
Added file: http://bugs.python.org/file23829/test_sdist.diff

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

From report at bugs.python.org  Thu Dec  1 18:04:38 2011
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 01 Dec 2011 17:04:38 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1322759078.97.0.0945359422321.issue12850@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Closing the request for this patch.  It is unsatisfactory that it only offers the basic user-level STM feature of transaction, but not, say, abort_and_retry() or any other feature generally found in real-world STM implementations.  This goes against the idea, which was (in part) to let python-dev people play with it to know which features seem to make sense in Python.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec  1 18:41:30 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Thu, 01 Dec 2011 17:41:30 +0000
Subject: [issue13512] ~/.pypirc created insecurely
In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>
Message-ID: <1322761290.67.0.241964614367.issue13512@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

2.5 is done http://mail.python.org/pipermail/python-committers/2011-October/001844.html

----------

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

From report at bugs.python.org  Thu Dec  1 18:50:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 01 Dec 2011 17:50:19 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1322761819.96.0.0592558561685.issue12612@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Could you please provide a diff ?
Also, they should probably be commented by default (as other obmalloc-related calls).

----------
nosy: +neologix

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

From report at bugs.python.org  Thu Dec  1 18:55:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 01 Dec 2011 17:55:56 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1322762156.11.0.269463070027.issue13390@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> If someone finds a way to sanitize Valgrind output,

Did you use the valgrind suppression file (Misc/valgrind-python.supp)?
If yes, then one could simply use --gen-suppressions=yes to add those spurious warning to the suppression file.

> a daily Valgrind run would be cool as well.

Daily, or rather weakly, since running under valgrind is so much slower ;-)

----------

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

From report at bugs.python.org  Thu Dec  1 19:00:23 2011
From: report at bugs.python.org (Raul Morales)
Date: Thu, 01 Dec 2011 18:00:23 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
Message-ID: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>


New submission from Raul Morales <raul.mh at gmail.com>:

Sometimes log files grow very quickly and consume too much disk space (e.g. DEBUG), so compress old log files saves disk space without losing the information from log files.

I propose to add a "gzip" or "compress" argument to RotatingFileHandler and TimedRotatingFileHandler to select the number of old files you want to compress.

For example, if you set the argument to 0 (default) no files are gzipped , but if you set it to 3 you get the following log files:
app.log
app.log.1
app.log.2
app.log.3.gz
app.log.4.gz
...
app.log.n.gz

For TimedRotatingFileHandler it works similar, gzipping from the n-th newer log file to the oldest log file:
app.log
app.log.2011-12-01
app.log.2011-11-30
app.log.2011-11-29.gz
app.log.2011-11-28.gz
...

A possible patch is attached

----------
components: Library (Lib)
files: log.patch
keywords: patch
messages: 148732
nosy: ramhux, vinay.sajip
priority: normal
severity: normal
status: open
title: Gzip old log files in rotating handlers
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23830/log.patch

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

From report at bugs.python.org  Thu Dec  1 19:05:18 2011
From: report at bugs.python.org (Paul Price)
Date: Thu, 01 Dec 2011 18:05:18 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1322762718.44.0.486344617559.issue12612@psf.upfronthosting.co.za>


Paul Price <price at astro.princeton.edu> added the comment:

Here's the diff with the added sections commented out.

----------
keywords: +patch
Added file: http://bugs.python.org/file23831/proposed.patch

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

From report at bugs.python.org  Thu Dec  1 19:34:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Dec 2011 18:34:21 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1322762156.11.0.269463070027.issue13390@psf.upfronthosting.co.za>
Message-ID: <1322764152.3512.14.camel@localhost.localdomain>


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

> > If someone finds a way to sanitize Valgrind output,
> 
> Did you use the valgrind suppression file (Misc/valgrind-python.supp)?

Ah, I hadn't. But using it doesn't seem to make much of a difference.
Also, the suppressions file seems quite inflexible (it has hardcoded
library version numbers for third-party libs).

----------

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

From report at bugs.python.org  Thu Dec  1 20:29:52 2011
From: report at bugs.python.org (Rick Regan)
Date: Thu, 01 Dec 2011 19:29:52 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1322767792.58.0.538191553868.issue9009@psf.upfronthosting.co.za>


Rick Regan <exploringbinary at gmail.com> added the comment:

> 	if (!(dig = quorem(b,d))) {
> 		b = multadd(b, 10, 0);	/* very unlikely */
> 		dig = quorem(b,d);
> 		}
> 
> This code is part of the algorithm for strtod.  Here b and d are
> Bigints, and b / d is a fraction that gives an approximation to 
> the value of the input to strtod;  the aim is to produce the 
> digits of b / d one-by-one to compare them with the strtod input,
> and (eventually) use the result of that comparison work out whether
> to round up or down.

> If the condition of the 'if' block above is ever satisfied, b is 
> multiplied by 10 (that's the multadd(b, 10, 0) call), so the 
> fraction b / d is multiplied by 10 (with no corresponding correction
> for the strtod input string), and the wrong comparison is made!

Mark,

I think I know the motivation for this code, although I still don't know how it could hit. The halfway value H is scaled by a power of ten to put it in the form "d1.d2d3d4d5...". The power of ten exponent is derived from the input decimal string S, instead of computing it from H using logarithms.

Now what if H's exponent does not match S's? I'm thinking of cases like S = 10^n and H = 9.99999999... * 10^(n-1). Scaling H by 10^-n would make it 0.999999999... . That leading 0 needs to be removed, by multiplying by 10, do put it in the right form.

First of all, I don't know if a case like this is possible. Second of all, the check would fail either way (1 against 0 vs 1 against 9).
 
BTW, b / d represents only the significant digits of H, so it shouldn't matter that there's no corresponding adjustment to the input string.

To summarize: I'm not saying this code is necessary; I'm just saying it makes you wonder.

----------
nosy: +DoctorBinary

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

From report at bugs.python.org  Thu Dec  1 21:01:11 2011
From: report at bugs.python.org (Okko Willeboordse)
Date: Thu, 01 Dec 2011 20:01:11 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1322769671.1.0.077028025178.issue9090@psf.upfronthosting.co.za>


Okko Willeboordse <okko.willeboordse at gmail.com> added the comment:

I bumped into this issue at one of my customers that use Python to control a machine through Beckhoff EtherCAT. The Python code communicates with the Beckhoff EtherCAT program using TCP/IP.
They use non blocking sockets like so;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
  raise NoData
self._socket.recv(length)

They also found that the recv occasionally raises a 10035.
I changed the code in to;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
  raise NoData
try:
  buffer_ = self._socket.recv(length)
except socket.error as inst:
  if (gaius.utils.Platform.WINDOWS and 10035 == inst.args[0]) or \
     (gaius.utils.Platform.LINUX and 11 == inst.args[0]):
    raise NoData

So this issue applies also to sockets without timeout, albeit it can be worked around easily. 

Also note that this also applies to Linux as the man page of select states in the BUG section;

Under Linux, select() may report a socket file descriptor as "ready for
reading",  while  nevertheless a subsequent read blocks. This could for
example happen when data has arrived but  upon  examination  has  wrong
checksum  and is discarded. There may be other circumstances in which a
file descriptor is spuriously reported as ready.  Thus it may be  safer
to use O_NONBLOCK on sockets that should not block.

Note that Linux select is not Posix compliant as Posix states;

A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully.

See https://lkml.org/lkml/2011/6/18/76

MSDN select says;

For other sockets, readability means that queued data is available for reading such that a call to recv, WSARecv, WSARecvFrom, or recvfrom is guaranteed not to block.

http://support.microsoft.com/kb/177346 says (for Windows 95);

The Winsock select() API might fail to block on a nonblocking socket and return WSAEWOULDBLOCK as an error code when either send() or recv() is subsequently called. For example, select() may return indicating there is data to read, yet a call to recv() returns with the error code WSAEWOULDBLOCK, indicating there is no data immediately available. Windows NT 4.0 does not exhibit this behavior.


Finally I have 2 questions;

Is this select behavior on Windows 'normal'? Noting that it is not documented. or does it behaves this way due to crippled NIC's or drivers (VMWare)?

Can this behavior be reproduced? I need this for automatic testing. Now these exceptional paths cannot be tested.

----------
nosy: +Okko.Willeboordse

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

From report at bugs.python.org  Thu Dec  1 21:53:53 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Thu, 01 Dec 2011 20:53:53 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
Message-ID: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>


New submission from Thouis (Ray) Jones <thouis at gmail.com>:

On my system (OSX 10.6.8) using the python.org 32/64-bit build of 2.7.2, I see incorrect results from os.listdir() in a threaded program.  The error is that the result of os.listdir() is missing a few files from its list.

First, my use case.  I work with large image-based datasets, often with hundreds of thousands of images.  The first step in processing is to locate all of these images and extract some basic information (size, channels, etc.).  To do this more efficiently on network filesystems, where listing directories and stat()ing files is often slow, I wrote a multithreaded analog to os.walk().  While validating its results against unix 'find', I saw discrepancies in the number of files found.

My guess is that OSX's readdir() is not reentrant when dealing with SMB shares, even on different DIR pointers.  It's also possible that readdir() is not reentrant with lstat(), as some of my tests seemed to indicate this, but I need to run some more tests to be sure that's what I was actually seeing.

In any case, there are three possible ways to fix this, I think.

- Remove the Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS around readdir() in posixmodule.c

- Put a mutex on readdir()

- Use readdir_r().  I've attached a potential patch for 2.7.2 for this solution.

I would prefer the second or last approach, as they preserve the ability to do other work while listing large directories.

By my reading of the python 3.0 to 3.4 sources, this problem exists in those versions, as well.

----------
components: Library (Lib)
files: py272_readdir_r.patch
keywords: patch
messages: 148737
nosy: thouis
priority: normal
severity: normal
status: open
title: readdir() in os.listdir not threadsafe on OSX 10.6.8
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23832/py272_readdir_r.patch

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

From report at bugs.python.org  Thu Dec  1 21:56:51 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Thu, 01 Dec 2011 20:56:51 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322773011.41.0.998448764852.issue13517@psf.upfronthosting.co.za>


Thouis (Ray) Jones <thouis at gmail.com> added the comment:

Here is the script I use to detect the failure.
% python filefinder.py /PATH/TO/LARGE/DIRECTORY/TREE

(note that I was working over samba with an 8ish-level deep directory with around 250000 files).

Compare its final output in the FOUND column with 
% find /PATH/TO/LARGE/DIRECTORY/TREE | wc -l

----------
Added file: http://bugs.python.org/file23833/filefinder.py

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

From report at bugs.python.org  Thu Dec  1 22:35:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 01 Dec 2011 21:35:12 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322775312.09.0.626223256645.issue13517@psf.upfronthosting.co.za>


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

The link mentioned in the patch is really interesting:
http://womble.decadent.org.uk/readdir_r-advisory.html

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Thu Dec  1 22:54:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 01 Dec 2011 21:54:02 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322776442.57.0.3265062856.issue13517@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Is there any reason to believe that the problem is confined to OS X?

----------
nosy: +ned.deily, neologix

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

From report at bugs.python.org  Thu Dec  1 23:03:25 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Thu, 01 Dec 2011 22:03:25 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322777005.84.0.766965798378.issue13517@psf.upfronthosting.co.za>


Thouis (Ray) Jones <thouis at gmail.com> added the comment:

I should add the caveat that I am not completely confident that I have stress-tested the patch enough to be sure that it actually addresses the problem.  It is still possible that this is an error in OSX or the remote fileserver in which a large amount of concurrent traffic is causing it to actually return invalid data.  This is somewhat belied by the fact that I was running 'find' at the same time, and did not see it give variable answers, ever. I will continue testing.

----------

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

From report at bugs.python.org  Thu Dec  1 23:28:58 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Thu, 01 Dec 2011 22:28:58 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322778538.11.0.632185690176.issue13517@psf.upfronthosting.co.za>


Changes by Thouis (Ray) Jones <thouis at gmail.com>:


Added file: http://bugs.python.org/file23834/py272_readdir_r.v2.patch

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

From report at bugs.python.org  Thu Dec  1 23:31:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 01 Dec 2011 22:31:21 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322778681.37.0.665053889117.issue13517@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Is there any reason to believe that the problem is confined to OS X?

It's a bit of a grey area.
Here's what POSIX says:

http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir.html

"""
The pointer returned by readdir() points to data which may be overwritten by another call to readdir() on the same directory stream. This data is not overwritten by another call to readdir() on a different directory stream.
"""

So it seems safe as long as the threads are using distinct DIR *.
However, the documentation also says this:
"""
The readdir() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe.
"""

So in theory, readddir() could use some static/global state which may make it not thread-safe.

I just had a look at glibc's implementation, and it is indeed safe:
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/readdir.c;h=13e5e9a0213fcf37d5f289483439bff701a9708a;hb=HEAD

Every "sane" implementation should be safe in practice.

Now, it wouldn't be the first time we encounter such a stupid bug on OS X, but it would be nice to have a a short reproducer code in C to make sure.

> It's also possible that readdir() is not reentrant with lstat()

This doesn't make much sense to me.

----------

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

From report at bugs.python.org  Thu Dec  1 23:32:30 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Thu, 01 Dec 2011 22:32:30 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322778750.88.0.244059098468.issue13517@psf.upfronthosting.co.za>


Thouis (Ray) Jones <thouis at gmail.com> added the comment:

Reading through many pages discussing readdir vs. readdir_r (many on security mailing lists, a large number referring to the page linked in the patch), I get the impression that most implementations are thread-safe as long as separate threads do not call readdir() using the same DIR pointer.

I believe there is some ambiguity in the POSIX specification as to whether this is the only way in which readdir() might be thread-unsafe.

----------

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

From report at bugs.python.org  Thu Dec  1 23:38:06 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Thu, 01 Dec 2011 22:38:06 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322779086.47.0.58258183675.issue13517@psf.upfronthosting.co.za>


Thouis (Ray) Jones <thouis at gmail.com> added the comment:

> > It's also possible that readdir() is not reentrant with lstat()
> This doesn't make much sense to me.

Me either.  I think what I was actually seeing was multiple calls to readdir() still occurring even after placing a mutex on os.listdir due to my wrapping of os.listdir in a timeout via a subthread, and mutexing the timeout-wrapped version.  I will test this more carefully tomorrow.

I will also look into creating some C code to demonstrate the bug.

----------

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

From report at bugs.python.org  Thu Dec  1 23:41:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 01 Dec 2011 22:41:54 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322779314.66.0.638379025715.issue13517@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

And here's a post by Ulrich Drepper:
http://udrepper.livejournal.com/18555.html

"""
readdir_r is only needed if multiple threads are using the same directory stream. I have yet to see a program where this really is the case. In this toy example the stream (variable dir) is definitely not shared between different threads. Therefore the use of readdir is just fine. Should this matter? Yes, it should, since readdir_r has to copy the data in into the buffer provided by the user while readdir has the possibility to avoid that.
"""

So I'm even more confident that we should keep the current code.
At least, before going any further (and complicating the code), I'd like to know whether this can be reproduced with a small C snippet.

----------

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

From report at bugs.python.org  Fri Dec  2 00:19:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Dec 2011 23:19:18 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1322781558.91.0.924978199522.issue5689@psf.upfronthosting.co.za>


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

There is plenty of time until 3.3. OTOH, if Eric wants to work on it now: you got a week :-) Do recognize that there is a patch to start from already.

----------

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

From report at bugs.python.org  Fri Dec  2 00:42:56 2011
From: report at bugs.python.org (Mickey Ju)
Date: Thu, 01 Dec 2011 23:42:56 +0000
Subject: [issue13518] configparser
Message-ID: <1322782976.1.0.275624635723.issue13518@psf.upfronthosting.co.za>


New submission from Mickey Ju <mickeyju at gmail.com>:

If this issue has raised previously, then I am sorry for repeating.  I did a search but did not find related reports.

Below is the thing I did.

  config = configparser.RawConfigParser()
  #config.read_file(urlopen(path_config))
  config.read_file(open('jkl.ini', 'rb'))

The line commented out was the thing I wanted to do originally.  I wanted to parse a configuration file stored on some web server.  And I got this error "TypeError: startswith first arg must be bytes or a tuple of bytes, not str."  But after I tried, with this line "config.read_file(open('jkl.ini', 'rb'))", the same error can be reproduced.  Therefore, I think the error message should be stated another way around as "startswith first arg must be str instead of bytes or a tuple of bytes."  I have checked this by adding the lines below to configparser.py after the for-loop at line 994.

  print(type(line))
  line = str(line, 'utf-8')
  print(type(line))

That made the code work.

----------
components: Build
messages: 148747
nosy: mickeyju
priority: normal
severity: normal
status: open
title: configparser
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Dec  2 01:45:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Dec 2011 00:45:18 +0000
Subject: [issue13518] configparser
In-Reply-To: <1322782976.1.0.275624635723.issue13518@psf.upfronthosting.co.za>
Message-ID: <1322786718.59.0.667421596321.issue13518@psf.upfronthosting.co.za>


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


----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Fri Dec  2 02:04:33 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 02 Dec 2011 01:04:33 +0000
Subject: [issue13518] configparser
In-Reply-To: <1322782976.1.0.275624635723.issue13518@psf.upfronthosting.co.za>
Message-ID: <1322787873.08.0.962390081255.issue13518@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Hello, Mickey. By doing open('file', 'rb') you're explicitly stating you want the file to be opened in BINARY mode which means it doesn't return strings but bytes. This is not supported anymore in Python 3. This is clearly documented here: http://docs.python.org/dev/library/configparser.html#configparser.ConfigParser.read_file

Same goes for urllib.request.urlopen, it returns bytes because this is all Python knows at the time of reading the URL. If you happen to know the encoding (for instance by parsing the data or headers) you can do something like this: http://docs.python.org/dev/library/urllib.request.html#examples . Your example would become:

config.read_string(urlopen(path_config).read().decode('utf-8'))

Since this is a reasonable mistake to make, I'm leaving this open to adjust the exception raised if read() yields bytes instead of expected strings.

----------
assignee:  -> lukasz.langa
components: +Library (Lib) -Build
keywords: +easy
priority: normal -> low
versions: +Python 3.3

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

From report at bugs.python.org  Fri Dec  2 02:05:11 2011
From: report at bugs.python.org (Adam Forsyth)
Date: Fri, 02 Dec 2011 01:05:11 +0000
Subject: [issue13003] Bug in equivalent code for itertools.izip_longest
In-Reply-To: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>
Message-ID: <1322787911.72.0.193642596954.issue13003@psf.upfronthosting.co.za>


Adam Forsyth <agforsyth at gmail.com> added the comment:

This is marked as "wont fix" but has been fixed, the resolution should be changed.

----------
nosy: +agforsyth

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

From report at bugs.python.org  Fri Dec  2 02:11:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2011 01:11:58 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1322788318.0.0.665322459556.issue13390@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The overhead on PyObject_Malloc() is just an increment on an integer, so it is very low (or null).

The feature is interesting, but I'm not convinced that a very simple counter is enough to track memory leaks. It may help the CPython test suite, but what about real world application?

> I think we should hide at least the initial implementation
> behind PY_REF_DEBUG until we're sure we've worked the kinks
> out of it.

Programs not always behave exactly the same in debug or in release mode. Sometimes, bugs disappear in debug mode :-(

If the feature is written to track memory leaks in the CPython test suite, it's ok to only expose the function in debug mode.

> Right now this patch will allow to enrich the daily refleak runs

Did you already found real leaks using your hack^Wpatch? (was c6dafa2e2594 found by your tool?)

----------
nosy: +haypo

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

From report at bugs.python.org  Fri Dec  2 02:57:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 01:57:07 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1322791027.82.0.135484653617.issue9090@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

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

From report at bugs.python.org  Fri Dec  2 04:29:09 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 02 Dec 2011 03:29:09 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322796549.3.0.896103131224.issue13517@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Fri Dec  2 04:33:06 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Dec 2011 03:33:06 +0000
Subject: [issue13003] Bug in equivalent code for itertools.izip_longest
In-Reply-To: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>
Message-ID: <1322796786.92.0.540396036653.issue13003@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Yep, it appears that Raymond has fixed this in changeset b0065b9087ef

----------
resolution: wont fix -> fixed

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

From report at bugs.python.org  Fri Dec  2 08:21:06 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 02 Dec 2011 07:21:06 +0000
Subject: [issue11838] IDLE: make interactive code savable as a runnable script
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1322810466.88.0.91219735076.issue11838@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
nosy: +serwy

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

From report at bugs.python.org  Fri Dec  2 10:11:11 2011
From: report at bugs.python.org (aoi.leslie)
Date: Fri, 02 Dec 2011 09:11:11 +0000
Subject: [issue13519] Tkinter rowconfigure and columnconfigure functions crash
	if minsize, pad, or weight is not None
Message-ID: <1322817071.4.0.270134570046.issue13519@psf.upfronthosting.co.za>


New submission from aoi.leslie <aoi.leslie at gmail.com>:

Symptom:
When use tkinter Widget class's rowconfigure or columnconfigure function (The two functions are defined in baseclass Misc.) to get the setting for a row or column (The setting is a dict containing fields 'minsize', 'pad', 'weight', and 'uniform'.), if field value of 'minsize', 'pad', or 'weight' is a positive integer instead of None, then error |TypeError: argument of type 'int' is not iterable| is raised. Field value of 'uniform' does not matter.

Speculation:
File |tkinter.__init__|, function |_grid_configure|, line 1279, code |elif '.' in value| caused this error. The code assumes the value is a str, but the value can be int.

Suggested Fix:
Change the code block around line 1279 to handle int value as well.

----------
components: Tkinter
files: Reproduce.py
messages: 148752
nosy: aoi.leslie
priority: normal
severity: normal
status: open
title: Tkinter rowconfigure and columnconfigure functions crash if minsize, pad, or weight is not None
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23835/Reproduce.py

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

From report at bugs.python.org  Fri Dec  2 12:53:27 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Fri, 02 Dec 2011 11:53:27 +0000
Subject: [issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8
In-Reply-To: <1322772832.41.0.735087154575.issue13517@psf.upfronthosting.co.za>
Message-ID: <1322826807.74.0.888913864936.issue13517@psf.upfronthosting.co.za>


Thouis (Ray) Jones <thouis at gmail.com> added the comment:

Further testing indicates the problem is in the filesystem itself (either the server or client, but not in python).

Serializing the loops calling readdir / readdir_r fixes the problem on my system, but using either function in a large number of parallel threads causes some directory entries to be missed (usually 2 entries in a row, oddly enough).  I was also able to cause 'find' to fail in the same way by placing the filesystem under sufficient stress, which I hadn't managed to do before (leading me to trust the filesystem more than I should have).

I apologize for the noise.  I've closed this bug report.

----------
status: open -> closed

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

From report at bugs.python.org  Fri Dec  2 16:55:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 15:55:33 +0000
Subject: [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1322841333.94.0.190474263649.issue11201@psf.upfronthosting.co.za>


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

corenova, can you try what Martin said?

----------
nosy: +ezio.melotti
status: open -> pending

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

From report at bugs.python.org  Fri Dec  2 17:12:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Dec 2011 16:12:30 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1322842350.49.0.0301838141374.issue5689@psf.upfronthosting.co.za>


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

I?m perfectly happy to let Lars do it next week or next month, there is no rush.  The existing patch may even require very little or no change, as Nadeem?s module (in the stdlib) provides the same classes than the other lzma module which was used by the patch.

----------

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

From report at bugs.python.org  Fri Dec  2 17:24:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2011 16:24:11 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <E1RWVu8-0007XO-CC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bcfb499338c1 by Ezio Melotti in branch '2.7':
#8414: add more tests for "assert".  Initial patch by Gregory Nofi.
http://hg.python.org/cpython/rev/bcfb499338c1

New changeset 1efefeda00a7 by Ezio Melotti in branch '3.2':
#8414: add more tests for "assert".  Initial patch by Gregory Nofi.
http://hg.python.org/cpython/rev/1efefeda00a7

New changeset 47afbb2033aa by Ezio Melotti in branch 'default':
#8414: merge with 3.2.
http://hg.python.org/cpython/rev/47afbb2033aa

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Dec  2 17:26:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:26:36 +0000
Subject: [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1322843196.27.0.107194019076.issue8414@psf.upfronthosting.co.za>


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

Committed, thanks for the patch!
I preferred to add a separate test, because only the tests with "assert False" need to be skipped with -O, the other can run with and without -O.

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Fri Dec  2 17:27:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:27:21 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1322843241.67.0.903087214877.issue13449@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib)
stage:  -> patch review
type:  -> feature request

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

From report at bugs.python.org  Fri Dec  2 17:28:25 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Dec 2011 16:28:25 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1322843305.14.0.166617915392.issue9530@psf.upfronthosting.co.za>


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

See also issue #13496.

----------

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

From report at bugs.python.org  Fri Dec  2 17:29:13 2011
From: report at bugs.python.org (sbt)
Date: Fri, 02 Dec 2011 16:29:13 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
Message-ID: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

The attached patch makes pickle use an object's __qualname__ attribute if __name__ does not work.

This makes nested classes, unbound instance methods and static methods picklable (assuming that __module__ and __qualname__ give the correct "address").


BTW, It would not be hard to make instance methods picklable (and, as a by-product, class methods) by giving instance methods a __reduce__ method equivalent to

  def __reduce__(self):
    return (getattr, (self.__self__, self.__name__))

Is there any reason not to make such a change?

----------
files: pickle_qualname.patch
keywords: patch
messages: 148759
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: Patch to make pickle aware of __qualname__
versions: Python 3.3
Added file: http://bugs.python.org/file23836/pickle_qualname.patch

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

From report at bugs.python.org  Fri Dec  2 17:31:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:31:07 +0000
Subject: [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1322843467.14.0.919798382344.issue12005@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Dec  2 17:33:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:33:31 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>
Message-ID: <1322843611.59.0.808700725774.issue13520@psf.upfronthosting.co.za>


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


----------
components: +Extension Modules
stage:  -> patch review
type:  -> feature request

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

From report at bugs.python.org  Fri Dec  2 17:36:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2011 16:36:13 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>
Message-ID: <1322843773.54.0.341131366631.issue13520@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/issue13520>
_______________________________________

From report at bugs.python.org  Fri Dec  2 17:49:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:49:28 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1322844568.33.0.783845954563.issue12067@psf.upfronthosting.co.za>


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

Would it be ok to state that:
1) <, >, ==, >=, <=, and != compare the values of two objects;
2) the two objects don't necessarily have to be of the same type;
3) with == and !=, objects of different types compare unequal, unless they define a specific __eq__ and/or __ne__;
4) with <, >, <=, and >=, the comparison of objects of different types raises a TypeError, unless they define specific __lt__, __gt__, __le__, and __ge__;
5) some built-in types define these operations, so it's possible to compare e.g. int and floats;

This should summarize the possible behaviors.  There's no reason IMHO to expose implementation details and to special case built-in types (unless their comparison is actually different and doesn't depend on __eq__, __ne__, etc.).

----------

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

From report at bugs.python.org  Fri Dec  2 17:53:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:53:27 +0000
Subject: [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <1322844807.59.0.108293816902.issue12208@psf.upfronthosting.co.za>


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

LGTM.

----------
assignee: docs at python -> eric.araujo
nosy: +ezio.melotti
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Dec  2 17:55:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:55:36 +0000
Subject: [issue11513] chained exception/incorrect exception from tarfile.open
	on a non-existent file
In-Reply-To: <1300146032.78.0.080952835314.issue11513@psf.upfronthosting.co.za>
Message-ID: <1322844936.76.0.479298997955.issue11513@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec  2 17:56:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:56:57 +0000
Subject: [issue9420] gdbm with /usr/include/ndbm.h
In-Reply-To: <1280424380.77.0.379026276123.issue9420@psf.upfronthosting.co.za>
Message-ID: <1322845017.01.0.530044532818.issue9420@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  2 17:58:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:58:11 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1322845091.82.0.424370412376.issue2651@psf.upfronthosting.co.za>


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


----------
nosy:  -BreamoreBoy
versions: +Python 3.3

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

From report at bugs.python.org  Fri Dec  2 18:13:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Dec 2011 17:13:48 +0000
Subject: [issue13513] IOBase docs incorrectly link to the readline module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322846028.74.0.163759200277.issue13513@psf.upfronthosting.co.za>


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

That?s a known behavior of Sphinx.  Please go ahead and commit.

----------
nosy: +eric.araujo
title: IOBase docs incorrectly link to the GNU readline module -> IOBase docs incorrectly link to the readline module

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

From report at bugs.python.org  Fri Dec  2 18:13:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Dec 2011 17:13:58 +0000
Subject: [issue13513] IOBase docs incorrectly link to the readline module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322846038.31.0.716685890895.issue13513@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  2 18:16:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Dec 2011 17:16:51 +0000
Subject: [issue13499] uuid documentation example uses invalid REPL/doctest
	syntax
In-Reply-To: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>
Message-ID: <1322846211.5.0.896201892878.issue13499@psf.upfronthosting.co.za>


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

Please add >>> and commit.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Dec  2 18:21:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 17:21:12 +0000
Subject: [issue13513] IOBase docs incorrectly link to the readline module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322846472.64.0.872816097193.issue13513@psf.upfronthosting.co.za>


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

+1

----------
nosy: +ezio.melotti
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Dec  2 18:29:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2011 17:29:19 +0000
Subject: [issue13499] uuid documentation example uses invalid REPL/doctest
	syntax
In-Reply-To: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>
Message-ID: <E1RWWvF-0005Is-LN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d9e918c8d9d6 by Ezio Melotti in branch '2.7':
#13499: fix example adding >>> before the comments.
http://hg.python.org/cpython/rev/d9e918c8d9d6

New changeset 9e7728dc35e7 by Ezio Melotti in branch '3.2':
#13499: fix example adding >>> before the comments.
http://hg.python.org/cpython/rev/9e7728dc35e7

New changeset 060c7093a81f by Ezio Melotti in branch 'default':
#13499: merge with 3.2.
http://hg.python.org/cpython/rev/060c7093a81f

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Dec  2 18:30:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 17:30:00 +0000
Subject: [issue13499] uuid documentation example uses invalid REPL/doctest
	syntax
In-Reply-To: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>
Message-ID: <1322847000.42.0.534426138228.issue13499@psf.upfronthosting.co.za>


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

Done!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  2 18:49:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2011 17:49:14 +0000
Subject: [issue13494] 'cast' any value to a Boolean?
In-Reply-To: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>
Message-ID: <E1RWXEW-00077F-Ik@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2f9c986b46cd by Ezio Melotti in branch '2.7':
#13494: s/cast/convert/.  Also add a link.
http://hg.python.org/cpython/rev/2f9c986b46cd

New changeset 69369fd3514b by Ezio Melotti in branch '3.2':
#13494: s/cast/convert/.  Also add a link.
http://hg.python.org/cpython/rev/69369fd3514b

New changeset 454b97887c5a by Ezio Melotti in branch 'default':
#13494: merge with 3.2.
http://hg.python.org/cpython/rev/454b97887c5a

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Dec  2 18:50:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 17:50:39 +0000
Subject: [issue13494] 'cast' any value to a Boolean?
In-Reply-To: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>
Message-ID: <1322848239.99.0.0284732220706.issue13494@psf.upfronthosting.co.za>


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

Fixed!

@Eli
At least in the doc, I haven't seen any other suspicious use of 'cast'.

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  2 18:59:57 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 02 Dec 2011 17:59:57 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1322848797.23.0.316570788958.issue13390@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/issue13390>
_______________________________________

From report at bugs.python.org  Fri Dec  2 19:12:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Dec 2011 18:12:06 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1322849526.99.0.620381425983.issue13390@psf.upfronthosting.co.za>


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

> The feature is interesting, but I'm not convinced that a very simple
> counter is enough to track memory leaks. It may help the CPython test
> suite, but what about real world application?

Good question. A simple counter is the only thing we can enable by default, though. Anything else would require recompiling Python, which is probably a barrier for most users.

> Did you already found real leaks using your hack^Wpatch? (was
> c6dafa2e2594 found by your tool?)

yes, c6dafa2e2594 was found with this patch. It's the only one, though (there's also a leak in test_ctypes but I don't want to investigate :-)).

----------

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

From report at bugs.python.org  Fri Dec  2 19:51:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 02 Dec 2011 18:51:07 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322851867.75.0.664440430714.issue13496@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/issue13496>
_______________________________________

From report at bugs.python.org  Fri Dec  2 20:10:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Dec 2011 19:10:40 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>
Message-ID: <1322852729.3589.7.camel@localhost.localdomain>


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

> The attached patch makes pickle use an object's __qualname__ attribute
> if __name__ does not work.
> 
> This makes nested classes, unbound instance methods and static methods
> picklable (assuming that __module__ and __qualname__ give the correct
> "address").

Thanks. I'm not sure that's a good approach for protocol 3: some pickles
created by Python 3.3 would not be readable by Python 3.2. That's why I
initially added that idea to PEP 3154, for a hypothetical protocol 4.

However, perhaps it is possible to use the same reduce/getattr trick you
are proposing for instance methods?

> BTW, It would not be hard to make instance methods picklable (and, as
> a by-product, class methods) by giving instance methods a __reduce__
> method equivalent to
> 
>   def __reduce__(self):
>     return (getattr, (self.__self__, self.__name__))
> 
> Is there any reason not to make such a change?

I don't see any personally. Actually, multiprocessing has a Pickler
subclass called ForkingPickler which does something similar (in
Lib/multiprocessing/forking.py).

----------

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

From report at bugs.python.org  Fri Dec  2 20:12:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Dec 2011 19:12:40 +0000
Subject: [issue9276] pickle should support methods
In-Reply-To: <1279308320.41.0.159043379114.issue9276@psf.upfronthosting.co.za>
Message-ID: <1322853160.15.0.613178423002.issue9276@psf.upfronthosting.co.za>


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

PEP 3155 is now implemented (the __qualname__ attribute), making many more things potentially picklable. See PEP 3154 for a hypothetical new pickle protocol, and issue 13520 for a patch proposal.

----------

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

From report at bugs.python.org  Fri Dec  2 20:13:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Dec 2011 19:13:05 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>
Message-ID: <1322853185.87.0.16857771665.issue13520@psf.upfronthosting.co.za>


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


----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Fri Dec  2 20:28:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2011 19:28:37 +0000
Subject: [issue13439] turtle: Errors in docstrings of onkey and onkeypress
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <E1RWYmh-0007lm-Mn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6e03ab9950f6 by Petri Lehtinen in branch '2.7':
Issue #13439: Fix many errors in turtle docstrings.
http://hg.python.org/cpython/rev/6e03ab9950f6

New changeset cc559e1e3bd8 by Petri Lehtinen in branch '3.2':
Issue #13439: Fix many errors in turtle docstrings.
http://hg.python.org/cpython/rev/cc559e1e3bd8

New changeset 8d60c1c89105 by Petri Lehtinen in branch 'default':
Issue #13439: Merge branch 3.2
http://hg.python.org/cpython/rev/8d60c1c89105

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Dec  2 20:29:30 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 02 Dec 2011 19:29:30 +0000
Subject: [issue13439] turtle: Errors in docstrings of onkey and onkeypress
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <1322854170.67.0.912222720428.issue13439@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Fixed, thanks!

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

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

From report at bugs.python.org  Fri Dec  2 22:01:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 21:01:57 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1322859717.4.0.357760400016.issue12067@psf.upfronthosting.co.za>


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

In Python 3, where all classes inherit from object, the default rules are, by experiment, (which someone can verify from the code) simpler than you stated.

3. By default, == and /= compare identities.
4. By default, order comparisons raise TypeError.
ob <= ob raises even though ob == ob because ob is ob.

I am not sure of the method look-up rules for rich comparisons, but perhaps the following are true:

3) with == and !=, an object is equal to itself and different objects (a is not b) compare unequal, unless the class of the first define a specific __eq__ and __ne__;

4) with <, >, <=, and >=, comparison raises a TypeError, unless the class of the first object defines specific __lt__, __gt__, __le__, and __ge__, or the class of the second defines the reflected method (__ge__ reflects __lt__, etcetera);

What is not clear to me is whether the reflected method is called if the first raises TypeError. The special method names doc (reference 3.3) says "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. 
...
There are no swapped-argument versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other?s reflection, __le__() and __ge__() are each other?s reflection, and __eq__() and __ne__() are their own reflection."

Does 'not supported' mean 'raises TypeError', 'returns NotImplemented', or both? If the last, I don't really understand the reason for NotImplemented versus TypeError. That point should be clarified in 3.3 also. And 3.3 should be referenced in the comparisons section.

I think point 5 should say a bit more: builtin numbers compare as expected, even when of different types; builtin sequences compare lexicographically.

----------

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

From report at bugs.python.org  Fri Dec  2 22:32:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Dec 2011 21:32:32 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322861552.14.0.976712076178.issue13515@psf.upfronthosting.co.za>


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

Please propose a concrete new styling for the warnings; I think that should be done regardless of the other points.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Fri Dec  2 22:38:49 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 02 Dec 2011 21:38:49 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1322849526.99.0.620381425983.issue13390@psf.upfronthosting.co.za>
Message-ID: <CAK1QooonCunbUapx2xrT-o1mRo=AOSFw+OmyFJ2gC7=RtTyhWA@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Fri, Dec 2, 2011 at 12:12 PM, Antoine Pitrou <report at bugs.python.org> wrote:

> yes, c6dafa2e2594 was found with this patch. It's the only one, though (there's also a leak in test_ctypes but I don't want to investigate :-)).

I'll take a look at the ctypes leak.

----------
nosy: +meador.inge

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

From report at bugs.python.org  Fri Dec  2 22:47:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Dec 2011 21:47:50 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322862470.76.0.302871897327.issue13515@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Also consider writing a security howto guide so that the docs don't become littered with warnings.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Fri Dec  2 22:53:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 21:53:51 +0000
Subject: [issue3907] "for line in file" doesn't work for pipes
In-Reply-To: <1221793104.87.0.563162519119.issue3907@psf.upfronthosting.co.za>
Message-ID: <1322862831.18.0.190893435878.issue3907@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7 -Python 2.5

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

From report at bugs.python.org  Fri Dec  2 23:26:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 22:26:00 +0000
Subject: [issue13495] IDLE: Regression - Two ColorDelegator instances loaded
In-Reply-To: <1322510218.36.0.927250562508.issue13495@psf.upfronthosting.co.za>
Message-ID: <1322864760.29.0.881358774959.issue13495@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

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

From report at bugs.python.org  Fri Dec  2 23:37:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 22:37:18 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
In-Reply-To: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>
Message-ID: <1322865438.93.0.440315365677.issue13506@psf.upfronthosting.co.za>


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

On 3.2.2, I get
>>> import sys
>>> sys.path
['C:\\Programs\\Python32\\Lib\\idlelib', 'C:\\Windows\\system32\\python32.zip', 'C:\\Programs\\Python32\\DLLs', 'C:\\Programs\\Python32\\lib', 'C:\\Programs\\Python32', 'C:\\Programs\\Python32\\lib\\site-packages', 'F:\\Python']

so I presume the fix should include 3.2 and 3.3.

----------
nosy: +terry.reedy
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 00:18:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 23:18:48 +0000
Subject: [issue13519] Tkinter rowconfigure and columnconfigure functions crash
	if minsize, pad, or weight is not None
In-Reply-To: <1322817071.4.0.270134570046.issue13519@psf.upfronthosting.co.za>
Message-ID: <1322867928.39.0.54306369884.issue13519@psf.upfronthosting.co.za>


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

Running on Win 7, 3.2.2, IDLE, I get
''' 
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 19, in <module>
    the_rowconfigure_info = the_frame.rowconfigure(the_row_index)
  File "C:\Programs\Python32\lib\tkinter\__init__.py", line 1326, in grid_rowconfigure
    return self._grid_configure('rowconfigure', index, cnf, kw)
  File "C:\Programs\Python32\lib\tkinter\__init__.py", line 1279, in _grid_configure
    elif '.' in value:
TypeError: argument of type 'int' is not iterable
'''
(For tracker purposes, this is a graceful exit, not a crash - as in *nix segfault or equivalent Windows error box.)
'''
>>> help(Frame.rowconfigure)
Help on function grid_rowconfigure in module tkinter:

grid_rowconfigure(self, index, cnf={}, **kw)
    Configure row INDEX of a grid.
    
    Valid resources are minsize (minimum size of the row),
    weight (how much does additional space propagate to this row)
    and pad (how much space to let additionally).
'''
The above implies that setting uniform=1 (in your code) works because it is ignored. From docs on the web, it appears that 'uniform' is valid and is just missing from our doc string. It is different from the other three, though, in jperhaps not being restricted to int values.

You are right that (line 1259)
    def _grid_configure(self, command, index, cnf, kw):
expects strings (which is what tcl uses). I do not know enough, though, to know where the bug is. I do notice, however, that setting with a Python int matches online Python examples and that the code runs without the attempt to read the config.

----------
nosy: +gpolo, terry.reedy
type: crash -> behavior
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 00:33:42 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Dec 2011 23:33:42 +0000
Subject: [issue9663] importlib should exclusively open bytecode files
In-Reply-To: <1282515853.22.0.456551292376.issue9663@psf.upfronthosting.co.za>
Message-ID: <1322868822.06.0.249108183019.issue9663@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed by Issue13146.

----------
resolution:  -> out of date
stage: test needed -> 
status: open -> closed
superseder:  -> Writing a pyc file is not atomic

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

From report at bugs.python.org  Sat Dec  3 00:34:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 23:34:32 +0000
Subject: [issue11838] IDLE: make interactive code savable as a runnable script
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1322868872.28.0.240743950956.issue11838@psf.upfronthosting.co.za>


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

Roger Serway pointed me to the PastePyShell.py extension that is part of the IdleX package http://idlex.sourceforge.net/ 
That does the conversion when *pasting* interpreter text into an edit window. I would have File/Save do the same thing when saving the shell text to a .py file.

----------

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

From report at bugs.python.org  Sat Dec  3 01:30:29 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Dec 2011 00:30:29 +0000
Subject: [issue13521] Make dict.setdefault() atomic
Message-ID: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

A dialog on python-dev suggests that dict.setdefault() was intended to be atomic and that a number of experienced developers have deployed code relying on its atomicity:  http://mail.python.org/pipermail/python-3000/2007-July/008693.html

The actual implementation shows a second call to PyDict_Setitem() which can call PyObject_Hash() which can call arbitrary Python code.   http://hg.python.org/cpython/file/2.7/Objects/dictobject.c#l1937

This fix is straight-forward, use the results of the initial lookup to insert the default object.  This will make the operation atomic and it will make it faster.

----------
components: Interpreter Core
messages: 148782
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make dict.setdefault() atomic
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 01:38:50 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 03 Dec 2011 00:38:50 +0000
Subject: [issue11838] IDLE: make interactive code savable as a runnable script
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1322872730.65.0.964801965599.issue11838@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I considered saving directly from the shell but then I ran into a use-case problem. Saving the shell window as an runnable script will also save any syntax errors that were entered. A user would then have to open an editor to correct these errors.

A high-level task analysis would be as follows:
With "Save As Runnable", the user needs to save, open, and then fix.
With "Paste from Shell", the user needs to copy, paste, and then fix.


If you have suggestions for handling shell errors, I'm open to them.

----------

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

From report at bugs.python.org  Sat Dec  3 02:27:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 01:27:27 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1322875647.93.0.311798802141.issue13521@psf.upfronthosting.co.za>


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

+1.

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

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

From report at bugs.python.org  Sat Dec  3 03:15:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Dec 2011 02:15:57 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1322878557.44.0.870132752217.issue13521@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Sat Dec  3 04:35:57 2011
From: report at bugs.python.org (aoi.leslie)
Date: Sat, 03 Dec 2011 03:35:57 +0000
Subject: [issue13519] Tkinter rowconfigure and columnconfigure functions crash
	if minsize, pad, or weight is not None
In-Reply-To: <1322817071.4.0.270134570046.issue13519@psf.upfronthosting.co.za>
Message-ID: <1322883357.72.0.314549261599.issue13519@psf.upfronthosting.co.za>


aoi.leslie <aoi.leslie at gmail.com> added the comment:

Setting the config has no problem. Only reading has.

The config is read from Tk at line 1270 by code

            res = self.tk.call('grid',
                       command, self._w, index)

. If each of the four options (minsize, pad, uniform, and weight) has been set to value 1, |res|'s value after the tk call would be a tuple |('-minsize', 1, '-pad', 1, '-uniform', '1', '-weight', 1)|. This explains why |uniform|'s value does not cause problem, because it is a str, while the other three's are int. Also int 0 does not cause problem because it is handled at line 1277 by code

                if not value:
                    value = None

so the resulting option value appears as None in rowconfigure or columnconfigure's resulting dict.

In my speculation, the bug is that, when converting from the tuple returned by tk call into the resulting dict to be returned by rowconfigure or columnconfigure, the converting code assumes that the option values in the tuple returned by tk call are all str. But somehow only |uniform|'s value is str, while other three's are int.

----------

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

From report at bugs.python.org  Sat Dec  3 06:56:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2011 05:56:34 +0000
Subject: [issue11838] IDLE: make interactive code savable as a runnable script
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1322891794.74.0.0146250963163.issue11838@psf.upfronthosting.co.za>


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

Either way, it would be nice to have erroneous commands flagged or filtered. That can be detected when the first line of output is 

Traceback (most recent call last):

I typically would copy, correct, and rerun a line until I get it correct, so I would want bad lines just removed. Others might prefer otherwise. I should take a look at your extension when I get a chance.

----------

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

From report at bugs.python.org  Sat Dec  3 09:21:36 2011
From: report at bugs.python.org (Christopher Smith)
Date: Sat, 03 Dec 2011 08:21:36 +0000
Subject: [issue13439] turtle: Errors in docstrings of onkey and onkeypress
In-Reply-To: <1322854170.67.0.912222720428.issue13439@psf.upfronthosting.co.za>
Message-ID: <CAEPTCsMzS623_mb_WNMDZke9MsPLPgBkvGg0obcatL5Zp+7odA@mail.gmail.com>


Christopher Smith <smichr at users.sourceforge.net> added the comment:

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

Nice to see a good thing get even better. Thanks for you work.

Chris Smith

----------

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

From report at bugs.python.org  Sat Dec  3 10:56:30 2011
From: report at bugs.python.org (Urjit Bhatia)
Date: Sat, 03 Dec 2011 09:56:30 +0000
Subject: [issue13127] xml.dom.Attr.name is not labeled as read-only
In-Reply-To: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>
Message-ID: <1322906190.67.0.159266521622.issue13127@psf.upfronthosting.co.za>


Urjit Bhatia <urjitsb87 at gmail.com> added the comment:

Using the same code example as above, I added a simple print statement in the set method being defined in the defproperty and it fired correctly for -

a.childNodes[0].attributes='something'
**My print statement:**in defproperty set for name: attributes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/urjit/code/mercurial/python/cpython/Lib/xml/dom/minicompat.py", line 106, in set
    "attempt to modify read-only attribute " + repr(name))
xml.dom.NoModificationAllowedErr: attempt to modify read-only attribute 'attributes'

The getter seems to work fine for localName but the setter somehow does not fire.

I have a fix for this but when I am running the test on my ubuntu vm, it doesnt go beyond test_sndhdr. However, when I run that test directly, it is successful. I can submit a patch if this problem is fixed.

----------
nosy: +urjitsb87

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

From report at bugs.python.org  Sat Dec  3 13:08:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Dec 2011 12:08:49 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
Message-ID: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

A couple of -1.0 error return codes aren't documented, see for
example PyFloat_AsDouble() and PyComplex_AsCComplex().

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 148789
nosy: docs at python, mark.dickinson, skrah
priority: low
severity: normal
stage: needs patch
status: open
title: Document error return values for PyFloat_* and PyComplex_*
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/issue13522>
_______________________________________

From report at bugs.python.org  Sat Dec  3 13:13:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Dec 2011 12:13:07 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1322914387.74.0.526467535601.issue13522@psf.upfronthosting.co.za>


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

Well, it's sort of documented implicitly:  from

http://docs.python.org/c-api/intro.html#exceptions

"In general, when a function encounters an error, it sets an exception, discards any object references that it owns, and returns an error indicator.  If not documented otherwise, this indicator is either NULL or -1, depending on the function?s return type."

----------
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Dec  3 13:18:58 2011
From: report at bugs.python.org (lennartyseboodt)
Date: Sat, 03 Dec 2011 12:18:58 +0000
Subject: [issue13523] Python does not warn in module .py files does not exist
	if there is still a .pyc file
Message-ID: <1322914738.52.0.754629082847.issue13523@psf.upfronthosting.co.za>


New submission from lennartyseboodt <lennart.yseboodt at philips.com>:

Python does not warn/error when importing a module where the module.py file no longer exists, but there is still a .pyc file present.

It also does not warn when the imported file.py is a symlink pointing nowhere. As long as there is still a .pyc file with the correct name it does not warn/error.

Attached is a minimal set to demonstrate. Execute test.py.

----------
files: pythonbug.tar.gz
messages: 148791
nosy: lennartyseboodt
priority: normal
severity: normal
status: open
title: Python does not warn in module .py files does not exist if there is still a .pyc file
versions: Python 2.7
Added file: http://bugs.python.org/file23837/pythonbug.tar.gz

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

From report at bugs.python.org  Sat Dec  3 13:20:23 2011
From: report at bugs.python.org (Andrey Morozov)
Date: Sat, 03 Dec 2011 12:20:23 +0000
Subject: [issue13524] critical error with import tempfile
Message-ID: <1322914823.87.0.666849629429.issue13524@psf.upfronthosting.co.za>


New submission from Andrey Morozov <andrey.morozov at itseez.com>:

run_me.py: 
import subprocess, sys
e = {'PATH_TO_MY_APPS' : "path/to/my/apps"}
p = subprocess.Popen(sys.executable + " test1.py 123", env=e, shell=True, stdout=subprocess.PIPE)
print(p.stdout.readlines())
p.wait()


test1.py:
1: import sys, os
2: #import tempfile
3: print("hello : " + sys.platform + " PATH: " + os.environ['PATH_TO_MY_APPS'])

System:
Python 2.7.2 x64, Windows x64 7 Pro + SP1

Problem:
if I run python run_me.py then I see on my stdout:
['hello : win32 PATH: path/to/my/apps\r\n']

but if I uncomment line number 2 in test1.py  and run python run_me.py then I see on my stdout :

C:\tmp\python_test>python run_me.py
Traceback (most recent call last):
  File "test1.py", line 2, in <module>
    import tempfile
  File "C:\Python27\lib\tempfile.py", line 34, in <module>
    from random import Random as _Random
  File "C:\Python27\lib\random.py", line 883, in <module>
    _inst = Random()
  File "C:\Python27\lib\random.py", line 97, in __init__
    self.seed(x)
  File "C:\Python27\lib\random.py", line 111, in seed
    a = long(_hexlify(_urandom(16)), 16)
WindowsError: [Error -2146893818] Invalid Signature
[]

----------
files: run_me.py
messages: 148792
nosy: Andrey.Morozov
priority: normal
severity: normal
status: open
title: critical error with import tempfile
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23838/run_me.py

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

From report at bugs.python.org  Sat Dec  3 13:22:57 2011
From: report at bugs.python.org (Andrey Morozov)
Date: Sat, 03 Dec 2011 12:22:57 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <1322914823.87.0.666849629429.issue13524@psf.upfronthosting.co.za>
Message-ID: <1322914977.87.0.888217034141.issue13524@psf.upfronthosting.co.za>


Andrey Morozov <andrey.morozov at itseez.com> added the comment:

WIDW ?

----------
Added file: http://bugs.python.org/file23839/test1.py

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

From report at bugs.python.org  Sat Dec  3 13:27:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 12:27:31 +0000
Subject: [issue13523] Python does not warn in module .py files does not exist
	if there is still a .pyc file
In-Reply-To: <1322914738.52.0.754629082847.issue13523@psf.upfronthosting.co.za>
Message-ID: <1322915251.31.0.26875459737.issue13523@psf.upfronthosting.co.za>


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

Python doesn't require the .py to run the code if there's a .pyc.  This is expected so there's no need to give a warning.

If the .py is present but it's a symlink pointing nowhere, it might make sense to give a warning before falling back silently on the .pyc.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Dec  3 13:30:06 2011
From: report at bugs.python.org (Tim Golden)
Date: Sat, 03 Dec 2011 12:30:06 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <1322914823.87.0.666849629429.issue13524@psf.upfronthosting.co.za>
Message-ID: <4EDA1648.1060004@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

The environment passed to a Windows process must contain
certain things. (I don't at this moment remember exactly
what). You can't just pass the one thing you're adding.
Change your "e = ..." line to something like:

e = os.environ
e['PATH_TO_MY_CODE'] = '/x/y/z'

and then try the code.

Obviously the subprocess module doesn't have enough
checks in place for this -- it actually segfaults on my
WinXP machine. But can you confirm that this is indeed
your issue?

----------
nosy: +tim.golden

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

From report at bugs.python.org  Sat Dec  3 13:34:23 2011
From: report at bugs.python.org (Andrey Morozov)
Date: Sat, 03 Dec 2011 12:34:23 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <1322914823.87.0.666849629429.issue13524@psf.upfronthosting.co.za>
Message-ID: <1322915663.01.0.014448777498.issue13524@psf.upfronthosting.co.za>


Andrey Morozov <andrey.morozov at itseez.com> added the comment:

it fix my problem:

e = os.environ.copy()
e['PATH_TO_MY_APPS'] = "path/to/my/apps"

p = subprocess.Popen(sys.executable + " test1.py 123", env=e, shell=True, stdout=subprocess.PIPE)

answer: need have copy of environments

----------
status: open -> closed

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

From report at bugs.python.org  Sat Dec  3 13:35:16 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Dec 2011 12:35:16 +0000
Subject: [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <1322915716.87.0.409479948893.issue12965@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> Ultimately, I think it would make sense to remove all __int__
> conversions from Objects/longobject.c;

+1

I think this API cleanup is worth some (probably very limited)
breakage in third party modules.

----------

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

From report at bugs.python.org  Sat Dec  3 14:17:22 2011
From: report at bugs.python.org (Nicolas Goutte)
Date: Sat, 03 Dec 2011 13:17:22 +0000
Subject: [issue13525] Tutorial: Example of Source Code Encoding triggers error
Message-ID: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>


New submission from Nicolas Goutte <nicolas.goutte at extragroup.de>:

Current Behaviour

The tutorial of Python 3.2.x has an example to set an encoding in a source file: http://docs.python.org/py3k/tutorial/interpreter.html#source-code-encoding

It explains to set the following line at the start of the source code:
# -*- coding: cp-1252 -*-

However when done exactly so, Python raises the following exception:
SyntaxError: encoding problem: with BOM

The problem seems to be that Python knows Windows codepage 1252 as windows-1252 (its IANA charset name, see http://www.iana.org/assignments/charset-reg/windows-1252 ) or alternatively as cp1252 (without dash) but not as cp-1252 (with dash).

As this is an example in the tutorial is particularly problematic, as users might not understand how to do it correctly.

This is still the case in the tutorial of Python 3.3 alpha: http://docs.python.org/dev/tutorial/interpreter.html#source-code-encoding


Expected Behaviour

The tutorial should give a correct example, for example with:
# -*- coding: windows-1252 -*-

Alternatively a totally other example as for Python 2.7 would be nice too: http://docs.python.org/tutorial/interpreter.html#source-code-encoding


Notes:
I have tested this with following Python implementations:
- Python 3.2.1 (openSUSE 12.1) on Linux
- Python 3.2.2 on Windows 7 SP1 64 Bits
- Python 3.2.2 on MacOS 10.5.8
(Always on the command line; I have not tested in IDLE.)

----------
assignee: docs at python
components: Documentation
files: cp_1252broken.py
messages: 148798
nosy: docs at python, nicolasg
priority: normal
severity: normal
status: open
title: Tutorial: Example of Source Code Encoding triggers error
versions: Python 3.2
Added file: http://bugs.python.org/file23840/cp_1252broken.py

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

From report at bugs.python.org  Sat Dec  3 14:19:06 2011
From: report at bugs.python.org (Nicolas Goutte)
Date: Sat, 03 Dec 2011 13:19:06 +0000
Subject: [issue13525] Tutorial: Example of Source Code Encoding triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1322918346.83.0.366976916675.issue13525@psf.upfronthosting.co.za>


Changes by Nicolas Goutte <nicolas.goutte at extragroup.de>:


Added file: http://bugs.python.org/file23841/windows_1252ok.py

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

From report at bugs.python.org  Sat Dec  3 14:23:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 13:23:54 +0000
Subject: [issue13525] Tutorial: Example of Source Code Encoding triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1322918634.05.0.40251898743.issue13525@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 14:25:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Dec 2011 13:25:52 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1322918752.35.0.507229459385.issue13522@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Good point. - I just had to figure out if the pattern

    Py_complex c = PyComplex_AsCComplex(w);
    if (c.real == -1.0 && PyErr_Occurred()) {
        ...

will always be reliable in the future. The source of PyComplex_AsCComplex()
suggests that it will, on the other hand in getargs.c the pattern isn't
used.

The passage you quoted is quite clear, so I wouldn't mind if you
close this.

I'm not sure how many people read that passage though. :)

----------

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

From report at bugs.python.org  Sat Dec  3 14:44:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 13:44:41 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <E1RWptP-0005HI-Lj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3eb73f45a614 by Charles-Fran?ois Natali in branch 'default':
Issue #12612: Add some Valgrind suppressions for 64-bit machines. Patch by Paul
http://hg.python.org/cpython/rev/3eb73f45a614

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Dec  3 14:45:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Dec 2011 13:45:56 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1322919956.38.0.75224872787.issue12612@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed, thanks for the patch!

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

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

From report at bugs.python.org  Sat Dec  3 15:00:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 14:00:36 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <E1RWq8m-0006Nm-Az@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3b505df38fd8 by Jason R. Coombs in branch '3.2':
Issue #12666: Clarifying changes in map for Python 3
http://hg.python.org/cpython/rev/3b505df38fd8

New changeset 0e2812b16f5f by Jason R. Coombs in branch '3.2':
Issue #12666: Added section about map changes.
http://hg.python.org/cpython/rev/0e2812b16f5f

New changeset 51af35bd46f7 by Jason R. Coombs in branch 'default':
Merge fix for Issue #12666 from 3.2
http://hg.python.org/cpython/rev/51af35bd46f7

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Dec  3 15:01:20 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 03 Dec 2011 14:01:20 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1322920880.78.0.678136703679.issue12666@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Sat Dec  3 15:46:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 14:46:13 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <E1RWqqx-0000qB-Q2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ee94b89f65ab by Jason R. Coombs in branch '2.7':
Issue #13211: Add .reason attribute to HTTPError to implement parent class (URLError) interface.
http://hg.python.org/cpython/rev/ee94b89f65ab

New changeset abfe76a19f63 by Jason R. Coombs in branch '3.2':
Issue #13211: Add .reason attribute to HTTPError to implement parent class (URLError) interface.
http://hg.python.org/cpython/rev/abfe76a19f63

New changeset deb60efd32eb by Jason R. Coombs in branch 'default':
Merged fix for #13211 from 3.2
http://hg.python.org/cpython/rev/deb60efd32eb

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Dec  3 15:47:19 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 03 Dec 2011 14:47:19 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322923639.85.0.0611750541555.issue13211@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Sat Dec  3 15:49:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 14:49:21 +0000
Subject: [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1322923761.44.0.805214226113.issue13498@psf.upfronthosting.co.za>


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


----------
nosy: +Arfrever, belopolsky, draghuram, eric.araujo, gagenellina, georg.brandl, giampaolo.rodola, ijmorlan, terry.reedy, ysj.ray, zooko

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

From report at bugs.python.org  Sat Dec  3 15:53:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 14:53:33 +0000
Subject: [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1322924013.41.0.166945578785.issue13501@psf.upfronthosting.co.za>


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

ISTM --with-readline=yes should just be --with-readline, and the =no forms should just be --without-readline.  That would be more in line with other options and less confusing (--without-readline=no ?!).

There is no trunk anymore now that we?ve switched away from Subversion; you should probably work on the Mercurial default branch (see devguide).

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  3 15:54:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 14:54:49 +0000
Subject: [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1322924089.59.0.604414491351.issue13501@psf.upfronthosting.co.za>


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

And if this is really two different requests (port readline module to FreeBSD i.e. change if __APPLE__ to if HAVE_EDITLINE and give more control about readline vs. editline in the configure script), then two reports should be opened.

----------

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

From report at bugs.python.org  Sat Dec  3 15:55:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 14:55:23 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1322924123.2.0.954729304028.issue13500@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo, haypo
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Dec  3 15:56:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 14:56:28 +0000
Subject: =?utf-8?q?=5Bissue13518=5D_configparser_can=E2=80=99t_read_file_objects_f?=
	=?utf-8?q?rom_urlopen?=
In-Reply-To: <1322782976.1.0.275624635723.issue13518@psf.upfronthosting.co.za>
Message-ID: <1322924188.37.0.186698111384.issue13518@psf.upfronthosting.co.za>


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


----------
title: configparser -> configparser can?t read file objects from urlopen

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

From report at bugs.python.org  Sat Dec  3 15:59:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 14:59:24 +0000
Subject: [issue13511] ./configure --includedir, --libdir accept multiple
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1322924364.42.0.299710629562.issue13511@psf.upfronthosting.co.za>


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

> For ./configure, --includedir and --libdir both cannot handle multiple packages.
I see ?packages? means ?directories? here.  Is it a standard configure feature to support multiple --includedir and --libdir?  Does it work if you pass --includedir one:two instead?  Links would be welcome.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  3 16:01:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 15:01:11 +0000
Subject: [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <1322924471.2.0.810680234188.issue12208@psf.upfronthosting.co.za>


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

Thank you sir.  I fixed the directive markup in 4f860536efa3, I?m committing the rest now.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec  3 16:01:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 15:01:30 +0000
Subject: [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <E1RWr5l-0001xS-CQ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9ffb00748a47 by ?ric Araujo in branch 'default':
Fix glitches in email.policy docs (#12208)
http://hg.python.org/cpython/rev/9ffb00748a47

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Dec  3 16:19:18 2011
From: report at bugs.python.org (Paul Price)
Date: Sat, 03 Dec 2011 15:19:18 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1322925558.17.0.135005171876.issue12612@psf.upfronthosting.co.za>


Paul Price <price at astro.princeton.edu> added the comment:

Welcome.  Thank you!

----------

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

From report at bugs.python.org  Sat Dec  3 18:12:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 17:12:12 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1322932332.51.0.566302385255.issue13522@psf.upfronthosting.co.za>


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

I think it's still a good idea to spell it out explicitly in each function description. The document pointed by Mark is long enough that it's easy to overlook or forget that single important statement.

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

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

From report at bugs.python.org  Sat Dec  3 18:16:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 17:16:21 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322932581.75.0.948764751761.issue13515@psf.upfronthosting.co.za>


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

For the record, the SSL module has a separate security considerations section:
http://docs.python.org/dev/library/ssl.html#security-considerations

----------

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

From report at bugs.python.org  Sat Dec  3 19:02:26 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 03 Dec 2011 18:02:26 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1322935346.16.0.960990277312.issue13521@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> needs patch

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

From report at bugs.python.org  Sat Dec  3 19:05:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Dec 2011 18:05:09 +0000
Subject: [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1322935509.2.0.504560189513.issue13501@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Without having yet done a detailed review of the patch and the configure options, I don't see a need to open a second issue.  The scope of this one is fine: generalizing the support of libedit to other platforms.

----------

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

From report at bugs.python.org  Sat Dec  3 19:14:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 18:14:05 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936045.04.0.745211977344.issue13515@psf.upfronthosting.co.za>


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

Attached a patch to make the CSS used for warnings and notes less evident by removing the red/gray background color.

----------
keywords: +patch
Added file: http://bugs.python.org/file23842/issue13515.diff

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

From report at bugs.python.org  Sat Dec  3 19:14:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 18:14:36 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936076.83.0.018932314799.issue13515@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23843/warnnew.png

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

From report at bugs.python.org  Sat Dec  3 19:14:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 18:14:52 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936092.52.0.938846637368.issue13515@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23844/warnold.png

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

From report at bugs.python.org  Sat Dec  3 19:18:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 18:18:35 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322936045.04.0.745211977344.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936003.3279.0.camel@localhost.localdomain>


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

> Attached a patch to make the CSS used for warnings and notes less
> evident by removing the red/gray background color.

This really years for an icon, IMO. A bit more indenting would be good,
too, so that it stands out clearly from the rest of the text.

----------

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

From report at bugs.python.org  Sat Dec  3 19:27:44 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 03 Dec 2011 18:27:44 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1322936864.72.0.417899279268.issue13521@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Atomic and faster... +1.

----------
nosy: +jcea

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

From report at bugs.python.org  Sat Dec  3 19:51:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 18:51:44 +0000
Subject: [issue13513] IOBase docs incorrectly link to the readline module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <E1RWugW-0001SH-O4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fb8b6d310fb8 by Meador Inge in branch '2.7':
Issue #13513: IOBase docs incorrectly link to the readline module
http://hg.python.org/cpython/rev/fb8b6d310fb8

New changeset 9792e812198f by Meador Inge in branch '3.2':
Issue #13513: IOBase docs incorrectly link to the readline module
http://hg.python.org/cpython/rev/9792e812198f

New changeset ab5bc05ac223 by Meador Inge in branch 'default':
Issue #13513: IOBase docs incorrectly link to the readline module
http://hg.python.org/cpython/rev/ab5bc05ac223

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Dec  3 19:53:38 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 03 Dec 2011 18:53:38 +0000
Subject: [issue13513] IOBase docs incorrectly link to the readline module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322938418.55.0.700291076934.issue13513@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Fixed.  Thanks for the review y'all.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec  3 20:10:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Dec 2011 19:10:51 +0000
Subject: [issue13526] Deprecate the old Unicode API
Message-ID: <1322939449.96.0.831797199263.issue13526@psf.upfronthosting.co.za>


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

Attached patch modifies the following function to emit a DeprecationWarning:
 * PyUnicode_GET_SIZE() (and so PyUnicode_GET_DATA_SIZE())
 * PyUnicode_AS_UNICODE()
 * PyUnicode_AsUnicodeAndSize() (and so PyUnicode_AsUnicode())
 * PyUnicode_FromUnicode()

PyUnicode_GET_SIZE() macro is converted to a function.

The patch adds PyUnicode_AsWideCharAndSize() because PyUnicode_AsUnicodeAndSize() is deprecated and it is still useful to convert a Unicode string to wchar_t* without having to care of freeing the memory.

The patch changes tests to ignore DeprecationWarning.

--

"PyUnicode_AsWideCharAndSize" name is maybe confusing because "PyUnicode_AsWideChar" exists, whereas PyUnicode_AsWideChar() requires to free explicitly the memory.

--

PyUnicode_AsUnicodeAndSize() should maybe fail with an error if the string kind is not PyUnicode_WCHAR_KIND.

--

The CJK codecs should be modified to use the new Unicode API before applying this patch, or test_codecs (and other tests using CJK codecs) would fail with python -Werror.

----------
components: Unicode
files: unicode_warn_deprecate.patch
keywords: patch
messages: 148818
nosy: ezio.melotti, haypo, loewis
priority: normal
severity: normal
status: open
title: Deprecate the old Unicode API
versions: Python 3.3
Added file: http://bugs.python.org/file23845/unicode_warn_deprecate.patch

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

From report at bugs.python.org  Sat Dec  3 20:47:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 19:47:49 +0000
Subject: [issue13526] Deprecate the old Unicode API
In-Reply-To: <1322939449.96.0.831797199263.issue13526@psf.upfronthosting.co.za>
Message-ID: <1322941669.1.0.475117829975.issue13526@psf.upfronthosting.co.za>


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

I'm not sure it is customary for C APIs to emit deprecation warnings.

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

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

From report at bugs.python.org  Sat Dec  3 20:49:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 19:49:56 +0000
Subject: [issue13523] Python does not warn in module .py files does not exist
	if there is still a .pyc file
In-Reply-To: <1322914738.52.0.754629082847.issue13523@psf.upfronthosting.co.za>
Message-ID: <1322941796.07.0.638862615075.issue13523@psf.upfronthosting.co.za>


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

Indeed, this is a feature, not a bug. Lone pyc files are used by some people to provide "binary only" distributions of Python software (I'm not really saying it's a good idea, but some people rely on it).

As for symlinks, well... This would complicate the code quite a bit and I'm not sure there's really a point to warn about it.

----------
nosy: +brett.cannon, ncoghlan, pitrou
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 21:14:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 20:14:56 +0000
Subject: [issue13527] Remove obsolete mentions in the GUIs page
Message-ID: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>


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

The "Other Graphical User Interface Packages" page (library/othergui.html) lists "Python megawidgets" and "Tkinter3000 Widget Construction Kit (WCK)". These two projects look pretty much dead to me, so I'm proposing to remove them.

----------
assignee: docs at python
components: Documentation
messages: 148821
nosy: docs at python, pitrou
priority: low
severity: normal
status: open
title: Remove obsolete mentions in the GUIs page
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 23:16:08 2011
From: report at bugs.python.org (Tim Golden)
Date: Sat, 03 Dec 2011 22:16:08 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <1322914823.87.0.666849629429.issue13524@psf.upfronthosting.co.za>
Message-ID: <1322950568.75.0.249984760479.issue13524@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Re-opening because there's a real problem here which can crash Python hard. Simplest reproduction:

import sys
import subprocess

subprocess.Popen (sys.executable, env={})

Affects 2.x and 3.x tip (haven't tried others yet but I don't imagine it's different)

----------
assignee:  -> tim.golden
components: +Library (Lib), Windows
stage:  -> test needed
status: closed -> open

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

From report at bugs.python.org  Sat Dec  3 23:17:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 22:17:40 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <1322914823.87.0.666849629429.issue13524@psf.upfronthosting.co.za>
Message-ID: <1322950660.81.0.86894647858.issue13524@psf.upfronthosting.co.za>


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

> Re-opening because there's a real problem here which can crash Python
> hard.

Works under Linux. Is it Windows-specific?

----------
nosy: +pitrou
stage: test needed -> 
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Dec  3 23:18:41 2011
From: report at bugs.python.org (Tim Golden)
Date: Sat, 03 Dec 2011 22:18:41 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <1322950660.81.0.86894647858.issue13524@psf.upfronthosting.co.za>
Message-ID: <4EDAA03C.9050003@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Yes. I've added the "Windows" component on the tracker.
(At least I think I have). It's to do with CreateProcess
needing at least certain items in the environment passed.
I'm trying to track down some docs on MSDN which specify
which must be there.

----------

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

From report at bugs.python.org  Sun Dec  4 00:00:26 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 03 Dec 2011 23:00:26 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
In-Reply-To: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>
Message-ID: <1322953226.35.0.387726026872.issue13506@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I have given this issue some further consideration, and realized that my "+1" recommendation was not correct.

Starting the interactive python interpreter will automatically include [''] in sys.path. A fresh restart of IDLE's shell does NOT include ''.

However, running a python script will have sys.path include the absolute path to the script. IDLE's shell does do this in conjunction with ScriptBinding's "Run Module".

The new patch preserves the existing correct behavior, but also fixes the issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file23846/issue13506.patch

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

From report at bugs.python.org  Sun Dec  4 01:24:07 2011
From: report at bugs.python.org (Julian Berman)
Date: Sun, 04 Dec 2011 00:24:07 +0000
Subject: [issue13523] Python does not warn in module .py files does not exist
	if there is still a .pyc file
In-Reply-To: <1322914738.52.0.754629082847.issue13523@psf.upfronthosting.co.za>
Message-ID: <1322958247.14.0.372907187746.issue13523@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

I know this is a feature, and on occasion as pointed out a useful one. But in some cases it can be a tad annoying as the OP probably considered it.

I had a recent example where a lingering .pyc made my test suite pass (and me nearly push broken code) despite the fact that I'd moved the file away and edited it, with bugs. Obviously I now remember to rebuild and remove all .pyc's before I commit, but it took a near miss to remind me to.

Would it be useful to have a command line flag that did something like this (perhaps that test runners could set by default) to prevent others from running into similar situations?

----------
nosy: +Julian

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

From report at bugs.python.org  Sun Dec  4 02:12:46 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Dec 2011 01:12:46 +0000
Subject: [issue13527] Remove obsolete mentions in the GUIs page
In-Reply-To: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>
Message-ID: <1322961166.15.0.00817527658873.issue13527@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

+1

----------
keywords: +easy
nosy: +eli.bendersky

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

From report at bugs.python.org  Sun Dec  4 03:05:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 02:05:13 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322964313.55.0.773846272627.issue13211@psf.upfronthosting.co.za>


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

The 3.x buildbots are all broken: http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable&category=3.x.unstable

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

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

From report at bugs.python.org  Sun Dec  4 04:33:29 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 04 Dec 2011 03:33:29 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1322969609.46.0.476602870597.issue12555@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Is the following change in behavior caused by the fix for this issue?

$ python3.2 -c $'class A(IOError):\n  def __init__(self, arg): pass\nA(arg=1)'
$ python3.3 -c $'class A(IOError):\n  def __init__(self, arg): pass\nA(arg=1)'
Traceback (most recent call last):
  File "<string>", line 3, in <module>
TypeError: A does not take keyword arguments

----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Dec  4 04:35:45 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 04 Dec 2011 03:35:45 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322969745.27.0.420087122501.issue13211@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I suspect that this problem is caused by the fix for issue #12555.

----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Dec  4 04:59:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 03:59:14 +0000
Subject: [issue13523] Python does not warn in module .py files does not exist
	if there is still a .pyc file
In-Reply-To: <1322914738.52.0.754629082847.issue13523@psf.upfronthosting.co.za>
Message-ID: <1322971154.37.0.679414006992.issue13523@psf.upfronthosting.co.za>


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

In Python 3.2 and later, standalone .pyc files are no longer created as a side effect of import. Instead, cached files are stored in a __pycache__ subdirectory and ignored completely if the corresponding source file is no longer present. (Standalone .pyc files may still be created explicitly for sourceless Python distribution)

See PEP 3147 for details.

Warnings for accidental use of standalone .pyc files will not be added to earlier versions, since there is no way for Python to tell the difference between accidental and deliberate use.

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

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

From report at bugs.python.org  Sun Dec  4 05:10:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 04:10:21 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1322971821.87.0.707014467438.issue12555@psf.upfronthosting.co.za>


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

Indeed, this seems to be the most likely culprit for the current buildbot failures in the new urllib2 tests:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2868/steps/test/logs/stdio

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

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

From report at bugs.python.org  Sun Dec  4 05:17:09 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 04 Dec 2011 04:17:09 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322972229.9.0.837162991133.issue11816@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

Instead of a get_instructions() function, How about using a DisCode class that defines the API for accessing Opinfo tuples of a disassembled object.

So instead of...

    for instr in dis.bytecode_instructions(thing):
        process(instr)

You could use...

    for instr in dis.DisCode(thing):
        process(instr)

And I would like to be able to do...

    assertEqual(DisCode(thing1), DisCode(thing2))


It could also have a .dis() method that returns formatted output that matches what dis() currently prints.  That would allow tests that use dis.dis() to get rid of capturing stdout with minimal changes.

     result = DisCode(func).dis()  # return a dis compatible string.

A DisCode object also offers a nice place to put documentation for the various pieces and an overall view of the new API without getting it confused with the current dis.dis() API.

It's easier for me to remember an object with methods than several separate but related functions. (YMMV)

This is very near a version of dis I did a while back where I removed the prints and returned a list of list object from dis.dis().  The returned object had __repr__ that formatted the data so it matched the current dis output.  That made it work the same in a python shell. But I could still access and alter individual lines and fields by indexing or iterating it.  While it worked nicely, it wouldn't be backwards compatible.

----------
nosy: +ron_adam

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

From report at bugs.python.org  Sun Dec  4 05:18:07 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Dec 2011 04:18:07 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322972287.36.0.74514819901.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Antoine, I think Arfrever is on to something here. It does appear the new test added to test_urllib2 is failing, but for reasons I don't exactly understand. I'm initializing the HTTPError instance according to its signature in urllib.error, but it fails to accept keyword arguments.

I guess for the sake of this test, I can pass positional arguments, though this added limitation should probably be addressed in #12555.

----------

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

From report at bugs.python.org  Sun Dec  4 05:20:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Dec 2011 04:20:43 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <E1RX3ZA-00069I-G3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a3ddee916808 by Jason R. Coombs in branch 'default':
Pass positional arguments - HTTPError is not accepting keyword arguments. Reference #13211 and #12555.
http://hg.python.org/cpython/rev/a3ddee916808

----------

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

From report at bugs.python.org  Sun Dec  4 05:20:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Dec 2011 04:20:43 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <E1RX3ZA-00069I-GA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a3ddee916808 by Jason R. Coombs in branch 'default':
Pass positional arguments - HTTPError is not accepting keyword arguments. Reference #13211 and #12555.
http://hg.python.org/cpython/rev/a3ddee916808

----------

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

From report at bugs.python.org  Sun Dec  4 05:36:11 2011
From: report at bugs.python.org (Jon Kuhn)
Date: Sun, 04 Dec 2011 04:36:11 +0000
Subject: [issue13464] HTTPResponse is missing an implementation of readinto
In-Reply-To: <1322072062.06.0.738377139897.issue13464@psf.upfronthosting.co.za>
Message-ID: <1322973371.98.0.682235957511.issue13464@psf.upfronthosting.co.za>


Jon Kuhn <jonkuhn at gmail.com> added the comment:

This is my first contribution to a real open source project.

Attached is my patch.  Suggestions for improvements are welcome.

----------
keywords: +patch
nosy: +Jon.Kuhn
Added file: http://bugs.python.org/file23847/issue13464.patch

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

From report at bugs.python.org  Sun Dec  4 06:01:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:01:06 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322974866.51.0.444025623731.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23569/issue11816_get_opinfo_branch_20111031.diff

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

From report at bugs.python.org  Sun Dec  4 06:03:36 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:03:36 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322975016.73.0.954461488157.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
hgrepos:  -17

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

From report at bugs.python.org  Sun Dec  4 06:03:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:03:49 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322975029.83.0.158295569014.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23773/9512712044a6.diff

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

From report at bugs.python.org  Sun Dec  4 06:03:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:03:58 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322975038.78.0.434385342.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
hgrepos: +93

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

From report at bugs.python.org  Sun Dec  4 06:04:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:04:32 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322975072.04.0.197887434525.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file23848/9512712044a6.diff

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

From report at bugs.python.org  Sun Dec  4 06:16:24 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Dec 2011 05:16:24 +0000
Subject: [issue13526] Deprecate the old Unicode API
In-Reply-To: <1322939449.96.0.831797199263.issue13526@psf.upfronthosting.co.za>
Message-ID: <1322975784.34.0.979742713675.issue13526@psf.upfronthosting.co.za>


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

Quoting the PEP "While the Py_UNICODE representation and APIs are deprecated with this PEP, no removal of the respective APIs is scheduled. The APIs should remain available at least five years after the PEP is accepted"

I don't think there should be warnings.

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

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

From report at bugs.python.org  Sun Dec  4 06:16:28 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:16:28 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322975788.5.0.605835290856.issue11816@psf.upfronthosting.co.za>


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

OK, there's something crazy going on with "Create Patch" failing to pick up the latest changes. I've removed all the obsolete patches, and am doing another merge from default to see if I can get it to pick things up correctly.

----------

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

From report at bugs.python.org  Sun Dec  4 06:16:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:16:37 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322975797.16.0.862474033601.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23848/9512712044a6.diff

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

From report at bugs.python.org  Sun Dec  4 06:59:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 05:59:34 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322978374.88.0.469290924526.issue11816@psf.upfronthosting.co.za>


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

Grr, "Create Patch" insists on trying to produce a patch based on https://bitbucket.org/ncoghlan/cpython_sandbox/changesets/9512712044a6.

That checkin is from *September* and ignores all my recent changes :P

Relevant meta-tracker issue: http://psf.upfronthosting.co.za/roundup/meta/issue429

Manual patch upload coming shortly...

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Dec  4 08:37:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 07:37:01 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322984221.67.0.32973431643.issue11816@psf.upfronthosting.co.za>


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

OK, manual up-to-date patch attached.

----------
Added file: http://bugs.python.org/file23849/issue11816_get_opinfo_branch_20111204.diff

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

From report at bugs.python.org  Sun Dec  4 08:46:56 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 07:46:56 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322984816.06.0.644104925994.issue11816@psf.upfronthosting.co.za>


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

@Ron: Now that it has a reasonably clear signature, I could see my way clear to making the Instruction._disassemble() method public, which makes it easy for people to compose their own disassembly output.

For all the other display methods, I prefer Ryan Kelly's suggestion of supporting a "file" argument which is then passed through to the underlying "print()" calls.

This is inconsistent with what I originally did for the code_info() APIs (where I made a separate "give me the string" function), but it's the lowest impact change that avoids the need to capture stdout.

----------

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

From report at bugs.python.org  Sun Dec  4 09:41:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Dec 2011 08:41:07 +0000
Subject: [issue13526] Deprecate the old Unicode API
In-Reply-To: <1322939449.96.0.831797199263.issue13526@psf.upfronthosting.co.za>
Message-ID: <1322988067.25.0.124343247546.issue13526@psf.upfronthosting.co.za>


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

I agree with Benjamin.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sun Dec  4 10:08:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 09:08:13 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1322969609.46.0.476602870597.issue12555@psf.upfronthosting.co.za>
Message-ID: <1322988839.3484.2.camel@localhost.localdomain>


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

> Is the following change in behavior caused by the fix for this issue?
> 
> $ python3.2 -c $'class A(IOError):\n  def __init__(self, arg): pass\nA(arg=1)'
> $ python3.3 -c $'class A(IOError):\n  def __init__(self, arg): pass\nA(arg=1)'
> Traceback (most recent call last):
>   File "<string>", line 3, in <module>
> TypeError: A does not take keyword arguments

It must be because IOError now has a significant __new__ method.
I could change it to accept arbitrary arguments but I'm not sure that's
the right solution.
Another approach would be:
- if IOError is instantiated, initialize stuff in IOError.__new__
- otherwise, initialize stuff in IOError.__init__

What do you think?

----------

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

From report at bugs.python.org  Sun Dec  4 10:21:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 09:21:48 +0000
Subject: [issue13464] HTTPResponse is missing an implementation of readinto
In-Reply-To: <1322072062.06.0.738377139897.issue13464@psf.upfronthosting.co.za>
Message-ID: <1322990508.04.0.143232096173.issue13464@psf.upfronthosting.co.za>


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

Hello Jon, and thanks for the patch. I have a couple of comments:

- readinto() shouldn't return None but 0 when there is nothing to read (this corresponds to read() returning b"")

- I see _read_chunked() is only ever called with amt=None, so perhaps it can be simplified?

Also, a nitpick: the doc entry needs a "versionadded" tag.

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

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

From report at bugs.python.org  Sun Dec  4 10:24:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 09:24:00 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1322988839.3484.2.camel@localhost.localdomain>
Message-ID: <1322990045.3484.4.camel@localhost.localdomain>


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

> > Is the following change in behavior caused by the fix for this issue?
> > 
> > $ python3.2 -c $'class A(IOError):\n  def __init__(self, arg): pass\nA(arg=1)'
> > $ python3.3 -c $'class A(IOError):\n  def __init__(self, arg): pass\nA(arg=1)'
> > Traceback (most recent call last):
> >   File "<string>", line 3, in <module>
> > TypeError: A does not take keyword arguments
> 
> It must be because IOError now has a significant __new__ method.
> I could change it to accept arbitrary arguments but I'm not sure that's
> the right solution.
> Another approach would be:
> - if IOError is instantiated, initialize stuff in IOError.__new__
> - otherwise, initialize stuff in IOError.__init__

To make things clearer, IOError.__new__ would detect if a subclass is
asked for, and then defer initialization until __init__ is called so
that argument checking is done in __init__.

----------

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

From report at bugs.python.org  Sun Dec  4 10:28:51 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Dec 2011 09:28:51 +0000
Subject: [issue13526] Deprecate the old Unicode API
In-Reply-To: <1322939449.96.0.831797199263.issue13526@psf.upfronthosting.co.za>
Message-ID: <1322990931.06.0.705527223658.issue13526@psf.upfronthosting.co.za>


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

Closing this as rejected, for the reasons given.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec  4 10:31:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 09:31:04 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1322991064.39.0.856755445214.issue12555@psf.upfronthosting.co.za>


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

There's a fairly sophisticated tapdance in object.__new__ that deals with this problem at that level.

See: http://hg.python.org/cpython/file/default/Objects/typeobject.c#l2869

The new IOError may require something similarly sophisticated to cope with subclasses that only override __init__.

----------

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

From report at bugs.python.org  Sun Dec  4 11:33:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 10:33:05 +0000
Subject: [issue9420] gdbm with /usr/include/ndbm.h
In-Reply-To: <1280424380.77.0.379026276123.issue9420@psf.upfronthosting.co.za>
Message-ID: <1322994785.56.0.829486727038.issue9420@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Dec  4 11:41:36 2011
From: report at bugs.python.org (Tim Golden)
Date: Sun, 04 Dec 2011 10:41:36 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <4EDAA03C.9050003@timgolden.me.uk>
Message-ID: <4EDB4E59.7000207@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

OK, the long and short is that spwaning a process without passing
in SystemRoot is asking for trouble. There's a blog post here
which gives an example:

http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/

And, certainly this works:

import os
import subprocess
subprocess.Popen(
     "notepad.exe",
     env={"SystemRoot" : os.environ['SystemRoot']}
)

I'm not quite sure what approach we should take in the subprocess
module. Is it a docs warning? Should we refuse to proceed if there's
no SystemRoot? Is it the caller's responsibility?
I'll ask on python-dev to gather opinions.

----------

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

From report at bugs.python.org  Sun Dec  4 15:19:21 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Dec 2011 14:19:21 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1323008361.86.0.462125251287.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After yet another commit, the build bots are green again:

http://hg.python.org/cpython/rev/8fa1dc66de5d

----------

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

From report at bugs.python.org  Sun Dec  4 17:54:49 2011
From: report at bugs.python.org (Jon Kuhn)
Date: Sun, 04 Dec 2011 16:54:49 +0000
Subject: [issue13464] HTTPResponse is missing an implementation of readinto
In-Reply-To: <1322072062.06.0.738377139897.issue13464@psf.upfronthosting.co.za>
Message-ID: <1323017689.19.0.266051766083.issue13464@psf.upfronthosting.co.za>


Jon Kuhn <jonkuhn at gmail.com> added the comment:

Thanks for the comments.  Attached is an updated patch.

In the RawIOBase docs it says "If the object is in non-blocking mode and no bytes are available, None is returned."  So I wasn't sure if that meant any time no bytes were available or just when no bytes are available and EOF has not been reached.  -- I updated it to return 0 instead of None.

I simplified _read_chunked() and renamed it to _readall_chunked() since that is all it does.  

I added the versionadded tag specifying that it was added in 3.3 since the patch is for the default branch.

----------
Added file: http://bugs.python.org/file23850/issue13464_r1.patch

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

From report at bugs.python.org  Sun Dec  4 18:01:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 17:01:32 +0000
Subject: [issue13528] Rework performance FAQ
Message-ID: <1323018091.73.0.846706598362.issue13528@psf.upfronthosting.co.za>


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

This is a slimmed down rewrite of the performance question in the FAQ (also moved around to a dedicated subheader).

----------
assignee: docs at python
components: Documentation
files: perffaq.patch
keywords: patch
messages: 148853
nosy: docs at python, pitrou, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Rework performance FAQ
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23851/perffaq.patch

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

From report at bugs.python.org  Sun Dec  4 20:14:27 2011
From: report at bugs.python.org (Irmen de Jong)
Date: Sun, 04 Dec 2011 19:14:27 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1323026067.11.0.716911875047.issue13503@psf.upfronthosting.co.za>


Irmen de Jong <irmen at razorvine.net> added the comment:

Added new patch that only does the new reduction when protocol is 3 or higher.

----------
Added file: http://bugs.python.org/file23852/bytearray3x_reduceex.patch

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

From report at bugs.python.org  Sun Dec  4 21:08:19 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 04 Dec 2011 20:08:19 +0000
Subject: [issue13529] Segfault inside of gc/weakref
Message-ID: <1323029299.59.0.686837162339.issue13529@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

I don't have a particularly minimal test case for this, however I am able to reproduce it consistently (so far reproduced on multiple machines, 32-bit and 64-bit on 2.6 and 2.7), using these steps:

First get a checkout of the PyPy repository:

hg clone ssh://hg at bitbucket.org/pypy/pypy

Next, get to the correct revision:

hg up -C 82e1fc9c253c

Finally, attempt to run the tests:

./pytest.py pypy/module/micronumpy/ -x

At this point you should have a segfault that appears to be because of a bad address for a weakref (but I could be horrifically wrong).

----------
components: Interpreter Core
messages: 148855
nosy: alex
priority: normal
severity: normal
status: open
title: Segfault inside of gc/weakref
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Dec  4 21:11:47 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 04 Dec 2011 20:11:47 +0000
Subject: [issue13529] Segfault inside of gc/weakref
In-Reply-To: <1323029299.59.0.686837162339.issue13529@psf.upfronthosting.co.za>
Message-ID: <1323029507.62.0.804726538163.issue13529@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Antoine asked for a gdb bt, here's the last couple of useful frames:


#0  _PyWeakref_ClearRef (self=0x4000000000000000) at Objects/weakrefobject.c:97
#1  0x00000000004d4c66 in handle_weakrefs (old=0x78a2b0, unreachable=0x7fffffff87b0) at Modules/gcmodule.c:595
#2  collect (generation=0) at Modules/gcmodule.c:924
#3  0x00000000004d5640 in collect_generations () at Modules/gcmodule.c:996
#4  _PyObject_GC_Malloc (basicsize=<optimized out>) at Modules/gcmodule.c:1457
#5  0x0000000000466ba9 in PyType_GenericAlloc (type=0x31d05e0, nitems=0) at Objects/typeobject.c:753
#6  0x000000000046ad83 in type_call (type=0x31d05e0, args=(257, None, [], 8, 51), kwds=0x0) at Objects/typeobject.c:721
#7  0x000000000041ebc7 in PyObject_Call (func=<type at remote 0x31d05e0>, arg=<optimized out>, kw=<optimized out>) at Objects/abstract.c:2529
#8  0x000000000049b152 in do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7fffffff89b0, func=<type at remote 0x31d05e0>)
    at Python/ceval.c:4239
#9  call_function (oparg=<optimized out>, pp_stack=0x7fffffff89b0) at Python/ceval.c:4044
#10 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666

----------

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

From report at bugs.python.org  Sun Dec  4 23:33:11 2011
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Dec 2011 22:33:11 +0000
Subject: [issue1660009] continuing problem with httplib multiple set-cookie
	headers
Message-ID: <1323037991.29.0.887780735941.issue1660009@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Sun Dec  4 23:48:05 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 04 Dec 2011 22:48:05 +0000
Subject: [issue13529] Segfault inside of gc/weakref
In-Reply-To: <1323029299.59.0.686837162339.issue13529@psf.upfronthosting.co.za>
Message-ID: <1323038885.61.0.596388059749.issue13529@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Turns out this was a subtle bug in some raw memory manipulation code, which amaury spotted.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 00:00:33 2011
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Dec 2011 23:00:33 +0000
Subject: [issue3276] httplib.HTTPConnection._send_request should not blindly
	assume dicts for headers
In-Reply-To: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za>
Message-ID: <1323039633.35.0.701136978901.issue3276@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at python.dobrogost.net>:


----------
nosy: +piotr.dobrogost
status: pending -> open

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

From report at bugs.python.org  Mon Dec  5 00:05:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Dec 2011 23:05:08 +0000
Subject: [issue13527] Remove obsolete mentions in the GUIs page
In-Reply-To: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>
Message-ID: <E1RXL7K-0004ND-TU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2111bf7e5bca by Antoine Pitrou in branch '3.2':
Issue #13527: remove mention of Python megawidgets and Tkinter3000 WCK
http://hg.python.org/cpython/rev/2111bf7e5bca

New changeset f0008683585c by Antoine Pitrou in branch 'default':
Issue #13527: remove mention of Python megawidgets and Tkinter3000 WCK
http://hg.python.org/cpython/rev/f0008683585c

New changeset 478b4e9551fa by Antoine Pitrou in branch '2.7':
Issue #13527: remove mention of Python megawidgets and Tkinter3000 WCK
http://hg.python.org/cpython/rev/478b4e9551fa

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Dec  5 00:14:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 23:14:26 +0000
Subject: [issue13527] Remove obsolete mentions in the GUIs page
In-Reply-To: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>
Message-ID: <1323040466.36.0.3203719994.issue13527@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Dec  5 00:59:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2011 23:59:55 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1323043195.99.0.961415330261.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
hgrepos:  -93

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

From report at bugs.python.org  Mon Dec  5 01:00:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2011 00:00:09 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1323043209.6.0.477184039243.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
hgrepos: +94

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

From report at bugs.python.org  Mon Dec  5 01:00:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2011 00:00:50 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1323043250.55.0.686654916879.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file23853/5ce60675e572.diff

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

From report at bugs.python.org  Mon Dec  5 01:05:30 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2011 00:05:30 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1323043530.1.0.842169038623.issue11816@psf.upfronthosting.co.za>


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

MvL pointed out I hadn't updated the Hg repo reference when I moved my sandbox over to BitBucket - the diff it was generating was from the last time I updated my pydotorg sandbox in order to try something on the buildbots.

----------

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

From report at bugs.python.org  Mon Dec  5 04:03:41 2011
From: report at bugs.python.org (James Polley)
Date: Mon, 05 Dec 2011 03:03:41 +0000
Subject: [issue5364] documentation in epub format
In-Reply-To: <1235557178.12.0.454366670328.issue5364@psf.upfronthosting.co.za>
Message-ID: <1323054221.08.0.807333632706.issue5364@psf.upfronthosting.co.za>


James Polley <jamezpolley at gmail.com> added the comment:

So http://bitbucket.org/birkenfeld/sphinx/issue/140/ has now been closed; sphinx happily builds epub.

However, the python docs are still not available for download in epub format from http://docs.python.org/download.html, which was the original request in this issue.

----------
nosy: +James.Polley

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

From report at bugs.python.org  Mon Dec  5 04:26:58 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 05 Dec 2011 03:26:58 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
Message-ID: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

The docs for os.lseek don't make any mention of its return value.  I believe it's the new offset in the file, but I'm not sure if there are other subtleties to be mentioned.

----------
assignee: docs at python
components: Documentation
messages: 148861
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: Docs for os.lseek neglect to mention what it returns
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Dec  5 05:48:55 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Mon, 05 Dec 2011 04:48:55 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
In-Reply-To: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>
Message-ID: <1323060535.75.0.611733955496.issue13506@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

At first I did no see the difference on preserving the existing correct behavior and fixing the issue between the two patches... and I thought less is more, so mine was better...

But, I checked again and by:
"... running a python script will have sys.path include the absolute path to the script..." (Roger meant) instead of CWD ("").

I can see the reasoning for it and since that IS the standard Python behavior it should be also transposed to IDLE.

So yes, Roger (serwy) patch presents a more accurate correction.

+1

----------

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

From report at bugs.python.org  Mon Dec  5 08:27:55 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 05 Dec 2011 07:27:55 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1323070075.83.0.072985175067.issue13530@psf.upfronthosting.co.za>


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

The only subtlety is that the result is the offset from the beginning, independent of the how value. It may also raise exceptions.

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Dec  5 08:35:40 2011
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 05 Dec 2011 07:35:40 +0000
Subject: [issue13495] IDLE: Regression - Two ColorDelegator instances loaded
In-Reply-To: <1322510218.36.0.927250562508.issue13495@psf.upfronthosting.co.za>
Message-ID: <1323070540.41.0.197598283111.issue13495@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I attached a better patch that preserves the goals of the original code while not creating two color delegators.

I traced down when the regression occurred (2007-09-06):
(a4bd8a4805a8) 1. Fail gracefully if the file fails to decode when loaded.

This patch (2008-02-16) modified parts of the last patch, as well adds "ResetColorizer" to the filename_change_hook.
(7c4c46342137) Merged revisions 60481,60485,60489-60492,60494-60496,60498-60499,60501-60503,605

----------
nosy: +christian.heimes, kbk -ned.deily
Added file: http://bugs.python.org/file23854/issue13495.patch

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

From report at bugs.python.org  Mon Dec  5 09:36:59 2011
From: report at bugs.python.org (James Polley)
Date: Mon, 05 Dec 2011 08:36:59 +0000
Subject: [issue5364] documentation in epub format
In-Reply-To: <1235557178.12.0.454366670328.issue5364@psf.upfronthosting.co.za>
Message-ID: <1323074219.34.0.825133687007.issue5364@psf.upfronthosting.co.za>


James Polley <jamezpolley at gmail.com> added the comment:

It looks like the first release that had epub support was 1.0; docs.python.org is still using 0.6.7, according to the footer on the bottom of the page.

I suspect that this is (A) pending the upgrade to 1.0.0, which is (B) more difficult than it sounds like, or at least, needs someone to make a concerted effort, and (C) should automatically just happen (or at least, be fairly trivial) once the move to the new version happens.

----------

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

From report at bugs.python.org  Mon Dec  5 10:14:21 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 05 Dec 2011 09:14:21 +0000
Subject: [issue5364] documentation in epub format
In-Reply-To: <1235557178.12.0.454366670328.issue5364@psf.upfronthosting.co.za>
Message-ID: <1323076461.97.0.955349163817.issue5364@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello James,
please note that EPUB is already available for Python 3 documentation: http://docs.python.org/py3k/download.html . We will probably make it available also for 2.7 when I'll find the time to work on upgrading sphinx on 2.7 branch.

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Mon Dec  5 12:21:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Dec 2011 11:21:16 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1323084076.45.0.999176850561.issue13443@psf.upfronthosting.co.za>


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

This section has been removed from the 3.x docs in 3828f81a64e7 and 2aeef275bec8, but it's still there in 2.7.

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

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

From report at bugs.python.org  Mon Dec  5 12:55:23 2011
From: report at bugs.python.org (mike c)
Date: Mon, 05 Dec 2011 11:55:23 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
Message-ID: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>


New submission from mike c <coolbutuseless at gmail.com>:

Could a test be added to ./Lib/test/test_defaultdict.py to test for TypeError being thrown when the the first argument to collections.defaultdict is not callable?  

pypy does not behave the same way as CPython 2.7.2 as the problem is not covered in the testcases.

e.g.
def test_callable_arg:
    d1 = defaultdict({})
    self.assertRaises(TypeError)  # TypeError: first argument must be callable

----------
components: Tests
messages: 148868
nosy: mike.c
priority: normal
severity: normal
status: open
title: add test for defaultdict with non-callable first argument
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec  5 12:57:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Dec 2011 11:57:40 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
In-Reply-To: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>
Message-ID: <1323086260.75.0.826471308702.issue13531@psf.upfronthosting.co.za>


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

Sure, do you want to propose a patch?  (You can see the devguide for more information.)

----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> test needed
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Dec  5 13:11:30 2011
From: report at bugs.python.org (mike c)
Date: Mon, 05 Dec 2011 12:11:30 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
In-Reply-To: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>
Message-ID: <1323087090.26.0.987444370801.issue13531@psf.upfronthosting.co.za>


mike c <coolbutuseless at gmail.com> added the comment:

Cloning repo. Reading the devguide.  Patch forthcoming.

----------

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

From report at bugs.python.org  Mon Dec  5 14:16:31 2011
From: report at bugs.python.org (mike c)
Date: Mon, 05 Dec 2011 13:16:31 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
In-Reply-To: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>
Message-ID: <1323090991.37.0.37695775572.issue13531@psf.upfronthosting.co.za>


mike c <coolbutuseless at gmail.com> added the comment:

Patch to add a defaultdict test which checks that if the first argument is not callable, then a TypeError is thrown.

----------
keywords: +patch
Added file: http://bugs.python.org/file23855/defaultdict_callable_test.patch

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

From report at bugs.python.org  Mon Dec  5 14:29:57 2011
From: report at bugs.python.org (mike c)
Date: Mon, 05 Dec 2011 13:29:57 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
In-Reply-To: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>
Message-ID: <1323091797.31.0.96852895575.issue13531@psf.upfronthosting.co.za>


mike c <coolbutuseless at gmail.com> added the comment:

patch v2. Now with assertRaises()!

----------
Added file: http://bugs.python.org/file23856/defaultdict_callable_test_v2.patch

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

From report at bugs.python.org  Mon Dec  5 15:07:43 2011
From: report at bugs.python.org (maniram maniram)
Date: Mon, 05 Dec 2011 14:07:43 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
Message-ID: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

In IDLE, sys.stdout.write and sys.stderr can write any pickleable object such as 100 when they should only allow strings.
IDLE seems to be pickling the object.
>>> import sys
>>> sys.stdout.write(100)
100
>>> sys.stdout.write(sys)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    sys.stdout.write(sys)
_pickle.PicklingError: Can't pickle <class 'module'>: attribute lookup builtins.module failed
The error above is more detailed in IDLE 2.7.
While in Python on the command-line:
>>> import sys
>>> sys.stdout.write(100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str, not int
>>> 
The error above in Python 2.7:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected a character buffer object

----------
components: IDLE
messages: 148873
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: In IDLE, sys.stdout.write and sys.stderr can write any pickleable object
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Dec  5 16:01:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Dec 2011 15:01:05 +0000
Subject: [issue12944] Accept arbitrary files for packaging's upload command
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1323097265.98.0.781375563549.issue12944@psf.upfronthosting.co.za>


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

Someone from the mentoring project has volunteered to work on a patch.

----------

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

From report at bugs.python.org  Mon Dec  5 16:36:35 2011
From: report at bugs.python.org (dangermouseb)
Date: Mon, 05 Dec 2011 15:36:35 +0000
Subject: [issue13533] Would like Py_Initialize to play friendly with host app
Message-ID: <1323099394.97.0.36914155274.issue13533@psf.upfronthosting.co.za>


New submission from dangermouseb <david at bigredmedia.tv>:

I'm building a dll add-in (on Windows) in which I want to use the installed version of Python, not provide my own installation. When py_initialize fails it appears to call exit(). This doesn't seem very friendly behaviour for an embeddable scripting language as the host application is terminated (out of my control).

So my request is that either py_initialize is changed to return a code indicating failure or sucess or another function is added to th api to test if the installation is good or not. That way I can report to the user that there is a problem in the python installation rather than apparently crashing the host app.

Currently the only strategy I've thought of to get around this is to fork a seperate process, and inspect it after a delay to see if it is running (indicating that py_initialize hasn't failed), terminate the new process and then call py_initialize in the host application process.

This has been raised before but only in terms of consistency with the documentation, not about if a embeddable scripting engine should terminate the hosting process without regard to that host.

Many thanks,

David

----------
components: None
messages: 148875
nosy: dangermouseb
priority: normal
severity: normal
status: open
title: Would like Py_Initialize to play friendly with host app
type: feature request
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Dec  5 16:50:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Dec 2011 15:50:27 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1323100227.0.0.200534162018.issue13491@psf.upfronthosting.co.za>


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

The updated patch looks good, I?ll commit it soon.

----------

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

From report at bugs.python.org  Mon Dec  5 16:51:40 2011
From: report at bugs.python.org (Tim Golden)
Date: Mon, 05 Dec 2011 15:51:40 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <4EDB4E59.7000207@timgolden.me.uk>
Message-ID: <4EDCE888.5040707@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

After a discussion on python-dev:

   http://mail.python.org/pipermail/python-dev/2011-December/114733.html

I propose to close this call tomorrow as wontfix

----------

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

From report at bugs.python.org  Mon Dec  5 16:59:36 2011
From: report at bugs.python.org (Nebelhom)
Date: Mon, 05 Dec 2011 15:59:36 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1323100227.0.0.200534162018.issue13491@psf.upfronthosting.co.za>
Message-ID: <CAHw0e=uS13q8Jz7MSD2PD2LuVGj1tnP8M+QirWvY+55qoXcSUQ@mail.gmail.com>


Nebelhom <nebelhom at googlemail.com> added the comment:

Hi,

thanks for your help and support, mate.

Unfortunately, no word about the createdb.py business (the last bullet
point on the list) and whether it should be referred to in the doc. Should
we just drop this from the adjustments?

Thanks.

Johannes

P.S. Any suggestions where to look in the doc next until your packaging
patch is ready for reviewing?

On Mon, Dec 5, 2011 at 4:50 PM, ?ric Araujo <report at bugs.python.org> wrote:

>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> The updated patch looks good, I?ll commit it soon.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13491>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Dec  5 17:17:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Dec 2011 16:17:41 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1323101861.35.0.871726082936.issue13491@psf.upfronthosting.co.za>


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

> Unfortunately, no word about the createdb.py business (the last bullet point on the list)
> and whether it should be referred to in the doc.
If you make the whitespace more standard, use the tempfile module (to remove the os.remove line) and use with statements, the file is actually very short (so my earlier hypothesis about createdb was wrong :).

I think we could inline it (with a literalinclude directive) or link to it (with :source:`Doc/include/sqlite3/createdb.py`).  Add something like ?If you want to run these examples, run this code to create and populate the initial database? and we?re set.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Dec  5 18:12:44 2011
From: report at bugs.python.org (Sivan Greenberg)
Date: Mon, 05 Dec 2011 17:12:44 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1323105164.98.0.663972774035.issue1685453@psf.upfronthosting.co.za>


Sivan Greenberg <sivang at gmail.com> added the comment:

I am having hard time parsing all the text/html and text/plain parts of a message, concatenating them into a string. I am thinking of writing some custom code to do manual handling of this...

If this could be fixed that would be great. The issues are converting from and to ascii/unicode or whatever encoding/charset the part uses.

----------
nosy: +sivang

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

From report at bugs.python.org  Mon Dec  5 19:06:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Dec 2011 18:06:08 +0000
Subject: [issue13533] Would like Py_Initialize to play friendly with host app
In-Reply-To: <1323099394.97.0.36914155274.issue13533@psf.upfronthosting.co.za>
Message-ID: <1323108368.32.0.510104541924.issue13533@psf.upfronthosting.co.za>


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

If we add a (yet another) variant of Py_Initialize, I would suggest we make it extensible by passing it a struct of arguments (so that the struct can be augmented without breaking compatibility).

----------
components: +Interpreter Core -None
nosy: +pitrou
versions: +Python 3.3 -Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Dec  5 19:14:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2011 18:14:12 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1323108852.88.0.538291818569.issue1685453@psf.upfronthosting.co.za>


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

That particular problem will get fixed in the next version of the email package (hopefully in Python3.3), but that isn't ready yet.

----------

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

From report at bugs.python.org  Mon Dec  5 19:25:51 2011
From: report at bugs.python.org (Darren Dale)
Date: Mon, 05 Dec 2011 18:25:51 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1323109551.02.0.0696529453473.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Patch addressing latest comments in review. Notable change: defines _PyObject_IsAbstract in object.c/object.h, rather than repeating the code in multiple files and functions.

----------
Added file: http://bugs.python.org/file23857/abc_descriptor.patch

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

From report at bugs.python.org  Mon Dec  5 19:32:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 05 Dec 2011 18:32:51 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323109971.98.0.429467954073.issue11051@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a trivial patch reducing the number of calls to open.
before:
"""
$ strace -c -e open ./python -c ""
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000049           0       392       306 open
------ ----------- ----------- --------- --------- ----------------
100.00    0.000049                   392       306 total
"""
after:
"""
$ strace -c -e open ./python -c ""
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000024           0        86           open
------ ----------- ----------- --------- --------- ----------------
100.00    0.000024                    86           total
"""

As for the flury of tentative locations, I don't feel like modifying this since I'm not familiar enough with the import machinery.

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file23858/import_stat.diff

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

From report at bugs.python.org  Mon Dec  5 20:45:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2011 19:45:49 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <E1RXeU0-0001bb-69@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e2959a6a1440 by Antoine Pitrou in branch 'default':
Issue #13503: Use a more efficient reduction format for bytearrays with
http://hg.python.org/cpython/rev/e2959a6a1440

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Dec  5 20:46:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Dec 2011 19:46:46 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1323114406.98.0.932858120102.issue13503@psf.upfronthosting.co.za>


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

The patch wasn't entirely PEP 7-compliant (spaces around operators, space after if), but I've fixed that when committing. Thank you!

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

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

From report at bugs.python.org  Mon Dec  5 21:12:08 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 05 Dec 2011 20:12:08 +0000
Subject: [issue13533] Would like Py_Initialize to play friendly with host app
In-Reply-To: <1323099394.97.0.36914155274.issue13533@psf.upfronthosting.co.za>
Message-ID: <1323115928.98.0.287757396718.issue13533@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Mon Dec  5 21:37:31 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 05 Dec 2011 20:37:31 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323117451.04.0.300866118864.issue11051@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Mon Dec  5 21:54:18 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Dec 2011 20:54:18 +0000
Subject: [issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument,
	effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <1323118458.19.0.139706440986.issue11147@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Confirmed, and this is really annoying.  I'm of the mind to apply your second idea.

----------
nosy: +barry

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

From report at bugs.python.org  Mon Dec  5 21:56:26 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Dec 2011 20:56:26 +0000
Subject: [issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument,
	effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <1323118586.93.0.62899384104.issue11147@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Sorry, I meant your first option.

----------

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

From report at bugs.python.org  Mon Dec  5 22:27:49 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 05 Dec 2011 21:27:49 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1323120469.59.0.697038972529.issue13532@psf.upfronthosting.co.za>


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

Why do you think this is a bug? Is this behavior causing problems?

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Dec  5 22:42:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 05 Dec 2011 21:42:50 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323121370.59.0.00570445000435.issue11051@psf.upfronthosting.co.za>


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

> First, I don't understand why we need to check both "foo.so" and
> "foomodule.so".

Because we always did, i.e. changing it now may break backwards compatibility. Now, as for why we always had *module.so also: it may be that calling an extension module foo.so might not be feasible if it needs to link with a system library called foo.so (rather than libfoo.so). 

I don't know how serious this problem is in practice - we may consider deprecating-then-removing *module.so from the import machinery.

As for checking both "foo.so" and "foo.cpython-32m.so": that's for backwards compatibility also. Existing build processes may produce foo.so, as they did in previous Python versions (in particular, if they are not based on distutils, but, say, make). Unfortunately, PEP 3149 did not specify a deprecation scheduling. You could ask Barry - I suppose that was an oversight, and not actually deliberate.

Of course, with .cpython-32m.so being present, removing *module.so would be easy enough, except again for breaking existing projects which might use that name.

----------

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

From report at bugs.python.org  Mon Dec  5 22:50:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2011 21:50:51 +0000
Subject: [issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument,
	effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <E1RXgQz-0004yF-FG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4579cd952156 by Barry Warsaw in branch '3.2':
- Issue #11147: Fix an unused argument in _Py_ANNOTATE_MEMORY_ORDER.  (Fix
http://hg.python.org/cpython/rev/4579cd952156

New changeset 6b6c79eba944 by Barry Warsaw in branch 'default':
- Issue #11147: Fix an unused argument in _Py_ANNOTATE_MEMORY_ORDER.  (Fix
http://hg.python.org/cpython/rev/6b6c79eba944

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Dec  5 22:51:26 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Dec 2011 21:51:26 +0000
Subject: [issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument,
	effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <1323121886.83.0.302836416939.issue11147@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

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

From report at bugs.python.org  Mon Dec  5 23:06:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2011 22:06:15 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1323122775.97.0.123320186581.issue11886@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Alex ? Florent ?

----------

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

From report at bugs.python.org  Tue Dec  6 00:24:21 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 05 Dec 2011 23:24:21 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to
	optimized architecture-specific "hypot"
Message-ID: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>


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

On ppc64, on this box, with glibc-2.14.90-19.ppc64, test_cmath fails with:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 352,
in test_specific_values
    msg=error_message)
  File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 112,
in rAssertAlmostEqual
    '{!r} and {!r} are not sufficiently close'.format(a, b))
AssertionError: acos0200: acos(complex(1.620686051868302e+308,
1.0308426226285283e+308))
Expected: complex(0.5665082609382622, -710.5420687424156)
Received: complex(0.5665082609382622, -inf)
Received value insufficiently close to expected value.

It turns out (after much debugging) that libm in this version of glibc has an architecture-specific implementation of hypot(3) which returns inf in many of the test cases in tests/cmath_testcases.txt, when the non-architecture-specific implementation returns large finite values.

See downstream bug in Fedora's bug tracker:
  https://bugzilla.redhat.com/show_bug.cgi?id=750811
for more details.

Seen with the Python 2.7.2 tarball, but the code doesn't appear to have changed in hg in either the default or the 2.7 branches.

I will also file a bug in glibc's bug tracker about this.

----------
components: Tests
messages: 148893
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: test_cmath fails on ppc with glibc-2.14.90 due to optimized architecture-specific "hypot"
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  6 00:37:37 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 05 Dec 2011 23:37:37 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to
	optimized architecture-specific "hypot"
In-Reply-To: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>
Message-ID: <1323128257.99.0.559880392884.issue13534@psf.upfronthosting.co.za>


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

Reported in glibc's bug tracker as:
  http://sourceware.org/bugzilla/show_bug.cgi?id=13472

----------

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

From report at bugs.python.org  Tue Dec  6 01:33:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 00:33:43 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323131623.2.0.376530985288.issue11051@psf.upfronthosting.co.za>


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

> Here's a trivial patch reducing the number of calls to open.

Looks good to me.

----------

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

From report at bugs.python.org  Tue Dec  6 01:49:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 00:49:34 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
Message-ID: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>


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

This RFE proposes two new methods "to_signed" and "to_unsigned" on 'int' objects and on the numbers.Integral ABC.

Semantics (and number.Integral implementation):

def to_unsigned(self, bits):
  "Convert this integer to its unsigned two's complement equivalent for the given bit length"
  if self.bit_length() >= bits:
       raise ValueError("{} is too large for {}-bit two's complement
precision".format(self, bits))
  if self >= 0:
       return self
  return 2**bits + self # self is known to be negative at this point

def to_signed(self, bits):
  "Convert an integer in two's complement format to its signed equivalent for the given bit length"
  if self < 0:
       raise ValueError("{} is already signed".format(self))
  if self.bit_length() > bits:
       raise ValueError("{} is too large for {}-bit two's complement
precision".format(self, bits))
  upper_bound = 2**bits
  if self < (upper_bound / 2):
     return self
  return upper_bound - self

To add these methods to numbers.Integral, a concrete numbers.Integral.bit_length() operation will also be needed. This can be implemented simply as:

def bit_length(self):
    return int(self).bit_length()

(Initial concept from this python-ideas thread: http://mail.python.org/pipermail/python-ideas/2011-December/012989.html)

----------
components: Interpreter Core, Library (Lib)
messages: 148896
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Improved two's complement arithmetic support: to_signed() and to_unsigned()
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec  6 01:54:40 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 06 Dec 2011 00:54:40 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323132880.41.0.230069413186.issue13535@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Dec  6 02:02:40 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 06 Dec 2011 01:02:40 +0000
Subject: [issue13536] ast.literal_eval fails on sets
Message-ID: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

In 2.7 ast.literal_eval blows up with a set for input:


>>> import ast
>>> ast.literal_eval("{1}")

----------
messages: 148897
nosy: alex
priority: low
severity: normal
status: open
title: ast.literal_eval fails on sets
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  6 02:05:24 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 06 Dec 2011 01:05:24 +0000
Subject: [issue13536] ast.literal_eval fails on sets
In-Reply-To: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>
Message-ID: <1323133524.6.0.773497955705.issue13536@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Patch with tests

----------
keywords: +patch
Added file: http://bugs.python.org/file23859/x.diff

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

From report at bugs.python.org  Tue Dec  6 02:08:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 01:08:58 +0000
Subject: [issue13536] ast.literal_eval fails on sets
In-Reply-To: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>
Message-ID: <1323133738.55.0.728307399085.issue13536@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan

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

From report at bugs.python.org  Tue Dec  6 02:14:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 06 Dec 2011 01:14:48 +0000
Subject: [issue13536] ast.literal_eval fails on sets
In-Reply-To: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>
Message-ID: <1323134088.38.0.54189322415.issue13536@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I don't profess to have any special ast knowledge, but given the context around there and the fact that it works...it looks fine to me.

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

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

From report at bugs.python.org  Tue Dec  6 02:26:22 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 06 Dec 2011 01:26:22 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323134782.2.0.487696144785.issue13535@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Tue Dec  6 02:29:20 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 01:29:20 +0000
Subject: [issue13536] ast.literal_eval fails on sets
In-Reply-To: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>
Message-ID: <1323134960.33.0.679080553573.issue13536@psf.upfronthosting.co.za>


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

Dict and Set comprehensions are also broken:

>>> {1 for x in ()}
set([])
>>> {1:2 for x in ()}
{}
>>> ast.literal_eval("{1 for x in ()}")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/ast.py", line 80, in literal_eval
    return _convert(node_or_string)
  File "/usr/lib64/python2.7/ast.py", line 79, in _convert
    raise ValueError('malformed string')
ValueError: malformed string
>>> ast.literal_eval("{1:2 for x in ()}")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/ast.py", line 80, in literal_eval
    return _convert(node_or_string)
  File "/usr/lib64/python2.7/ast.py", line 79, in _convert
    raise ValueError('malformed string')
ValueError: malformed string

----------

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

From report at bugs.python.org  Tue Dec  6 02:32:13 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 06 Dec 2011 01:32:13 +0000
Subject: [issue13536] ast.literal_eval fails on sets
In-Reply-To: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>
Message-ID: <1323135133.1.0.295829022435.issue13536@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

There's no support for comprehensions of any sort, and confusingly limited support for arithmetic ops, I'd like to keep the scope of this issue small, basically backporting 90bf0631bfb8 and adding the tests (which I can also add to default).

----------

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

From report at bugs.python.org  Tue Dec  6 02:47:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 06 Dec 2011 01:47:59 +0000
Subject: [issue13536] ast.literal_eval fails on sets
In-Reply-To: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>
Message-ID: <1323136079.8.0.350138166364.issue13536@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
status: open -> closed
superseder:  -> ast.literal_eval does not handled new set literals

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

From report at bugs.python.org  Tue Dec  6 03:17:21 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 06 Dec 2011 02:17:21 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1323137841.42.0.0421508191595.issue13503@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Antoine, do we have unit tests for this code path?

----------

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

From report at bugs.python.org  Tue Dec  6 03:36:53 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 06 Dec 2011 02:36:53 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>
Message-ID: <1323139013.33.0.56988253806.issue13520@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

This might not be the case anymore, but __module__ can sometime be None. There is some discussion about this in Issue 3657. We should define the expected behavior when this happens.

Also, I don't think backward-compatibility of the protocol is a big issue if we use the getattr approach. I feel bumping the protocol version is only necessary if we introduce new opcodes or change their interpretation.

----------

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

From report at bugs.python.org  Tue Dec  6 04:17:22 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 06 Dec 2011 03:17:22 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323141442.4.0.137143878614.issue13505@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I think we are kind of stuck here. I might need to rely on some clever hack to generate the desired str object in 2.7 without breaking the bytes support in 3.3 and without changing 2.7 itself.

One *dirty* trick I am thinking about would be to use something like array.tostring() to construct the byte string.

    from array import array

    class bytes:
        def __reduce__(self):
            return (array.tostring, (array('B', self),))

Of course, this doesn't work because pickle doesn't method pickling. But, maybe someone can figure out a way around this... I don't know.

Also, this is a bit annoying to fix since we changed the semantic meaning of the STRING opcodes in 3.x---i.e., it now represents a unicode string instead of a byte string.

----------

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

From report at bugs.python.org  Tue Dec  6 04:35:11 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 06 Dec 2011 03:35:11 +0000
Subject: [issue3635] pickle.dumps cannot save instance of dict-derived class
	that overrides __getattribute__
In-Reply-To: <1219346500.78.0.74794831892.issue3635@psf.upfronthosting.co.za>
Message-ID: <1323142511.44.0.28711324845.issue3635@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I don't think it is a bug.

The posted code completely breaks the expected behavior of __getattribute__. With a such implementation, there is nothing we can do with this object as we cannot introspect it.

Use the following if you really need this kind of behaviour:

class E(dict):
    def __getattribute__(self,name):
        try:
            return self[name]
        except KeyError:
            return dict.__getattribute__(self, name)

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Tue Dec  6 05:24:39 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Tue, 06 Dec 2011 04:24:39 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1323145479.04.0.182240909838.issue2057@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

I agree with Anatoly that it should be an easy way to create and apply Unified Diff Patches within Python. Also issue 2142 should get fixed, as proposed, but also include the fix at least on 2.7 not only on 3.x

----------
nosy: +marco

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

From report at bugs.python.org  Tue Dec  6 06:00:55 2011
From: report at bugs.python.org (maniram maniram)
Date: Tue, 06 Dec 2011 05:00:55 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1323147655.0.0.333966468124.issue13532@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

It is different behaviour than usual.
I agree it is of low importance.

----------

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

From report at bugs.python.org  Tue Dec  6 07:01:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Dec 2011 06:01:25 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1323151285.53.0.440029579571.issue13530@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Tue Dec  6 08:31:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 07:31:10 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1323156670.8.0.4308450574.issue11610@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23819/abc_descriptor.patch

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

From report at bugs.python.org  Tue Dec  6 08:31:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 07:31:17 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1323156677.74.0.495698111482.issue11610@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file22729/abc_descriptor.patch

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

From report at bugs.python.org  Tue Dec  6 08:31:20 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 07:31:20 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1323156680.17.0.514085906866.issue11610@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file22407/abc_descriptor.patch

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

From report at bugs.python.org  Tue Dec  6 10:45:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 09:45:22 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1323164722.27.0.174384714291.issue11610@psf.upfronthosting.co.za>


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

Added some review comments in Reitveld - core functionality changes look good, but there are some other aspects that need addressing before the patch will be good to go (primarily relating to only doing a minimal documented deprecation of the legacy APIs without actually harming their documentation, testing or functionality).

----------

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

From report at bugs.python.org  Tue Dec  6 10:58:09 2011
From: report at bugs.python.org (Tim Golden)
Date: Tue, 06 Dec 2011 09:58:09 +0000
Subject: [issue13524] critical error with import tempfile
In-Reply-To: <1322914823.87.0.666849629429.issue13524@psf.upfronthosting.co.za>
Message-ID: <1323165489.31.0.214883471356.issue13524@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


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

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

From report at bugs.python.org  Tue Dec  6 11:38:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 10:38:59 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323167939.03.0.110784129797.issue13535@psf.upfronthosting.co.za>


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

Instead of requiring bit_length(), couldn't you simply compare self to 2**(bits-1) (for to_unsigned) and 2**bits (for to_signed)?

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

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

From report at bugs.python.org  Tue Dec  6 12:52:14 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 06 Dec 2011 11:52:14 +0000
Subject: [issue13536] ast.literal_eval fails on sets
In-Reply-To: <1323133360.31.0.331405139525.issue13536@psf.upfronthosting.co.za>
Message-ID: <1323172334.17.0.390145417384.issue13536@psf.upfronthosting.co.za>


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

Alex: IMO the operator support is only required for complex "literals".

----------

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

From report at bugs.python.org  Tue Dec  6 13:25:47 2011
From: report at bugs.python.org (sbt)
Date: Tue, 06 Dec 2011 12:25:47 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323174347.71.0.565108110534.issue13505@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> One *dirty* trick I am thinking about would be to use something like 
> array.tostring() to construct the byte string.

array('B', ...) objects are pickled using two bytes per character, so there would be no advantage:

  >>> pickle.dumps(array.array('B', b"hello"), 2)
  b'\x80\x02carray\narray\nq\x00X\x01\x00\x00\x00Bq\x01]q\x02(KhKeKlKlKoe\x86q\x03Rq\x04.'

----------
nosy: +sbt

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

From report at bugs.python.org  Tue Dec  6 13:28:22 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Tue, 06 Dec 2011 12:28:22 +0000
Subject: [issue13537] Namedtuple instances can't be pickled in a daemonized
	process
Message-ID: <1323174502.67.0.202903753382.issue13537@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

On Unix world, in a daemonized process, any namedtuple instance can't be pickled, failing with error:
_pickle.PicklingError: Can't pickle class X: attribute lookup __main__.t failed.
This can't be reproduced with the attached code. If I add the created class inside the globals dict, the pickling will work.

----------
components: Library (Lib)
files: daemon.py
messages: 148912
nosy: Popa.Claudiu, rhettinger
priority: normal
severity: normal
status: open
title: Namedtuple instances can't be pickled in a daemonized process
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23860/daemon.py

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

From report at bugs.python.org  Tue Dec  6 13:35:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 12:35:42 +0000
Subject: [issue13537] Namedtuple instances can't be pickled in a daemonized
	process
In-Reply-To: <1323174502.67.0.202903753382.issue13537@psf.upfronthosting.co.za>
Message-ID: <1323174942.91.0.949399475235.issue13537@psf.upfronthosting.co.za>


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

As far as I can tell, this has nothing to do with daemon processes and all to do with the fact that user-defined classes have to be globally visible for their instances to be pickled. It is because pickles reference classes by name, and local names obviously don't work for that.

In other words, this is not a bug.

----------
nosy: +alexandre.vassalotti, pitrou
resolution:  -> invalid
status: open -> pending
versions:  -Python 3.4

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

From report at bugs.python.org  Tue Dec  6 13:56:42 2011
From: report at bugs.python.org (Guillaume Bouchard)
Date: Tue, 06 Dec 2011 12:56:42 +0000
Subject: [issue13538] Docstring of str() and/or behavior
Message-ID: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>


New submission from Guillaume Bouchard <guillaum.bouchard at gmail.com>:

The docstring associated with str() says:

  str(string[, encoding[, errors]]) -> str
  
  Create a new string object from the given encoded string.
  encoding defaults to the current default string encoding.
  errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'.

When it is stated in the on-line documentation::

  When only object is given, this returns its nicely printable representation.

My issue comes when I tried to convert bytes to str.

As stated in the documentation, and to avoid implicit behavior, converting str to bytes cannot be done without giving an encoding (using bytes(my_str, encoding=..) or my_str.encode(...). bytes(my_str) will raise a TypeError). But if you try to convert bytes to str using str(my_bytes), python will returns you the so-called nicely printable representation of the bytes object).

ie. ::


  >>> bytes("foo")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: string argument without an encoding
  >>> str(b"foo")
  "b'foo'"

As a matter of coherency and to avoid silent errors, I suggest that str() of a byte object without encoding raise an exception. I think it is usually what people want. If one wants a *nicely printable representation* of their bytes object, they can call explicitly the repr() function and will quickly see that what they just printed is wrong. But if they want to convert a byte object to its unicode representation, they will prefer an exception rather than a silently failing converting which leads to an unicode string starting with 'b"' and ending with '"'.

----------
components: Interpreter Core
messages: 148914
nosy: Guillaume.Bouchard
priority: normal
severity: normal
status: open
title: Docstring of str() and/or behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Dec  6 14:07:51 2011
From: report at bugs.python.org (psam)
Date: Tue, 06 Dec 2011 13:07:51 +0000
Subject: [issue13539] A return is missing in TimeEncoding of calendar.py
Message-ID: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za>


New submission from psam <pk.samson at gmail.com>:

The v2.6 of __enter__() of TimeEncoding has been fixed in v2.7 in relation with the return of setlocale(), but for no apparent reason, its necessary returned value is no more there.

Patch:

    def __enter__(self):
        self.oldlocale = _locale.getlocale(_locale.LC_TIME)
        _locale.setlocale(_locale.LC_TIME, self.locale)
+       return _locale.getlocale(_locale.LC_TIME)[1]

----------
components: Library (Lib)
messages: 148915
nosy: psam
priority: normal
severity: normal
status: open
title: A return is missing in TimeEncoding of calendar.py
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  6 14:12:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Dec 2011 13:12:17 +0000
Subject: [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323177137.13.0.74081855.issue13538@psf.upfronthosting.co.za>


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

I agree with you that this is inconsistent.  However, having str raise an error is pretty much a non-starter as a suggestion.  str always falls back to the repr; in general str(obj) should always return some value, otherwise the assumptions of a *lot* of Python code would be broken.

Personally I'm not at all sure why str takes encoding and errors arguments (I never use them). I'd rather there be only one way to do that, decode.  In other words, why do we have special case support for byte strings in the str conversion function?

But I don't think that can be changed either, so I think we are stuck with documenting the existing situation better.  Do you want to propose a doc patch?

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, r.david.murray
versions: +Python 3.3

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

From report at bugs.python.org  Tue Dec  6 14:14:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 13:14:32 +0000
Subject: [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323177272.46.0.54919678862.issue13538@psf.upfronthosting.co.za>


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

> Personally I'm not at all sure why str takes encoding and errors
> arguments (I never use them).

Probably because the unicode type also did in 2.x.
And also because it makes it compatible with arbitrary buffer objects:

>>> str(memoryview(b"foo"), "ascii")
'foo'

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

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

From report at bugs.python.org  Tue Dec  6 14:56:41 2011
From: report at bugs.python.org (Guillaume Bouchard)
Date: Tue, 06 Dec 2011 13:56:41 +0000
Subject: [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323179801.38.0.915954488581.issue13538@psf.upfronthosting.co.za>


Guillaume Bouchard <guillaum.bouchard at gmail.com> added the comment:

> str always falls back to the repr; in general str(obj) should always return some value, otherwise the assumptions of a *lot* of Python code would be broken.

Perhaps it may raises a warning ?

ie, the only reason encoding exists if for the conversion of bytes (or something which looks like bytes) to str. Do you think it may be possible to special case the use of str for bytes (and bytesarray) with something like this:

def str(object, encoding=None, errors=None):
    if encoding is not None:
         # usual work
    else:
       if isinstance(object, (bytes, bytesarray)):
             warning('Converting bytes/bytesarray to str without encoding, it may not be what you expect')
             return object.__str__()

But by the way, adding warnings and special case everywhere seems not too pythonic.

> Do you want to propose a doc patch?

The docstring for str() should looks like something like, in my frenglish way of writing english ::

  Create a new string object from the given encoded string.

  If object is bytes, bytesarray or a buffer-like object, encoding and error
  can be set. errors can be 'strict', 'replace' or 'ignore' and defaults to
  'strict'.

  WARNING, if encoding is not set, the object is converted to a nicely
  printable representation, which is totally different from what you may expect.

Perhaps a warning may be added in the on-line documentation, such as ::

  .. warning::
     When str() converts a bytes/bytesarray or a buffer-like object and
     *encoding* is not specified, the result will an unicode nicely printable
     representation, which is totally different from the unicode representation of
     you object using a specified encoding.

Whould you like a .diff on top of the current mercurial repository ?

----------

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

From report at bugs.python.org  Tue Dec  6 15:30:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Dec 2011 14:30:26 +0000
Subject: [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323181826.87.0.685107739752.issue13538@psf.upfronthosting.co.za>


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

A diff would be great.

We try to use warnings sparingly, and I don't think this is a case that warrants it.  Possibly a .. note is worthwhile, perhaps with an example for the bytes case, but even that may be too much.

I also wouldn't use the wording "is totally different from what you would expect", since by now I do expect it :).  How about something like "the result will not be the decoded version of the bytes, but instead will be the repr of the object", with a cross link to repr.

----------

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

From report at bugs.python.org  Tue Dec  6 15:52:16 2011
From: report at bugs.python.org (sbt)
Date: Tue, 06 Dec 2011 14:52:16 +0000
Subject: [issue13520] Patch to make pickle aware of __qualname__
In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za>
Message-ID: <1323183136.39.0.753122084823.issue13520@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

It looks like Issue 3657 is really about builtin methods (i.e. builtin_function_or_method objects where __self__ is not a module).  It causes no problem for normal python instance methods.

If we tried the getattr approach for builtin methods too then it should only be used as a fallback when saving as a global will not work.

----------

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

From report at bugs.python.org  Tue Dec  6 15:56:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Dec 2011 14:56:35 +0000
Subject: [issue13540] Document the Action API
Message-ID: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>


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

In http://docs.python.org/dev/library/argparse.html#action, when describing an arbitrary action, the documentation states, "You can also specify an arbitrary action by passing an object that implements the Action API." This statement does not link to any documentation on the Action API and does not describe the API except to give an example.

Furthermore, the example contradicts the description. The description says "pass an object" but the example passes a class.

The documentation should clarify the text relating to the example and should document the expected interface for a custom action.

----------
assignee: docs at python
components: Documentation
messages: 148921
nosy: docs at python, jason.coombs
priority: low
severity: normal
status: open
title: Document the Action API
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Dec  6 15:57:00 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Dec 2011 14:57:00 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323183420.93.0.300363325473.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
title: Document the Action API -> Document the Action API in argparse

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

From report at bugs.python.org  Tue Dec  6 16:00:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 15:00:19 +0000
Subject: [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323183619.04.0.429338748952.issue13538@psf.upfronthosting.co.za>


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

Well, I forgot to mention it in my previous message, but there is already a warning that you can activate with the -b option:

$ ./python -b
Python 3.3.0a0 (default:6b6c79eba944, Dec  6 2011, 11:11:32) 
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b"")
__main__:1: BytesWarning: str() on a bytes instance
"b''"


And you can even turn it into an error with -bb:

$ ./python -bb
Python 3.3.0a0 (default:6b6c79eba944, Dec  6 2011, 11:11:32) 
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b"")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BytesWarning: str() on a bytes instance


However, -b is highly unlikely to become the default, for the reasons already explained. It was mainly meant to ease porting from Python 2.

----------

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

From report at bugs.python.org  Tue Dec  6 16:03:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Dec 2011 15:03:03 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1323183783.28.0.315037991186.issue2057@psf.upfronthosting.co.za>


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

Hi Marco, thanks for your interest in improving Python.  Do you want to propose a patch for this request?  If so, guidelines and help are found in the devguide.

(For the other bug, please read the discussion there to see why 2.7 is not possible.)

----------

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

From report at bugs.python.org  Tue Dec  6 16:12:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Dec 2011 15:12:49 +0000
Subject: [issue13408] Rename packaging.resources back to datafiles
In-Reply-To: <1321362147.83.0.710071986655.issue13408@psf.upfronthosting.co.za>
Message-ID: <1323184369.74.0.505101029628.issue13408@psf.upfronthosting.co.za>


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

MvL also thought the ?resources? term to be non-obvious: http://mail.python.org/pipermail/python-dev/2006-April/063966.html Other people mentioned its prior use within the Mac, the X system or Web frameworks.  Someone mentioned ?assets? in the game industry (also vague in my opinion).

One con for ?data? is that people may think it refers to files created by a program in the user home directory.

After reading this, I?m -0 rather than -1 on ?resources?, and +0.5 on ?data files?.  Whatever we decide, I strongly think all the code should use only one name (install_xxx command, dist.xxx attribute, dist-info/XXX file, etc.).

----------

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

From report at bugs.python.org  Tue Dec  6 16:32:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 15:32:55 +0000
Subject: [issue13408] Rename packaging.resources back to datafiles
In-Reply-To: <1321362147.83.0.710071986655.issue13408@psf.upfronthosting.co.za>
Message-ID: <1323185575.11.0.0271476360348.issue13408@psf.upfronthosting.co.za>


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

Sounds reasonable to me.

(is it normal that there's no online help for it:

$ ./python -m pydoc packaging.resources
no Python documentation found for 'packaging.resources'
)

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

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

From report at bugs.python.org  Tue Dec  6 16:37:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Dec 2011 15:37:08 +0000
Subject: =?utf-8?q?=5Bissue13408=5D_Rename_the_packaging_=E2=80=9Cresources?=
	=?utf-8?b?4oCdIGNvbmNlcHQgYmFjayB0byDigJxkYXRhIGZpbGVz4oCd?=
In-Reply-To: <1321362147.83.0.710071986655.issue13408@psf.upfronthosting.co.za>
Message-ID: <1323185828.26.0.157788612676.issue13408@psf.upfronthosting.co.za>


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

The resources subsystem has code in the install_data command, the p7g.database module and internal classes.  There used to be a p7g.resources module but it was merged into database because it contained only a few lines.

----------
title: Rename packaging.resources back to datafiles -> Rename the packaging ?resources? concept back to ?data files?

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

From report at bugs.python.org  Tue Dec  6 16:39:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Dec 2011 15:39:09 +0000
Subject: =?utf-8?q?=5Bissue13408=5D_Rename_the_packaging_=E2=80=9Cresources?=
	=?utf-8?b?4oCdIGNvbmNlcHQgYmFjayB0byDigJxkYXRhIGZpbGVz4oCd?=
In-Reply-To: <1321362147.83.0.710071986655.issue13408@psf.upfronthosting.co.za>
Message-ID: <1323185949.15.0.750079607142.issue13408@psf.upfronthosting.co.za>


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

Regarding reST docs, there?s a good bit in packaging/setupcfg and I have plans to explain it more (what it does, how it works with sysconfig.cfg, how it obsoletes package_data, how to use it and keep compat with distutils).

----------

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

From report at bugs.python.org  Tue Dec  6 17:44:59 2011
From: report at bugs.python.org (Peter)
Date: Tue, 06 Dec 2011 16:44:59 +0000
Subject: [issue13541] HTTPResponse (urllib) has no attribute read1 needed for
	TextIOWrapper
Message-ID: <1323189899.67.0.308842457665.issue13541@psf.upfronthosting.co.za>


New submission from Peter <p.j.a.cock at googlemail.com>:

Use case: I want to open an HTTP URL, and treat the handle as though it were opened in text mode (i.e. unicode strings not bytes).

$ python3
Python 3.2 (r32:88445, Feb 28 2011, 17:04:33) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> import urllib.request
>>> f_bytes = urllib.request.urlopen("http://www.python.org")
>>> for line in io.TextIOWrapper(f_bytes, "iso-8859-1"): print(line)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'HTTPResponse' object has no attribute 'read1'

See also Slide 122 of http://www.slideshare.net/dabeaz/mastering-python-3-io-version-2 which reports the same exception.

See also issue 5628 on a related issue, where Benjamin Peterson's issue 5628 message 84970 suggests double wrapping with BufferIOBase [sic] to solve this, but neither of the following works for me:

>>> f_bytes = urllib.request.urlopen("http://www.python.org")
>>> for line in io.TextIOWrapper(io.BufferedIOBase(f_bytes), "iso-8859-1"): print(line)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: not readable


>>> f_bytes = urllib.request.urlopen("http://www.python.org")
>>> for line in io.TextIOWrapper(io.BufferedReader(f_bytes), "iso-8859-1"): print(line)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'HTTPResponse' object has no attribute 'readinto'


Nor incidentally does this:


>>> f_bytes = urllib.request.urlopen("http://www.python.org")
>>> for line in io.BufferedReader(f_bytes): print(line)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'HTTPResponse' object has no attribute 'readinto'


See also issue 4996.

It is entirely possible I have simply failed to understand the proper way to do this, so at very least an example on the urllib documentation would be a welcome improvement. However it is my impression that the file-like object from urllib is not file-like enough.

----------
messages: 148928
nosy: maubp
priority: normal
severity: normal
status: open
title: HTTPResponse (urllib) has no attribute read1 needed for TextIOWrapper
versions: Python 3.2

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

From report at bugs.python.org  Tue Dec  6 20:18:09 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Dec 2011 19:18:09 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323199089.2.0.17962810082.issue13535@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/issue13535>
_______________________________________

From report at bugs.python.org  Tue Dec  6 20:24:50 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Dec 2011 19:24:50 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323199490.6.0.379850756991.issue13535@psf.upfronthosting.co.za>


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

The 'self.bit_length() >= bits' condition for to_unsigned doesn't look right to me.

E.g., if bits == 32, I'd expect the acceptable range of values to be range(-2**31, 2**31)---i.e., including -2**31, but excluding 2**31.  But the ValueError for 'self.bit_length() >= 32' means that -2**31 is excluded.

----------

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

From report at bugs.python.org  Tue Dec  6 20:35:55 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Dec 2011 19:35:55 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323200155.76.0.856361229351.issue13535@psf.upfronthosting.co.za>


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

On the feature request itself, I have to say that I'm unconvinced.  Doing x % (2**32) seems good enough to me, in situations where you don't need the bounds checking.  (And it's not clear to me that needing the bounds checks is the more common situation.)

----------

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

From report at bugs.python.org  Tue Dec  6 20:39:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 19:39:21 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323200155.76.0.856361229351.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323200044.4215.0.camel@localhost.localdomain>


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

> On the feature request itself, I have to say that I'm unconvinced.
> Doing x % (2**32) seems good enough to me, in situations where you
> don't need the bounds checking.

Ah, I didn't know that modulo worked for that. Nice trick.

----------

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

From report at bugs.python.org  Tue Dec  6 20:42:23 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Dec 2011 19:42:23 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to
	optimized architecture-specific "hypot"
In-Reply-To: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>
Message-ID: <1323200543.93.0.416032441706.issue13534@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/issue13534>
_______________________________________

From report at bugs.python.org  Tue Dec  6 20:47:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2011 19:47:48 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <E1RY0zS-0001Wc-D7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5910c385fab6 by Jesus Cea in branch '2.7':
Close #13500: Hitting EOF gets cmd.py into a infinite EOF on return loop
http://hg.python.org/cpython/rev/5910c385fab6

New changeset b6b4d74b8d42 by Jesus Cea in branch '3.2':
Close #13500: Hitting EOF gets cmd.py into a infinite EOF on return loop
http://hg.python.org/cpython/rev/b6b4d74b8d42

New changeset 70ba352f9586 by Jesus Cea in branch 'default':
MERGE: Close #13500: Hitting EOF gets cmd.py into a infinite EOF on return loop
http://hg.python.org/cpython/rev/70ba352f9586

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Dec  6 20:48:58 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 06 Dec 2011 19:48:58 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1323200938.94.0.490633131626.issue13500@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/issue13500>
_______________________________________

From report at bugs.python.org  Tue Dec  6 20:49:34 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 06 Dec 2011 19:49:34 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1323200974.59.0.658425676805.issue13500@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Garrett, please verify the fix.

----------

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

From report at bugs.python.org  Tue Dec  6 20:54:34 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Dec 2011 19:54:34 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to
	optimized architecture-specific "hypot"
In-Reply-To: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>
Message-ID: <1323201274.53.0.460567918937.issue13534@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.4

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

From report at bugs.python.org  Tue Dec  6 20:56:24 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 06 Dec 2011 19:56:24 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to buggy
	architecture-specific "hypot"
In-Reply-To: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>
Message-ID: <1323201384.83.0.47225894572.issue13534@psf.upfronthosting.co.za>


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

The glibc bug has been fixed in that project's git repo:
http://repo.or.cz/w/glibc.git/commit/850fb039cec802072f70ed9763927881bbbf639c

----------
title: test_cmath fails on ppc with glibc-2.14.90 due to optimized architecture-specific "hypot" -> test_cmath fails on ppc with glibc-2.14.90 due to buggy architecture-specific "hypot"

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

From report at bugs.python.org  Tue Dec  6 20:57:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 19:57:24 +0000
Subject: [issue13541] HTTPResponse (urllib) has no attribute read1 needed for
	TextIOWrapper
In-Reply-To: <1323189899.67.0.308842457665.issue13541@psf.upfronthosting.co.za>
Message-ID: <1323201444.42.0.711021475033.issue13541@psf.upfronthosting.co.za>


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

For the record, readinto is handled in issue 13464.

----------
components: +Library (Lib)
nosy: +pitrou
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Tue Dec  6 21:07:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Dec 2011 20:07:07 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
	to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1323202027.82.0.53664118729.issue13535@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/issue13535>
_______________________________________

From report at bugs.python.org  Tue Dec  6 21:08:49 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Dec 2011 20:08:49 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to buggy
	architecture-specific "hypot"
In-Reply-To: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>
Message-ID: <1323202129.93.0.374059805.issue13534@psf.upfronthosting.co.za>


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

Thanks for the report, and all the sleuthing.  It's always good to see Python's test suite expose C library (or C compiler) bugs. :-)

I propose closing this as 'won't fix':  I certainly wouldn't want to add workarounds in the cmath source (though in theory that would be possible).  I don't really think it's worth adding special cases to the test-suite, either.  What do you think?

----------

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

From report at bugs.python.org  Tue Dec  6 21:09:49 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Dec 2011 20:09:49 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to buggy
	architecture-specific "hypot"
In-Reply-To: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>
Message-ID: <1323202189.48.0.104911263489.issue13534@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/issue13534>
_______________________________________

From report at bugs.python.org  Tue Dec  6 21:28:30 2011
From: report at bugs.python.org (Yang Zhang)
Date: Tue, 06 Dec 2011 20:28:30 +0000
Subject: [issue13542] Memory leak in multiprocessing.pool
Message-ID: <1323203310.38.0.606183787821.issue13542@psf.upfronthosting.co.za>


New submission from Yang Zhang <yang.pythonbugs at mailnull.com>:

Calling Pool.map (and friends) on empty lists [] causes Pool._cache to hang on to the MapResults forever:

tp = ThreadPool(5)
xs = tp.map(lambda x: 'a' * int(10e6), range(100))
# now using 1GB mem = 100 * 10MB strs
del xs
gc.collect()
# still using 1GB mem
tp.close(); tp.join()
# now using ~0GB mem

----------
components: Library (Lib)
messages: 148937
nosy: yang
priority: normal
severity: normal
status: open
title: Memory leak in multiprocessing.pool
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  6 21:39:26 2011
From: report at bugs.python.org (Yang Zhang)
Date: Tue, 06 Dec 2011 20:39:26 +0000
Subject: [issue13542] Memory leak in multiprocessing.pool
In-Reply-To: <1323203310.38.0.606183787821.issue13542@psf.upfronthosting.co.za>
Message-ID: <1323203966.02.0.535782262145.issue13542@psf.upfronthosting.co.za>


Yang Zhang <yang.pythonbugs at mailnull.com> added the comment:

Oops, sorry - pasted a wrong example.


In [38]: tp = ThreadPool(5)

In [39]: xs = tp.map(lambda x: x, [])

In [40]: xs
Out[40]: []

In [41]: tp._cache
Out[41]: {3: <multiprocessing.pool.MapResult at 0x244ab50>}

----------

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

From report at bugs.python.org  Tue Dec  6 22:39:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2011 21:39:54 +0000
Subject: [issue13464] HTTPResponse is missing an implementation of readinto
In-Reply-To: <1322072062.06.0.738377139897.issue13464@psf.upfronthosting.co.za>
Message-ID: <E1RY2jx-000352-Bo@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 806cfe39f729 by Antoine Pitrou in branch 'default':
Issue #13464: Add a readinto() method to http.client.HTTPResponse.
http://hg.python.org/cpython/rev/806cfe39f729

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Dec  6 22:41:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 21:41:39 +0000
Subject: [issue13464] HTTPResponse is missing an implementation of readinto
In-Reply-To: <1322072062.06.0.738377139897.issue13464@psf.upfronthosting.co.za>
Message-ID: <1323207699.86.0.069325046594.issue13464@psf.upfronthosting.co.za>


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

Ok, thank you. I've now committed the patch in the default branch. Congratulations!

(since the documentation doesn't claim that HTTPResponse implements RawIOBase, I tend to consider this a feature request rather than a bugfix, hence no 3.2 commit)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> feature request
versions:  -Python 3.2

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

From report at bugs.python.org  Tue Dec  6 23:33:53 2011
From: report at bugs.python.org (ekorn)
Date: Tue, 06 Dec 2011 22:33:53 +0000
Subject: [issue13543] shlex with string ending in space gives "ValueError: No
	closing quotation"
Message-ID: <1323210833.77.0.155317327445.issue13543@psf.upfronthosting.co.za>


New submission from ekorn <jonovik at gmail.com>:

It seems shlex fails on processing strings ending in space, causing this bug that I reported for IPython:
https://github.com/ipython/ipython/issues/1109

Fernando Perez made a minimal example of the problem, quoted below. As he points out, it would be best to fix this at the source, namely the shlex module.

Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul  3 2011, 15:13:59) [MSC v.1500 32 bit (Intel)] on win32
>>> import shlex
>>> lex = shlex.shlex(' ("a ")', posix=False)
>>> lex.whitespace_split = True
>>> list(lex)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\shlex.py", line 269, in next
    token = self.get_token()
  File "C:\Python27\lib\shlex.py", line 96, in get_token
    raw = self.read_token()
  File "C:\Python27\lib\shlex.py", line 172, in read_token
    raise ValueError, "No closing quotation"
ValueError: No closing quotation

----------
components: Library (Lib)
messages: 148941
nosy: ekorn
priority: normal
severity: normal
status: open
title: shlex with string ending in space gives "ValueError: No closing quotation"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  6 23:53:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 06 Dec 2011 22:53:14 +0000
Subject: [issue13543] shlex with string ending in space gives "ValueError: No
	closing quotation"
In-Reply-To: <1323210833.77.0.155317327445.issue13543@psf.upfronthosting.co.za>
Message-ID: <1323211994.77.0.273691160563.issue13543@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> needs patch

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

From report at bugs.python.org  Tue Dec  6 23:55:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Dec 2011 22:55:54 +0000
Subject: [issue13543] shlex with string ending in space gives "ValueError: No
	closing quotation"
In-Reply-To: <1323210833.77.0.155317327445.issue13543@psf.upfronthosting.co.za>
Message-ID: <1323212154.76.0.665998715344.issue13543@psf.upfronthosting.co.za>


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

Why do you consider this to be a bug?  You set posix=False and whitespace_split=True, so it seems to me that according to the documented rules the " inside the word ("a is as documented not recognized as a quote character.  If you use either posix=True or whitespace_split=False the string parses without error.  (Since I have no idea what standard non-posix mode is based on, I have no idea whether or not this is in fact correct behavior, though.)

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed Dec  7 00:20:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 23:20:27 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
Message-ID: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>


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

functools.update_wrapper() and functools.wraps() should copy the new property by default.

----------
keywords: easy
messages: 148943
nosy: ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec  7 00:21:19 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 23:21:19 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1323213679.13.0.784790470471.issue12555@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority: normal -> release blocker

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

From report at bugs.python.org  Wed Dec  7 00:41:43 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 06 Dec 2011 23:41:43 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1323214903.04.0.78072292975.issue13390@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I looked at the 'ctypes' "leak" a bit.  I haven't determined exactly what
is going on, but the leak has something to do with a change in the patch that
runs 'dash_R_cleanup' twice instead of once.  The new behavior can be reduced
to something like:

   import sys, ctypes, gc

   ctypes._reset_cache()
   gc.collect()

   for i in range(0, 5):
       ctypes._reset_cache()
       gc.collect()
       print("%d: start refs = %s" % (i, sys.gettotalrefcount()))
       proto = ctypes.CFUNCTYPE(ctypes.POINTER(ctypes.c_char))
       ctypes._reset_cache()
       gc.collect()
       print("%d: after refs = %s" % (i, sys.gettotalrefcount()))

which prints:

   0: start refs = 71395
   0: after refs = 71462
   1: start refs = 71463
   1: after refs = 71493
   2: start refs = 71465
   2: after refs = 71494
   3: start refs = 71465
   3: after refs = 71494
   4: start refs = 71465
   4: after refs = 71494

Note that the start/after refs converge on a difference of 29 references.

The existing version 'regrtest.py' does something like:

   import sys, ctypes, gc

   ctypes._reset_cache()
   gc.collect()

   for i in range(0, 5):
       print("%d: start refs = %s" % (i, sys.gettotalrefcount()))
       proto = ctypes.CFUNCTYPE(ctypes.POINTER(ctypes.c_char))
       ctypes._reset_cache()
       gc.collect()
       print("%d: after refs = %s" % (i, sys.gettotalrefcount()))

which prints:

   0: start refs = 71391
   0: after refs = 71458
   1: start refs = 71458
   1: after refs = 71489
   2: start refs = 71489
   2: after refs = 71490
   3: start refs = 71490
   3: after refs = 71490
   4: start refs = 71490
   4: after refs = 71490

This one converges on a difference of zero.

So, I am not sure whether there really is a leak, if this is just
a very senstive area of 'regrtest.py', or something else I am missing.

----------

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

From report at bugs.python.org  Wed Dec  7 00:45:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 23:45:31 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1323214903.04.0.78072292975.issue13390@psf.upfronthosting.co.za>
Message-ID: <1323214814.4215.2.camel@localhost.localdomain>


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

> So, I am not sure whether there really is a leak, if this is just
> a very senstive area of 'regrtest.py', or something else I am missing.

Well, test_ctypes seems to be the only test exhibiting that behaviour.
And since your script reproduces it, it's probably not regrtest.py in
itself.

----------

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

From report at bugs.python.org  Wed Dec  7 02:08:35 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 07 Dec 2011 01:08:35 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1323220115.25.0.0758126377927.issue8641@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I applied the patch against the latest version in the repository and it works correctly.

----------
nosy: +serwy
type:  -> behavior
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec  7 02:32:13 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 07 Dec 2011 01:32:13 +0000
Subject: [issue11838] IDLE: make interactive code savable as a runnable script
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1323221533.94.0.0537803321029.issue11838@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This issue relates to #1178

A traceback does not necessarily mean that the last statement had the error. For example:

    >>> a = lambda: 1/0
    >>> a()

    Traceback (most recent call last):
      File "<pyshell#1>", line 1, in <module>
        a()
      File "<pyshell#0>", line 1, in <lambda>
        a = lambda: 1/0
    ZeroDivisionError: integer division or modulo by zero

I suppose that the specification should be extended such that the above to get transformed to:

    a = lambda: 1/0
    #ERROR>>> a()
    #
    #Traceback  (most recent call last):
    #....

or something similar. Thoughts?

----------

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

From report at bugs.python.org  Wed Dec  7 02:45:35 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 07 Dec 2011 01:45:35 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323222335.26.0.0409065068077.issue11051@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/issue11051>
_______________________________________

From report at bugs.python.org  Wed Dec  7 03:01:01 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 07 Dec 2011 02:01:01 +0000
Subject: [issue13511] ./configure --includedir, --libdir accept multiple
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1323223261.94.0.828478319735.issue13511@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

You should request this new feature on autoconf at gnu.org or bug-autoconf at gnu.org mailing list.

----------
nosy: +Arfrever

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

From report at bugs.python.org  Wed Dec  7 04:20:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 07 Dec 2011 03:20:56 +0000
Subject: [issue11838] IDLE: make interactive code savable as a runnable script
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1323228056.6.0.893370258191.issue11838@psf.upfronthosting.co.za>


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

Interesting example. This issue is a bit more complicated than I thought. Clearly, the call that reveals an error in previous lines should not be simply deleted.

----------

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

From report at bugs.python.org  Wed Dec  7 06:46:15 2011
From: report at bugs.python.org (Ron Adam)
Date: Wed, 07 Dec 2011 05:46:15 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323236775.47.0.5980194063.issue11682@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

There is a test for 'yield from' as a function argument without the extra parentheses.

      f(yield from x)

You do need them in the case of a regular yield.

      f((yield))   or f((yield value))

Shouldn't the same rule apply in both cases?

* I'm trying to do a version of the patch with 'yield_from' as a separate item from 'yield' in the grammar, but it insists on the parentheses due to it being a yield_expr component.

----------
nosy: +ron_adam

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

From report at bugs.python.org  Wed Dec  7 09:14:11 2011
From: report at bugs.python.org (Peter Frauenglass)
Date: Wed, 07 Dec 2011 08:14:11 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
Message-ID: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>


New submission from Peter Frauenglass <python.org at everblue.info>:

While attempting to use pydoc, I came across the following error. On my system it's simple to reproduce: pydoc -p 1234, then visit http://localhost:1234/ in a browser.

A open('/home/(me)/DEBUG', 'w').write(binary)
 right before the m.groups() call created the attached file. Hopefully this is enough to help. Thanks.

~$ pydoc3.2 -p 1234 py/core.py 
Server ready at http://localhost:1234/
Server commands: [b]rowser, [q]uit
server> ----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 49185)
Traceback (most recent call last):
  File "/usr/lib/python3.2/socketserver.py", line 284, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python3.2/socketserver.py", line 310, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python3.2/socketserver.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.2/socketserver.py", line 638, in __init__
    self.handle()
  File "/usr/lib/python3.2/http/server.py", line 399, in handle
    self.handle_one_request()
  File "/usr/lib/python3.2/http/server.py", line 387, in handle_one_request
    method()
  File "/usr/lib/python3.2/pydoc.py", line 2405, in do_GET
    self.path, content_type).encode('utf-8'))
  File "/usr/lib/python3.2/pydoc.py", line 2723, in _url_handler
    return get_html_page(url)
  File "/usr/lib/python3.2/pydoc.py", line 2713, in get_html_page
    return html.page(title, content)
  File "/usr/lib/python3.2/pydoc.py", line 2497, in page
    </body></html>''' % (title, css_link, html_navbar(), contents)
  File "/usr/lib/python3.2/pydoc.py", line 2530, in html_navbar
    """ % (version, html.escape(platform.platform(terse=True)))
  File "/usr/lib/python3.2/platform.py", line 1568, in platform
    libcname,libcversion = libc_ver(sys.executable)
  File "/usr/lib/python3.2/platform.py", line 184, in libc_ver
    if soversion > version:
TypeError: unorderable types: NoneType() > str()
----------------------------------------

----------
components: Library (Lib)
files: DEBUG
messages: 148951
nosy: threewestwinds
priority: normal
severity: normal
status: open
title: Pydoc3.2: TypeError: unorderable types
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23861/DEBUG

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

From report at bugs.python.org  Wed Dec  7 09:22:43 2011
From: report at bugs.python.org (Peter Frauenglass)
Date: Wed, 07 Dec 2011 08:22:43 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <1323246163.54.0.584788908543.issue13545@psf.upfronthosting.co.za>


Peter Frauenglass <python.org at everblue.info> added the comment:

I should also mention that pydoc2.7 -p 1234 works without issue. It seems to be a regression.

Also adding lemburg to the Nosy list as the comments on platform.py suggest.

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

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

From report at bugs.python.org  Wed Dec  7 09:42:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Dec 2011 08:42:21 +0000
Subject: [issue13542] Memory leak in multiprocessing.pool
In-Reply-To: <1323203310.38.0.606183787821.issue13542@psf.upfronthosting.co.za>
Message-ID: <1323247341.49.0.382084878674.issue13542@psf.upfronthosting.co.za>


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


----------
nosy: +jnoller
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Wed Dec  7 09:49:04 2011
From: report at bugs.python.org (Ji Han)
Date: Wed, 07 Dec 2011 08:49:04 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
Message-ID: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>


New submission from Ji Han <hanji1984 at gmail.com>:

The following code snippet will crash IDLE:

>>> import sys
>>> sys.setrecursionlimit((1<<31)-1)

The crash happens immediately and is consistently reproducible (environment: Windows 7 SP1 64-bit, Python 2.7.2 for Windows X86_64).

----------
components: None
messages: 148953
nosy: hanji
priority: normal
severity: normal
status: open
title: sys.setrecursionlimit() crashes IDLE
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec  7 10:14:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2011 09:14:53 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <E1RYDaW-00072V-17@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3822c8087d70 by Ned Deily in branch '3.2':
Issue #8641: Update IDLE 3 syntax coloring to recognize b".." and not u"..".
http://hg.python.org/cpython/rev/3822c8087d70

New changeset e49220f4c31f by Ned Deily in branch 'default':
Issue #8641: Update IDLE 3 syntax coloring to recognize b".." and not u"..".
http://hg.python.org/cpython/rev/e49220f4c31f

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Dec  7 10:17:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2011 09:17:07 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1323249427.6.0.0949690760727.issue8641@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the patch, Tal, and thanks for testing it, Roger.  Applied to 3.2 for release in 3.2.3 and to default for 3.3.0.

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution: works for me -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.1

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

From report at bugs.python.org  Wed Dec  7 10:57:54 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2011 09:57:54 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323251874.11.0.69126122371.issue13546@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Trying to set the recursion limit to a large number defeats its purpose.  As documented in the Standard Library Reference:

The highest possible limit is platform-dependent. A user may need to set the limit higher when she has a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash.

http://docs.python.org/library/sys.html#sys.setrecursionlimit

----------
nosy: +ned.deily
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
type:  -> crash

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

From report at bugs.python.org  Wed Dec  7 11:02:06 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Dec 2011 10:02:06 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323252126.84.0.243428928065.issue13546@psf.upfronthosting.co.za>


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

On the other hand, there is no reason for the recursion limit to be actually reached, just by setting it!  Is there a hidden infinite recursion somewhere?

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Wed Dec  7 11:05:29 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Dec 2011 10:05:29 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323252329.7.0.714797521383.issue13546@psf.upfronthosting.co.za>


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

hanji, could you start IDLE from a command prompt and try again:

   c:\python27\python.exe -m idlelib.idle

Do you see additional error messages?

----------

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

From report at bugs.python.org  Wed Dec  7 11:11:41 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 07 Dec 2011 10:11:41 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323252701.29.0.256319236879.issue11682@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

>>> f((yield))

This requirement seems unnecessary. And surprising, because f(<generator-expression>) or f('a' if 'a' else 'b') doesn't require parenthes. There's no room for confusion if parentheses were omitted in the single-argument case. (Following the rule given in documentation for generator expressions: "The parentheses can be omitted on calls with only one argument.").

----------

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

From report at bugs.python.org  Wed Dec  7 11:14:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2011 10:14:41 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323252881.55.0.594597315859.issue13546@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

But after setting it, IDLE is going to be executing code.  In the 64-bit Windows Python 2.7.2 that I have available, there were exceptions reported in the command line interpreter (not IDLE) after changing the recursion limit and then executing some code.  Perhaps there is another of the known overflow error issues here.  OTOH, similar reports have also been closed as "won't fix", most recently Issue12468.  This doesn't seem worth the effort to investigate further.  Feel free to reopen if you disagree.

----------

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

From report at bugs.python.org  Wed Dec  7 12:28:23 2011
From: report at bugs.python.org (Ji Han)
Date: Wed, 07 Dec 2011 11:28:23 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323257303.23.0.541570145459.issue13546@psf.upfronthosting.co.za>


Ji Han <hanji1984 at gmail.com> added the comment:

@amaury.forgeotdarc

It says 'python.exe has stopped working'. Details:

  Problem Event Name:	APPCRASH
  Application Name:	python.exe
  Application Version:	0.0.0.0
  Application Timestamp:	4df4b010
  Fault Module Name:	MSVCR90.dll
  Fault Module Version:	9.0.30729.6161
  Fault Module Timestamp:	4dace4e7
  Exception Code:	c00000fd
  Exception Offset:	000000000001edcf
  ... ... ...

P.S. I'm well aware recursions won't go that deep. But crashing IDLE (instead of Raising an Error) by simply setting an option is still annoying.

----------

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

From report at bugs.python.org  Wed Dec  7 13:15:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Dec 2011 12:15:55 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <1323260155.08.0.0777983177456.issue13545@psf.upfronthosting.co.za>


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

This seems to be an issue with the platform module's detection of the glibc. Can you tell us more about your system? (OS, distribution...)

----------
nosy: +pitrou, r.david.murray
versions: +Python 3.3

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

From report at bugs.python.org  Wed Dec  7 13:31:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2011 12:31:05 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323261065.02.0.48887422312.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23216/0001.diff

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

From report at bugs.python.org  Wed Dec  7 13:31:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2011 12:31:32 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323261092.48.0.966084487389.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23570/issue11682_pep380_branch_20111131.diff

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

From report at bugs.python.org  Wed Dec  7 13:31:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2011 12:31:35 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323261095.09.0.856598555973.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23639/test.py

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

From report at bugs.python.org  Wed Dec  7 13:31:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2011 12:31:37 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323261097.23.0.635885857321.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23759/0001-2.diff

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

From report at bugs.python.org  Wed Dec  7 13:31:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2011 12:31:39 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323261099.89.0.456783876544.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
hgrepos:  -11

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

From report at bugs.python.org  Wed Dec  7 13:38:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2011 12:38:57 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323261537.16.0.00577956428332.issue11682@psf.upfronthosting.co.za>


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

OK, I removed all the old files and repo links (they're still available in the history below if needed). (well, the link to Renaud's hg patch queue is gone, but that's also present in one of the early comments). (Ron: your comment makes me think you were looking at an old version of the PEP 380 updates. The most up to date published version is the tip of my BitBucket branch)

Also, don't spend a lot of time messing with functional aspects of the patch folks, especially the Grammar. 'yield from' is going to be a variant of the existing yield expressions to avoid parser ambiguity, and it's going to inherit all of the associated restrictions, including the requirement for parentheses when it's the sole argument to a function.

While that restriction isn't *necessary*, it's also irrelevant to this PEP (hence why I reverted Greg's changes that allowed it for 'yield from', but not for other yield expressions).

----------

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

From report at bugs.python.org  Wed Dec  7 13:42:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2011 12:42:32 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323261752.0.0.279847923176.issue11682@psf.upfronthosting.co.za>


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

As far as *why* yield expressions aren't special cased the way generator expressions are - just an oversight when yield expressions were added, no real grand master plan. It's not a big deal in practice, so nobody has ever cared enough to argue for fixing it.

Conditional expressions simply don't include mandatory parentheses as part of the syntax in the first place.

----------

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

From report at bugs.python.org  Wed Dec  7 14:04:35 2011
From: report at bugs.python.org (Darren Dale)
Date: Wed, 07 Dec 2011 13:04:35 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1323263075.26.0.636538762677.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

New patch addressing comments in review.

----------
Added file: http://bugs.python.org/file23864/abc_descriptor.patch

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

From report at bugs.python.org  Wed Dec  7 14:29:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Dec 2011 13:29:57 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323264597.58.0.203570016568.issue13546@psf.upfronthosting.co.za>


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

Tested on Linux:
Python 2.7.2+ (2.7:16c4137a413c+, Dec  4 2011, 22:56:38) 
[GCC 4.4.3] on linux2
>>> import sys
>>> sys.setrecursionlimit((1<<31)-1)
>>> import xx
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.ImportError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.ImportError'> ignored
Traceback (most recent call last):

This comes from PyErr_GivenExceptionMatches() which tries to "Temporarily bump the recursion limit", and calls Py_SetRecursionLimit(reclimit + 5); without any consideration for 32bit int overflow... and PyErr_WriteUnraisable() is called to display the error.

IDLE crashes (with a real stack overflow) because sys.stderr is a special RPCProxy object whose methods are found through a __getattr__. But __getattr__ is called when __getattribute__ raises AttributeError, right?  To implement this, PyErr_GivenExceptionMatches() is called again, fails again, call PyErr_WriteUnraisable()... recursively.

The fix should be easy: do not bump the recursion limit when it's already too high.

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

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

From report at bugs.python.org  Wed Dec  7 14:56:44 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 07 Dec 2011 13:56:44 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <1323266204.19.0.686770625682.issue13545@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

On my system it works. :-)

----------
nosy: +maniram.maniram

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

From report at bugs.python.org  Wed Dec  7 15:16:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 14:16:30 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <1323267390.05.0.0220374135529.issue13545@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you try to patch platform.py with the following patch?


diff --git a/Lib/platform.py b/Lib/platform.py
--- a/Lib/platform.py
+++ b/Lib/platform.py
@@ -186,7 +186,7 @@ def libc_ver(executable=sys.executable,l
         elif so:
             if lib != 'glibc':
                 lib = 'libc'
-                if soversion > version:
+                if soversion and soversion > version:
                     version = soversion
                 if threads and version[-len(threads):] != threads:
                     version = version + threads

----------
nosy: +haypo

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

From report at bugs.python.org  Wed Dec  7 16:53:29 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Dec 2011 15:53:29 +0000
Subject: [issue13547] Clean Lib/_sysconfigdata.py and Modules/_testembed
Message-ID: <1323273209.84.0.652920813208.issue13547@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I think that `make distclean` should remove Lib/_sysconfigdata.py and
Modules/_testembed. On second thought, `make clean` should probably
also remove those.

----------
components: Build
messages: 148969
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Clean Lib/_sysconfigdata.py and Modules/_testembed
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec  7 16:56:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Dec 2011 15:56:10 +0000
Subject: [issue13547] Clean Lib/_sysconfigdata.py and Modules/_testembed
In-Reply-To: <1323273209.84.0.652920813208.issue13547@psf.upfronthosting.co.za>
Message-ID: <1323273370.31.0.774900456233.issue13547@psf.upfronthosting.co.za>


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

Yes, "make clean" should remove them as well.

----------
nosy: +pitrou
versions: +Python 3.2

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

From report at bugs.python.org  Wed Dec  7 17:09:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Dec 2011 16:09:13 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1323274153.48.0.373568675733.issue13500@psf.upfronthosting.co.za>


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

I believe the commit would have needed a regression test.

----------

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

From report at bugs.python.org  Wed Dec  7 17:11:48 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Wed, 07 Dec 2011 16:11:48 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1323274308.24.0.582037109568.issue13500@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

I'll verify the fix in another day or two.

FWIW unless python is willing to import pexpect, or provide an equivalent, I'm not sure how items like this which require interactive  input can be run via the python project testing framework.

----------

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

From report at bugs.python.org  Wed Dec  7 17:16:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Dec 2011 16:16:46 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1323274606.39.0.78828144891.issue13500@psf.upfronthosting.co.za>


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

> I'm not sure how items like this which require interactive  input can
> be run via the python project testing framework.

Replace sys.stdin with a custom object (a stub) and you can control input (see the Inputs class used in Lib/packaging/tests/test_create.py or Lib/packaging/tests/test_command_register.py).  The readline module would not be used however, so that can?t be tested.

----------

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

From report at bugs.python.org  Wed Dec  7 17:28:10 2011
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Wed, 07 Dec 2011 16:28:10 +0000
Subject: [issue13548] Invalid 'line' tracer event on pass within else clause
Message-ID: <1323275290.33.0.837630531134.issue13548@psf.upfronthosting.co.za>


New submission from Stephan R.A. Deibel <sdeibel at wingware.com>:

The tracer set with sys.settrace() is called incorrectly with a 'line' event on a 'pass' that is at the end of an 'else' clause on the final line of a function even if the else block is not executed by the interpreter.  Whew, talk about an end case!  The attached file illustrates this.

----------
components: Interpreter Core
files: badlineevent.py
messages: 148974
nosy: sdeibel
priority: normal
severity: normal
status: open
title: Invalid 'line' tracer event on pass within else clause
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23865/badlineevent.py

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

From report at bugs.python.org  Wed Dec  7 17:30:17 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 07 Dec 2011 16:30:17 +0000
Subject: [issue13548] Invalid 'line' tracer event on pass within else clause
In-Reply-To: <1323275290.33.0.837630531134.issue13548@psf.upfronthosting.co.za>
Message-ID: <1323275417.36.0.78627446799.issue13548@psf.upfronthosting.co.za>


Changes by Ned Batchelder <ned at nedbatchelder.com>:


----------
nosy: +nedbat

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

From report at bugs.python.org  Wed Dec  7 17:32:03 2011
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Wed, 07 Dec 2011 16:32:03 +0000
Subject: [issue13548] Invalid 'line' tracer event on pass within else clause
In-Reply-To: <1323275290.33.0.837630531134.issue13548@psf.upfronthosting.co.za>
Message-ID: <1323275523.48.0.350970252968.issue13548@psf.upfronthosting.co.za>


Stephan R.A. Deibel <sdeibel at wingware.com> added the comment:

Sorry, the print statement in the file needs a tweak to work with Python 3.2, but the bug does occur there also.

----------

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

From report at bugs.python.org  Wed Dec  7 17:37:26 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Wed, 07 Dec 2011 16:37:26 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1323275846.34.0.981355870668.issue13500@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Ok. I'll see if I can provide a unittest for this by the 12th.

----------

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

From report at bugs.python.org  Wed Dec  7 17:49:56 2011
From: report at bugs.python.org (Ron Adam)
Date: Wed, 07 Dec 2011 16:49:56 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1323276596.86.0.421009211232.issue11682@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

Thanks for the updated links Nick.

There is a comment in the docs that recommends putting parentheses around any yield expression that returns a value.  So it is in agreement with that in the function argument case.

The grammar I used does keep it as a variant.

    yield_expr 'yield' [testlist | yield_from]
    yield_from 'from' test

The purpose of doing that is so I can do ...

    yield_expr 'yield' [testlist | yield_from | yield_raise]
    yield_from 'from' test
    yield_raise 'raise' [test ['from' test]]

The yield_raise part is only an interesting exercise to help me understand cpythons internals better.  I'm getting there and hope to be able to contribute to more bug fixes, and patches. :-)

----------

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

From report at bugs.python.org  Wed Dec  7 17:56:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Dec 2011 16:56:01 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323276961.27.0.241175232406.issue13394@psf.upfronthosting.co.za>


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

I think the patch includes too many changes.  It would be better if you can split it in two separate patches: one with the increased coverage, the other with the bugs you found and their tests.
I can easily commit the first (assuming it doesn't break the test suite), but the second requires someone familiar with the aifc module for a review.
If you have found (and fixed) several unrelated bugs in aifc, it might be better to split the second patch further, and possibly open different issues, stating what the bugs are and how you fixed them.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Wed Dec  7 18:15:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Dec 2011 17:15:14 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
In-Reply-To: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>
Message-ID: <1323278114.47.0.226060694677.issue13531@psf.upfronthosting.co.za>


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


----------
assignee:  -> ezio.melotti
stage: test needed -> commit review

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

From report at bugs.python.org  Wed Dec  7 18:27:24 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 07 Dec 2011 17:27:24 +0000
Subject: [issue13534] test_cmath fails on ppc with glibc-2.14.90 due to buggy
	architecture-specific "hypot"
In-Reply-To: <1323127461.54.0.191716898613.issue13534@psf.upfronthosting.co.za>
Message-ID: <1323278844.07.0.875409249228.issue13534@psf.upfronthosting.co.za>


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

I agree.  I filed this here in case anyone else ran into it, but given that this is really a glibc bug (now fixed), I'm closing this out as "won't fix".

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

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

From report at bugs.python.org  Wed Dec  7 18:49:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Dec 2011 17:49:27 +0000
Subject: [issue13542] Memory leak in multiprocessing.pool
In-Reply-To: <1323203310.38.0.606183787821.issue13542@psf.upfronthosting.co.za>
Message-ID: <1323280167.11.0.833687241503.issue13542@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's a duplicate of #12157.

----------
nosy: +neologix
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty

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

From report at bugs.python.org  Wed Dec  7 19:16:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2011 18:16:32 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <E1RYM2h-0007rb-Av@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a541bda2f5e2 by Charles-Fran?ois Natali in branch 'default':
Issue #11051: Reduce the number of syscalls per import.
http://hg.python.org/cpython/rev/a541bda2f5e2

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Dec  7 19:27:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Dec 2011 18:27:09 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323282429.65.0.334749088369.issue11051@psf.upfronthosting.co.za>


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

I would have appreciated had you considered my review before pushing that change.

----------

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

From report at bugs.python.org  Wed Dec  7 19:43:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Dec 2011 18:43:33 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323283413.44.0.801191008578.issue11051@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I would have appreciated had you considered my review before pushing
> that change.

Sorry, I didn't receive an email notification for your review, so I didn't know you had done one. I'll add a comment.

----------

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

From report at bugs.python.org  Wed Dec  7 19:45:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Dec 2011 18:45:27 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <CAH_1eM3GhXAMbwD+__3ojjdXF5yMVf54QwyD3BjkS5j4t59vug@mail.gmail.com>
Message-ID: <CAH_1eM02EouZ-1X8dgZhEDbDWsPzzh6PxGb-HtdQUHSE4Wd88w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23866/event_wait_cleared.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -804,8 +804,9 @@
       floating point number specifying a timeout for the operation in seconds
       (or fractions thereof).
 
-      This method returns the internal flag on exit, so it will always return
-      ``True`` except if a timeout is given and the operation times out.
+      This method returns true if and only if the internal flag has been set to
+      true by another thread, so it will always return ``True`` except if a
+      timeout is given and the operation times out.
 
       .. versionchanged:: 3.1
          Previously, the method always returned ``None``.
diff --git a/Lib/test/lock_tests.py b/Lib/test/lock_tests.py
--- a/Lib/test/lock_tests.py
+++ b/Lib/test/lock_tests.py
@@ -353,6 +353,22 @@
         for r, dt in results2:
             self.assertTrue(r)
 
+    def test_set_and_clear(self):
+        # Issue #13502: check that wait() returns true even when the event is
+        # cleared before the waiting thread is woken up.
+        evt = self.eventtype()
+        results = []
+        N = 5
+        def f():
+            results.append(evt.wait(1))
+        b = Bunch(f, N)
+        b.wait_for_started()
+        time.sleep(0.5)
+        evt.set()
+        evt.clear()
+        b.wait_for_finished()
+        self.assertEqual(results, [True] * N)
+
 
 class ConditionTests(BaseTestCase):
     """
diff --git a/Lib/threading.py b/Lib/threading.py
--- a/Lib/threading.py
+++ b/Lib/threading.py
@@ -408,9 +408,10 @@
     def wait(self, timeout=None):
         self._cond.acquire()
         try:
-            if not self._flag:
-                self._cond.wait(timeout)
-            return self._flag
+            signaled = self._flag
+            if not signaled:
+                signaled = self._cond.wait(timeout)
+            return signaled
         finally:
             self._cond.release()
 

From report at bugs.python.org  Wed Dec  7 20:40:07 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Dec 2011 19:40:07 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1323286807.96.0.99602406847.issue13453@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> URLError: <urlopen error [Errno 4] Non-recoverable failure in name
> resolution>

For this one, we should probably add EAI_FAIL to support.transient_internet.

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file23867/transient.diff

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

From report at bugs.python.org  Wed Dec  7 20:40:20 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Dec 2011 19:40:20 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323286820.58.0.478218024706.issue13546@psf.upfronthosting.co.za>


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

Here is a patch, with test.

----------
keywords: +patch
Added file: http://bugs.python.org/file23868/issue13546.patch

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

From report at bugs.python.org  Wed Dec  7 20:40:39 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Dec 2011 19:40:39 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323286839.07.0.202095450945.issue13546@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Dec  7 21:36:53 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2011 20:36:53 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323290213.18.0.800995195072.issue13546@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

LGTM

----------

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

From report at bugs.python.org  Wed Dec  7 21:51:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2011 20:51:20 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <E1RYOSQ-0005kX-SN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 57de1ad15c54 by Amaury Forgeot d'Arc in branch '2.7':
Issue #13546: Fixed an overflow issue that could crash the intepreter when
http://hg.python.org/cpython/rev/57de1ad15c54

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Dec  7 21:52:52 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Dec 2011 20:52:52 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323291172.84.0.5106771636.issue13546@psf.upfronthosting.co.za>


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

This will be fixed in the next 2.7 release, thanks for the report!

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

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

From report at bugs.python.org  Wed Dec  7 22:18:23 2011
From: report at bugs.python.org (Matt Mackall)
Date: Wed, 07 Dec 2011 21:18:23 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1323292703.22.0.0526896619218.issue1602@psf.upfronthosting.co.za>


Matt Mackall <mpm at selenic.com> added the comment:

The underlying cause of Python's write exceptions with cp65001 is:

The ANSI C write() function as implemented by the Windows console returns the number of _characters_ written rather than the number of _bytes_, which Python reasonably interprets as a "short write error". It then consults errno, which gives the effectively random error message seen.

This can be bypassed by using os.write(sys.stdout.fileno(), utf8str), which will a) succeed and b) return a count <= len(utf8str).

With os.write() and an appropriate font, the Windows console will correctly display a large number of characters.

Possible workaround: clear errno before calling write, check for non-zero errno after. The vast majority of (non-Python) applications never check the return value of write, so don't encounter this problem.

----------
nosy: +Matt.Mackall

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

From report at bugs.python.org  Wed Dec  7 22:19:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 21:19:08 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1323292748.05.0.696226490667.issue11870@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I got the debug output of test_3_join_in_forked_from_thread() using some hacks (threading._VERBOSE=True and don't hide subprocess output):

Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[  1] test_threading
test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... <OS thread 139683761760000>: <Condition(<_thread.lock object at 0x7f0aa24b8e50>, 0)>.notify(): no waiters
MainThread: <Thread(Thread-1, initial)>.start(): starting thread
<OS thread 139683646777088>: <Condition(<_thread.lock object at 0x7f0aa24b8b80>, 1)>.notify(): notifying 1 waiter
Thread-1: <Thread(Thread-1, started 139683646777088)>._bootstrap(): thread started
MainThread: <Condition(<_thread.lock object at 0x7f0aa24b8b80>, 0)>.wait(): got it
MainThread: <Condition(<_thread.lock object at 0x7f0aa24b8cc0>, 0)>.notify(): no waiters
MainThread: <_MainThread(MainThread, stopped 139683761760000)>: waiting for other threads
MainThread: <Thread(Thread-1, started 139683646777088)>.join(): waiting until thread stops
end of main
Thread-1: <Thread(Thread-2, initial)>.start(): starting thread
<OS thread 139683638384384>: <Condition(<_thread.lock object at 0x7f0aa24b8b30>, 1)>.notify(): notifying 1 waiter
Thread-2: <Thread(Thread-2, started 139683638384384)>._bootstrap(): thread started
Thread-1: <Condition(<_thread.lock object at 0x7f0aa24b8b30>, 0)>.wait(): got it
Thread-2: <_MainThread(MainThread, stopped 139683761760000)>.join(): thread stopped
Thread-1: <Thread(Thread-2, started 139683638384384)>.join(): waiting until thread stops
end of thread
Thread-2: <Thread(Thread-2, started 139683638384384)>._bootstrap(): normal return
Thread-2: <Condition(<_thread.lock object at 0x7f0aa24b8b80>, 1)>.notify(): notifying 1 waiter
Thread-1: <Condition(<_thread.lock object at 0x7f0aa24b8b80>, 0)>.wait(): got it
Thread-1: <Thread(Thread-2, stopped 139683638384384)>.join(): thread stopped
Thread-1: <Thread(Thread-1, started 139683646777088)>._bootstrap(): normal return
Thread-1: <_RLock owner='Thread-1' count=1>.acquire(True): initial success
Thread-1: <Condition(<_RLock owner='Thread-1' count=1>, 0)>.notify(): no waiters
Thread-1: <_RLock owner=None count=0>.release(): final release
Thread-1: <Thread(Thread-1, started 139683646777088)>._bootstrap(): raised SystemExit
Thread-1: <Condition(<_thread.lock object at 0x7f0aa24b8bd0>, 1)>.notify(): notifying 1 waiter
MainThread: <Condition(<_thread.lock object at 0x7f0aa24b8bd0>, 0)>.wait(): got it
MainThread: <Thread(Thread-1, stopped 139683646777088)>.join(): thread stopped
MainThread: <_MainThread(MainThread, stopped 139683761760000)>: exiting
[47121 refs]
ok

----------------------------------------------------------------------
Ran 1 test in 0.095s

OK
[  2] test_threading
test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... <OS thread 140303874844416>: <Condition(<_thread.lock object at 0x7f9b03ea4e50>, 0)>.notify(): no waiters
MainThread: <Thread(Thread-1, initial)>.start(): starting thread
<OS thread 140303759861504>: <Condition(<_thread.lock object at 0x7f9b03ea4b80>, 1)>.notify(): notifying 1 waiter
Thread-1: <Thread(Thread-1, started 140303759861504)>._bootstrap(): thread started
MainThread: <Condition(<_thread.lock object at 0x7f9b03ea4b80>, 0)>.wait(): got it
MainThread: <Condition(<_thread.lock object at 0x7f9b03ea4cc0>, 0)>.notify(): no waiters
MainThread: <_MainThread(MainThread, stopped 140303874844416)>: waiting for other threads
MainThread: <Thread(Thread-1, started 140303759861504)>.join(): waiting until thread stops
end of main

----------

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

From report at bugs.python.org  Wed Dec  7 22:26:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 21:26:21 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1323293181.49.0.90769958712.issue11870@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, it's better with the process identifiers. Oh, by the way: the output is not truncated, Python test hangs during the second run :-) Without the debug output, it needs more than 1,000 runs to reproduce the 
 bug (hang).

Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[  1] test_threading
test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... pid 25114: <OS thread 140143566120704>: <Condition(<_thread.lock object at 0x7f75b0c54e50>, 0)>.notify(): no waiters
pid 25114: MainThread: <Thread(Thread-1, initial)>.start(): starting thread
pid 25114: <OS thread 140143451137792>: <Condition(<_thread.lock object at 0x7f75b0c54b80>, 1)>.notify(): notifying 1 waiter
pid 25114: Thread-1: <Thread(Thread-1, started 140143451137792)>._bootstrap(): thread started
pid 25114: MainThread: <Condition(<_thread.lock object at 0x7f75b0c54b80>, 0)>.wait(): got it
pid 25114: MainThread: <Condition(<_thread.lock object at 0x7f75b0c54cc0>, 0)>.notify(): no waiters
pid 25114: MainThread: <_MainThread(MainThread, stopped 140143566120704)>: waiting for other threads
pid 25114: MainThread: <Thread(Thread-1, started 140143451137792)>.join(): waiting until thread stops
end of main
pid 25116: Thread-1: <Thread(Thread-2, initial)>.start(): starting thread
pid 25116: <OS thread 140143373580032>: <Condition(<_thread.lock object at 0x7f75b0c54b30>, 1)>.notify(): notifying 1 waiter
pid 25116: Thread-2: <Thread(Thread-2, started 140143373580032)>._bootstrap(): thread started
pid 25116: Thread-2: <_MainThread(MainThread, stopped 140143566120704)>.join(): thread stopped
end of thread
pid 25116: Thread-2: <Thread(Thread-2, started 140143373580032)>._bootstrap(): normal return
pid 25116: Thread-1: <Condition(<_thread.lock object at 0x7f75b0c54b30>, 0)>.wait(): got it
pid 25116: Thread-2: <Condition(<_thread.lock object at 0x7f75b0c54b80>, 0)>.notify(): no waiters
pid 25116: Thread-1: <Thread(Thread-2, stopped 140143373580032)>.join(): thread stopped
pid 25116: Thread-1: <Thread(Thread-1, started 140143451137792)>._bootstrap(): normal return
pid 25116: Thread-1: <_RLock owner='Thread-1' count=1>.acquire(True): initial success
pid 25116: Thread-1: <Condition(<_RLock owner='Thread-1' count=1>, 0)>.notify(): no waiters
pid 25116: Thread-1: <_RLock owner=None count=0>.release(): final release
pid 25114: Thread-1: <Thread(Thread-1, started 140143451137792)>._bootstrap(): raised SystemExit
pid 25114: Thread-1: <Condition(<_thread.lock object at 0x7f75b0c54bd0>, 1)>.notify(): notifying 1 waiter
pid 25114: MainThread: <Condition(<_thread.lock object at 0x7f75b0c54bd0>, 0)>.wait(): got it
pid 25114: MainThread: <Thread(Thread-1, stopped 140143451137792)>.join(): thread stopped
pid 25114: MainThread: <_MainThread(MainThread, stopped 140143566120704)>: exiting
[47125 refs]
ok

----------------------------------------------------------------------
Ran 1 test in 0.091s

OK
[  2] test_threading
test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... pid 25118: <OS thread 139664631559936>: <Condition(<_thread.lock object at 0x7f062e0bde50>, 0)>.notify(): no waiters
pid 25118: MainThread: <Thread(Thread-1, initial)>.start(): starting thread
pid 25118: <OS thread 139664516577024>: <Condition(<_thread.lock object at 0x7f062e0bdb80>, 1)>.notify(): notifying 1 waiter
pid 25118: Thread-1: <Thread(Thread-1, started 139664516577024)>._bootstrap(): thread started
pid 25118: MainThread: <Condition(<_thread.lock object at 0x7f062e0bdb80>, 0)>.wait(): got it
pid 25118: MainThread: <Condition(<_thread.lock object at 0x7f062e0bdcc0>, 0)>.notify(): no waiters
pid 25118: MainThread: <_MainThread(MainThread, stopped 139664631559936)>: waiting for other threads
pid 25118: MainThread: <Thread(Thread-1, started 139664516577024)>.join(): waiting until thread stops
end of main

----------

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

From report at bugs.python.org  Wed Dec  7 22:34:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 21:34:23 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1323293663.35.0.532161746812.issue11870@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg148991

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

From report at bugs.python.org  Wed Dec  7 22:34:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 21:34:25 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1323293665.99.0.470705874489.issue11870@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg148992

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

From report at bugs.python.org  Wed Dec  7 22:35:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 21:35:35 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1323293735.07.0.739178051163.issue11870@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I removed my two previous message (msg148991 and msg148992), there were unrelated to this issue: the test hangs in debug mode in the IO module because of a deadleak in IO related to the fork...

----------

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

From report at bugs.python.org  Wed Dec  7 22:49:54 2011
From: report at bugs.python.org (Matt Long)
Date: Wed, 07 Dec 2011 21:49:54 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
Message-ID: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>


New submission from Matt Long <matt at crocodoc.com>:

The description of nesting list comprehensions in section 5.1.5 of the main Python tutorial (http://docs.python.org/tutorial/datastructures.html#nested-list-comprehensions) is misleading at best and arguably incorrect. Where it says "To avoid apprehension when nesting list comprehensions, read from right to left." This is incorrect and conflicts directly with the comment at the bottom of PEP 202 (http://www.python.org/dev/peps/pep-0202/), which says the last index varies fastest.

Take the following example:

matrix = [[1,2],[3,4],[5,6]]
my_list = []
for row in matrix:
  for number in row
    my_list.append(number)

The current documentation would suggest I do the following to achieve the same result with list comprehensions since the for statements should be read from right to left:

matrix = [[1,2],[3,4],[5,6]]
my_list = [number for number in row for row in matrix]

Running this code will result in an error. The correct form is:

matrix = [[1,2],[3,4],[5,6]]
[number for row in matrix for number in row]

Clearly the nesting order only matters when the inner loop depends on the outer loop as in my example above. There is no such dependency in the documentation's example, which is why it is does not result in an Error.

----------
assignee: docs at python
components: Documentation
messages: 148994
nosy: docs at python, mattlong
priority: normal
severity: normal
status: open
title: Incorrect nested list comprehension documentation
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Dec  7 23:04:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2011 22:04:11 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
In-Reply-To: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>
Message-ID: <E1RYPaz-0004IF-BM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a8deeb549e1a by Ezio Melotti in branch '2.7':
#13531: add a test for defaultdict with a non-callable arg.  Patch by Mike Cheng.
http://hg.python.org/cpython/rev/a8deeb549e1a

New changeset 17ceebc61b65 by Ezio Melotti in branch '3.2':
#13531: add a test for defaultdict with a non-callable arg.  Patch by Mike Cheng.
http://hg.python.org/cpython/rev/17ceebc61b65

New changeset 4180308547d9 by Ezio Melotti in branch 'default':
#13531: merge with 3.2.
http://hg.python.org/cpython/rev/4180308547d9

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Dec  7 23:04:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Dec 2011 22:04:20 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1323293735.07.0.739178051163.issue11870@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1BY1r24B5Dig1gYmN5xM6K6Fs9axWiO87tw7VRxSMT9w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

To debug this, we should probably make use of faulthandler (but not
dump_tracebacks_later, since it creates a new thread). The way to go
could be to make the parent process send a fatal signal to the child
process if the latter takes too long to complete.

----------

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

From report at bugs.python.org  Wed Dec  7 23:08:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Dec 2011 22:08:20 +0000
Subject: [issue13531] add test for defaultdict with non-callable first argument
In-Reply-To: <1323086123.24.0.303040379749.issue13531@psf.upfronthosting.co.za>
Message-ID: <1323295700.73.0.904967458246.issue13531@psf.upfronthosting.co.za>


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

Committed, thanks for the report and the patch!
For the record, this is related to https://bugs.pypy.org/issue953

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Dec  7 23:20:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 07 Dec 2011 22:20:28 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323296428.65.0.948149726765.issue11051@psf.upfronthosting.co.za>


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

I am a little puzzled by the patch. In logic, 'A and B' is equivalent to 'not A or not B'. But in the patch,

-            if (_Py_stat(filename, &statbuf) == 0 &&  /it exists */
-                S_ISDIR(statbuf.st_mode)) /* it's a directory */
+            if (_Py_stat(filename, &statbuf) != 0 || S_ISDIR(statbuf.st_mode))

you seem to change to 'not A or B', without negating B. Is this intentional? What am I missing? Some subtle effect of lazy evaluation? Or an intentional change in the logic?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Wed Dec  7 23:23:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 22:23:09 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323296589.74.0.560825646293.issue11051@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

By the way, _Py_stat() can fail because of a Python error: -1 result is not handled in import.c :-( It may leak to the "XXX undetected error" message.

----------
nosy: +haypo

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

From report at bugs.python.org  Wed Dec  7 23:30:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 07 Dec 2011 22:30:56 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1323297056.78.0.0652639905503.issue11051@psf.upfronthosting.co.za>


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

OK, I gather from the comment added in the second patch that you intentionally changed the logic to restart the loop more often.

----------

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

From report at bugs.python.org  Wed Dec  7 23:40:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 22:40:27 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
Message-ID: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>


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

The threading module uses an hack to log actions to help debugging. The log depends on 3 flags: __debug__, threading._VERBOSE and a verbose attribute (each threading class has such attribute). By default, _note() is always called but does nothing: it checks the verbose attribute and return if the flag is False.

Attached threading_note.patch only calls _note() if verbose is True to avoid a Python function call (which is slow in CPython). It avoids also a _Verbose parent class and pass the verbose flag to subobjects (e.g. Semaphore sets verbose argument of its Condition object).

I don't think that it is really useful to be able to enable/disable logs on only one threading object, so it is maybe simpler to have only one global flag (instead of 3 flags): threading._VERBOSE. Attached threading_note_global.patch replaces _note() method by a function, remove _Verbose class and the _verbose attribute, and only call _note() if _VERBOSE is True.

_VERBOSE and verbose arguments are undocumented and not tested, so I hope nobody relies on their API ;-)

----------
components: Library (Lib)
files: threading_note.patch
keywords: patch
messages: 149001
nosy: haypo
priority: normal
severity: normal
status: open
title: Rewrite logging hack of the threading module
versions: Python 3.3
Added file: http://bugs.python.org/file23869/threading_note.patch

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

From report at bugs.python.org  Wed Dec  7 23:40:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 22:40:41 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1323297641.05.0.956262169466.issue13550@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file23870/threading_note_global.patch

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

From report at bugs.python.org  Wed Dec  7 23:55:51 2011
From: report at bugs.python.org (Peter Frauenglass)
Date: Wed, 07 Dec 2011 22:55:51 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <1323298551.71.0.510378611395.issue13545@psf.upfronthosting.co.za>


Peter Frauenglass <python.org at everblue.info> added the comment:

The patch in msg<148968> solves the issue for me.

I'm running Linux, originally installed as Mint 9, though upgraded and modified incrementally until it's now kubuntu 11.10. I have the "libc6" package version "2.13-20ubuntu5" installed.

----------

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

From report at bugs.python.org  Thu Dec  8 00:15:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 23:15:59 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1323299759.96.0.843308691381.issue13550@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file23870/threading_note_global.patch

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

From report at bugs.python.org  Thu Dec  8 00:16:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 23:16:26 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1323299786.03.0.193908654198.issue13550@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(threading_note_global.patch was completly wrong, here is the fixed version)

----------
Added file: http://bugs.python.org/file23871/threading_note_global.patch

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

From report at bugs.python.org  Thu Dec  8 00:33:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2011 23:33:00 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <E1RYQyw-0003Av-Lx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c143e66e5efe by Victor Stinner in branch '3.2':
Issue #11886: workaround an OS bug (time zone data) in test_time
http://hg.python.org/cpython/rev/c143e66e5efe

New changeset c7638be1e430 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11886: workaround an OS bug (time zone data) in test_time
http://hg.python.org/cpython/rev/c7638be1e430

New changeset 2bca2cee79a1 by Victor Stinner in branch '2.7':
Issue #11886: workaround an OS bug (time zone data) in test_time
http://hg.python.org/cpython/rev/2bca2cee79a1

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Dec  8 01:38:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 00:38:17 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1323304697.3.0.975426300575.issue3786@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I hacked setup.py and _cursesmodule.c to use XPG4 curses. It requires many hacks because it lacks functions like getattrs() or getsyx/setsyx, constant like KEY_MIN and KEY_MAX. It looks difficult to use this curses library.

----------

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

From report at bugs.python.org  Thu Dec  8 01:41:39 2011
From: report at bugs.python.org (Achim Gaedke)
Date: Thu, 08 Dec 2011 00:41:39 +0000
Subject: [issue13551] pulldom doesn't populate DOM tree
Message-ID: <1323304899.35.0.878509919082.issue13551@psf.upfronthosting.co.za>


New submission from Achim Gaedke <Achim.Gaedke at physik.tu-darmstadt.de>:

Hi!

I tried to use the more general xml.dom interface, no longer defaulting to minidom straight away (or using etree).

The DOM tree gained with PullDOM seem to be incomplete.
Here is the output of the program attached.

$ python pulldom_test.py
with pulldom
(<xml.dom.minidom.Document instance at 0xb722962c>, [])
with minidom
(<xml.dom.minidom.Document instance at 0xb72459ac>, [<DOM Text node "u'\n'">, <DOM Element: a at 0xb71cb74c>, <DOM Text node "u'\n'">, <DOM Element: b at 0xb71cb7ac>, <DOM Text node "u'\n'">, <DOM Element: c at 0xb71cb80c>, <DOM Text node "u'\n'">])

I'd expect the same result for both ways of populating the minidom DOM implementation.

Thanks & Cheers, Achim

----------
components: XML
files: pulldom_test.py
messages: 149006
nosy: AchimGaedke
priority: normal
severity: normal
status: open
title: pulldom doesn't populate DOM tree
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23872/pulldom_test.py

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

From report at bugs.python.org  Thu Dec  8 01:53:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 00:53:18 +0000
Subject: [issue13552] Compilation issues of the curses module on OpenIndiana
Message-ID: <1323305598.14.0.0193622635558.issue13552@psf.upfronthosting.co.za>


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

The _curses module has two issues on OpenSolaris:

 - using the default curses library, mvwchgat() cannot be found and _curses module compilation fails
 - there is a "XPG4 curses" library. I tried to use it using various hacks in _cursesmodule.c and setup.py, but test_curses failed with a crash.
 - if the readline library (not the Python module) is linked to libncursesw, the compilation of the _curses module fails because cchar_t is not defined. I suppose that curses.h is the bytes library, not the ncursesw Unicode library.

See issue #12567 for the ncursesw issue and issue #3786 for the mvwchgat() problem. The issue #3786 contains information about XPG4 curses and has a (non working) patch for the mvwchgat() issue.

--

I opened a new issue because #12567 is more specific to Unicode, and #3786 talks about various issues (it is not specific to curses).

----------
components: Build
messages: 149007
nosy: haypo, iandekit, jcea, mschmarck
priority: normal
severity: normal
status: open
title: Compilation issues of the curses module on OpenIndiana
versions: Python 3.3

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

From report at bugs.python.org  Thu Dec  8 01:53:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 00:53:30 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1323305610.24.0.775899635098.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I am still concerned about the compilation warning in OpenIndiana buildbots :-(

I'm unable to reproduce the issue in my OpenIndiana VM: the compilaton of the _curses module fail, not because of Unicode, but because mvwchgat() function is missing => see the issue #3786. I don't know how to install ncursesw on OpenIndiana, I didn't find an official package using pkg search.

curses issues on OpenIndiana are serious enough to have their own issue: I opened the issue #13552.

----------

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

From report at bugs.python.org  Thu Dec  8 01:53:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 00:53:52 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1323305632.17.0.231528096792.issue3786@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened the issue #13552 to list all curses issues on OpenIndiana.

----------

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

From report at bugs.python.org  Thu Dec  8 01:57:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 00:57:00 +0000
Subject: [issue13552] Compilation issues of the curses module on OpenIndiana
In-Reply-To: <1323305598.14.0.0193622635558.issue13552@psf.upfronthosting.co.za>
Message-ID: <1323305820.12.0.561822275341.issue13552@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

curses_hacks.patch: various hacks to use the XPG4 curses on OpenIndiana.

----------
keywords: +patch
nosy: +enchanter
Added file: http://bugs.python.org/file23873/curses_hacks.patch

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

From report at bugs.python.org  Thu Dec  8 02:06:07 2011
From: report at bugs.python.org (Achim Gaedke)
Date: Thu, 08 Dec 2011 01:06:07 +0000
Subject: [issue13551] pulldom doesn't populate DOM tree
In-Reply-To: <1323304899.35.0.878509919082.issue13551@psf.upfronthosting.co.za>
Message-ID: <1323306367.38.0.12357904584.issue13551@psf.upfronthosting.co.za>


Achim Gaedke <Achim.Gaedke at physik.tu-darmstadt.de> added the comment:

sorry, the output given before was generated with python2.7

changing the line
xml.sax.parseString(xml_data, d_handler)

to

xml.sax.parseString(bytes(xml_data, "utf-8"), d_handler)

makes it working for python 3.2, result the same:

$ python3.2 pulldom_test.py
with pulldom
<xml.dom.minidom.Document object at 0x9bf9f2c> []
with minidom
<xml.dom.minidom.Document object at 0x9c2fccc> [<DOM Text node "'\n'">, <DOM Element: a at 0x9c3850c>, <DOM Text node "'\n'">, <DOM Element: b at 0x9c3856c>, <DOM Text node "'\n'">, <DOM Element: c at 0x9c385cc>, <DOM Text node "'\n'">]

Both test were done on debian testing/wheezy.

$ python3.2 -V
Python 3.2.2rc1
$ python -V
Python 2.7.2+

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file23874/pulldom_test.py

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

From report at bugs.python.org  Thu Dec  8 02:07:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 01:07:13 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1323306433.63.0.444869431079.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The code has been commited. The remaining task is to fix OpenIndiana issues: see #13552.

----------

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

From report at bugs.python.org  Thu Dec  8 02:07:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 01:07:21 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1323306441.99.0.287367188219.issue12567@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/issue12567>
_______________________________________

From report at bugs.python.org  Thu Dec  8 02:12:10 2011
From: report at bugs.python.org (th9)
Date: Thu, 08 Dec 2011 01:12:10 +0000
Subject: [issue13553] Tkinter doesn't set proper application name
Message-ID: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>


New submission from th9 <rei4dan at gmail.com>:

I want the app name to be displayed under the icon in Alt+Tab menu, but currently it only displays the className of the root, which by default is "Tk". So in Gnome3 all Tkinter apps show up as "Tk" in the panel and in the Alt+Tab menu.

It is possible to override that to some extent by giving className attribute to Tk(), but I don't know what the side effects are and it doesn't preserve capitalization of the name - the first letter is capital, but all others are small. Moreover, default title of the window is taken from the className by making first letter small and leaving the rest as given, so at the end nothing is as intended.

E.g., if I give calssName="APP", the app is called "App", but windows title is "aPP".

There should be a way to give this information, but I don't see it exposed anywhere and it is not correctly inferred from args[0] either.

Example program attached.

----------
components: Tkinter
files: tk_wm_test.py
messages: 149013
nosy: th9
priority: normal
severity: normal
status: open
title: Tkinter doesn't set proper application name
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23875/tk_wm_test.py

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

From report at bugs.python.org  Thu Dec  8 02:23:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 01:23:29 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1323307409.63.0.702783694258.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

localeconv_wchar.c: test program to dump the thousands separator on a locale specified on the command line. I wrote this program to try to reproduce the hu_HU issue, but I cannot reproduce it on OpenIndiana. I only have UTF-8 locales on my OpenIndiana VM, whereas the issue looks to be specific to an ISO-8859-?? encoding (b'\xA0' is not decodable from UTF-8).

----------
Added file: http://bugs.python.org/file23876/localeconv_wchar.c

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

From report at bugs.python.org  Thu Dec  8 02:44:26 2011
From: report at bugs.python.org (th9)
Date: Thu, 08 Dec 2011 01:44:26 +0000
Subject: [issue13554] Tkinter doesn't use higher resolution app icon
Message-ID: <1323308666.66.0.322569696678.issue13554@psf.upfronthosting.co.za>


New submission from th9 <rei4dan at gmail.com>:

48x48 icons in Gnome3 show up blurry, but giving larger resolution (128 or 256) icon to Tkinter doesn't improve its appearance at all in the panel or Alt+Tab menu.

I'm using 'photoimage' to get color icon. Giving two resolution icons in whatever order doesn't change anything - get blurry icon.

Attached example script. It expects two PNG pictures (48x48 and 256x256) in the CWD and uses PIL to load them.

----------
components: Tkinter
files: tk_wm_icon_test.py
messages: 149015
nosy: th9
priority: normal
severity: normal
status: open
title: Tkinter doesn't use higher resolution app icon
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23877/tk_wm_icon_test.py

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

From report at bugs.python.org  Thu Dec  8 05:13:49 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 08 Dec 2011 04:13:49 +0000
Subject: [issue7136] Idle File Menu Option Improvement
In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za>
Message-ID: <1323317629.14.0.905460224007.issue7136@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This issue is mentioned as part of #13504 meta-issue.

The attached patch extends Tal's original patch by also updating the help.txt documentation.

----------
nosy: +serwy
Added file: http://bugs.python.org/file23878/issue7136.patch

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

From report at bugs.python.org  Thu Dec  8 05:23:37 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 08 Dec 2011 04:23:37 +0000
Subject: [issue13319] IDLE: Menu accelerator conflict between Format and
	Options
In-Reply-To: <1320195837.58.0.031082649983.issue13319@psf.upfronthosting.co.za>
Message-ID: <1323318217.57.0.0699216366107.issue13319@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a patch to have Alt-i bring up the Options menu.

----------
keywords: +patch
Added file: http://bugs.python.org/file23879/issue13319.patch

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

From report at bugs.python.org  Thu Dec  8 05:30:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Dec 2011 04:30:01 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <CAH_1eM02EouZ-1X8dgZhEDbDWsPzzh6PxGb-HtdQUHSE4Wd88w@mail.gmail.com>
Message-ID: <20111208042958.A625F2500E6@webabinitio.net>


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

On Wed, 07 Dec 2011 18:45:27 +0000, <report at bugs.python.org> wrote:
> _______________________________________
> diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
> --- a/Doc/library/threading.rst
> +++ b/Doc/library/threading.rst
> @@ -804,8 +804,9 @@
>        floating point number specifying a timeout for the operation in seconds
>        (or fractions thereof).
>  
> -      This method returns the internal flag on exit, so it will always return
> -      ``True`` except if a timeout is given and the operation times out.
> +      This method returns true if and only if the internal flag has been set to
> +      true by another thread, so it will always return ``True`` except if a
> +      timeout is given and the operation times out.

This seems to imply that if the current thread previously set the event,
the wait will return False, which is contradicted by the 'so' statement
(which appears to be correct).

--David

----------

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

From report at bugs.python.org  Thu Dec  8 08:40:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 08 Dec 2011 07:40:42 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1323330042.0.0.384184423696.issue13502@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This seems to imply that if the current thread previously set the event,
> the wait will return False, which is contradicted by the 'so' statement
> (which appears to be correct).

You're probably referring to the "another thread" part...
A suggestion ? I see you're a native speaker :-)

----------

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

From report at bugs.python.org  Thu Dec  8 11:20:00 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Dec 2011 10:20:00 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1323339600.48.0.986461487475.issue13441@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/issue13441>
_______________________________________

From report at bugs.python.org  Thu Dec  8 12:47:07 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 08 Dec 2011 11:47:07 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1323344827.04.0.995770382395.issue5689@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

For those who want to test it first, I post the current state of the patch here. It is ready for commit, there are no failing tests. If nobody objects, I will apply it this weekend.

----------
Added file: http://bugs.python.org/file23880/2011-12-08-tarfile-lzma.diff

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

From report at bugs.python.org  Thu Dec  8 13:00:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 12:00:53 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1323345653.98.0.791835362176.issue5689@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Some comments about 2011-12-08-tarfile-lzma.diff:

> elif self.buf.startswith(b"\x5d\x00\x00\x80") or self.buf.startswith(b"...

Micro-optimization: you can use self.buf.startswith((b"\x5d\x00\x00\x80", b"\xfd7zXZ")) here.

> raise ValueError("mode must be 'r' or 'w'.")

Error messages usually don't end with a dot (or am I wrong?).

It would be better to use a skip instead of just return here:

def test_no_name_argument(self):
  if self.mode.endswith("bz2") or self.mode.endswith("xz"):
    # BZ2File and LZMAFile have no name attribute.
    return

In _Stream.__init__, for zlib:

> self.exception = zlib.error

Could you add a test for this change?

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Dec  8 13:16:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 12:16:19 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1323346579.82.0.395211288769.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also the issue #7442.

----------

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

From report at bugs.python.org  Thu Dec  8 13:41:40 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 08 Dec 2011 12:41:40 +0000
Subject: [issue7136] Idle File Menu Option Improvement
In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za>
Message-ID: <1323348100.77.0.440417271794.issue7136@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

+1 on renaming New Window to New File

----------
nosy: +maniram.maniram

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

From report at bugs.python.org  Thu Dec  8 13:45:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 12:45:15 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1323348315.86.0.370817484237.issue5905@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh! I think that I understood the problem: if HAVE_WCSFTIME is not defined, timemodule.c uses strftime(), instead of wcsftime(), encode input format and decode the format. It uses UTF-8 to encode/decode, whereas the right encoding is the locale encoding. Attached patch should fix this issue.

@Antoine: Do you have any idea why HAVE_WCSFTIME was not defined?

wcsftime() is defined in <wchar.h> on Ubuntu. In configure, it is tested using AC_CHECK_FUNCS(wcsftime)

----------
components: +Unicode
keywords: +patch
resolution: invalid -> 
status: closed -> open
Added file: http://bugs.python.org/file23881/tzname_encoding.patch

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

From report at bugs.python.org  Thu Dec  8 13:49:13 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 08 Dec 2011 12:49:13 +0000
Subject: [issue1062] nice to have a way to tell if a socket is bound
In-Reply-To: <1188496399.92.0.368162629574.issue1062@psf.upfronthosting.co.za>
Message-ID: <1323348553.97.0.222619682687.issue1062@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

perhaps you can subclass socket.socket and make a function wrapper around bind and connect that sets a variable if called
like:
class sock(socket.socket):
    def bind(self,*args):
        self.is_bound = True

----------
nosy: +maniram.maniram

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

From report at bugs.python.org  Thu Dec  8 13:51:20 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 08 Dec 2011 12:51:20 +0000
Subject: [issue1062] nice to have a way to tell if a socket is bound
In-Reply-To: <1188496399.92.0.368162629574.issue1062@psf.upfronthosting.co.za>
Message-ID: <1323348680.83.0.740346402461.issue1062@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

oops should be
class sock(socket.socket):
    _bind = socket.socket.bind
    def bind(self,*args):
        self.is_bound = True
        self._bind(self,*args)

----------

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

From report at bugs.python.org  Thu Dec  8 13:52:03 2011
From: report at bugs.python.org (Phillies)
Date: Thu, 08 Dec 2011 12:52:03 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
Message-ID: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>


New submission from Phillies <phil at bethgelab.org>:

When I try to load a large file (>1GB) cPickle crashes with a MemoryError:
$python test.py
Traceback (most recent call last):
  File "/tmp/test.py", line 8, in <module>
    A2 = cPickle.load(f2)
MemoryError

test.py contains following code:
import numpy as np
import cPickle
A = np.random.randn(196,240000)
f = open('test.pydat', 'w')
cPickle.dump(A,f)
f.close()
f2 = open('test.pydat', 'rb')
A2 = cPickle.load(f2)

System:
cPickle 1.71
python 2.7.2
Ubuntu 11.10 amd64

Memory is not an issue as a) pickle works nicely and b) my computer has 122GB free RAM

----------
components: None
messages: 149027
nosy: phillies
priority: normal
severity: normal
status: open
title: cPickle MemoryError when loading large file (while pickle works)
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  8 13:56:56 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 08 Dec 2011 12:56:56 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323349016.33.0.352914322137.issue13555@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Maybe Ubuntu doesn't think it is safe to allocate the memory.

----------
nosy: +maniram.maniram

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

From report at bugs.python.org  Thu Dec  8 14:02:08 2011
From: report at bugs.python.org (Philipp Lies)
Date: Thu, 08 Dec 2011 13:02:08 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323349328.92.0.728114539728.issue13555@psf.upfronthosting.co.za>


Philipp Lies <phil at bethgelab.org> added the comment:

Well, replace cPickle by pickle and it works. So if there is a memory allocation problem cPickle should be able to handle it, especially since it should be completely compatible to pickle.

----------

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

From report at bugs.python.org  Thu Dec  8 14:12:29 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Dec 2011 13:12:29 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323349949.37.0.579816873914.issue13546@psf.upfronthosting.co.za>


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

Style nit:  how about

    'except ValueError as e'

instead of

    'except ValueError, e'

(Actually, why do we need e?)

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Dec  8 14:16:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Dec 2011 13:16:52 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323350212.9.0.501961277475.issue13549@psf.upfronthosting.co.za>


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

Isn't the documentation that you refer to about *nested* list comprehensions, rather than list comprehensions with multiple 'for' clauses?

E.g.,:

    [number for row in matrix for number in row]

is not a nested list comprehension:  it's merely a list comprehension with two 'for' clauses.  But:

    [[number for number in row] for row in matrix]

*is* a nested list comprehension (a list comprehension for which the initial expression is itself a list comprehension), and there the advice to read from right to left seems to make sense to me.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Dec  8 14:17:32 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Dec 2011 13:17:32 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323350252.75.0.758457688627.issue13549@psf.upfronthosting.co.za>


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

Mind you, I'm not at all sure about that use of 'apprehension'...

----------

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

From report at bugs.python.org  Thu Dec  8 14:31:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Dec 2011 13:31:32 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1323351092.21.0.0183372226715.issue13441@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

localeconv_wchar.c runs fine on Ubuntu with hu_HU and fi_FI.

I tried on OpenSolaris, but I only have UTF-8 locales. The package
with ISO locales seems to be SUNWlang-cs-extra, but Oracle took down
http://pkg.opensolaris.org/release/ .

----------

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

From report at bugs.python.org  Thu Dec  8 14:38:18 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 08 Dec 2011 13:38:18 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323351498.64.0.219457001899.issue13555@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Have you checked the system monitor after all cPickle can use more memory than 1GB.

----------

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

From report at bugs.python.org  Thu Dec  8 14:40:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Dec 2011 13:40:29 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323351629.42.0.293245499634.issue13555@psf.upfronthosting.co.za>


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

Is there a way to reproduce that doesn't involve numpy?

----------
components: +Extension Modules -None
nosy: +pitrou

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

From report at bugs.python.org  Thu Dec  8 14:40:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Dec 2011 13:40:36 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323351636.97.0.483106425346.issue13555@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/issue13555>
_______________________________________

From report at bugs.python.org  Thu Dec  8 15:11:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 14:11:28 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323353488.31.0.202285234866.issue13549@psf.upfronthosting.co.za>


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

This section could be clearer imho.
First of all there's nothing special about "nested" list comprehensions.  In [expr for elem in seq], expr might be any expression -- including a listcomp.  As with any other expression, the nested listcomp will be executed for each elem in seq, so there's really nothing new to explain here.
The "reading order" is always from left to right, with the expression at the end:
    [expr for x in seq1 for y in seq2 for z in seq3]
     ^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^^^
     last     first        second         third...

So I agree that "To avoid apprehension when nesting list comprehensions, read from right to left." is a bit confusing/wrongish (is actually correct for listcomp with only a single for, but that's just a coincidence and it's not related to nested listcomps).

The previous section could also be a little clearer, showing the classic example:
    squares = [x**2 for x in range(10)]
and saying that it's equivalent to
    squares = []
    for x in range(10):
        squares.append(x**2)

and, similarly, that
    combs = [(c1, c2) for c1 in 'abc' for c2 in 'xyz']
is equivalent to
    combs = []
    for c1 in 'abc':
        for c2 in 'xyz':
            combs.append((c1, c2))

Showing the "reading direction" with these two equivalents and saying that nested listcomps follow the same rule (because there's nothing different about them), should be enough to make things clear.

In addition, the example with the matrix shouldn't use print in the "expanded" version, but rather something like:
    res = []
    for i in [0, 1, 2]:
        res.append([row[i] for row in mat])
    print res

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Thu Dec  8 15:28:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 08 Dec 2011 14:28:41 +0000
Subject: [issue13546] sys.setrecursionlimit() crashes IDLE
In-Reply-To: <1323247744.36.0.765628927504.issue13546@psf.upfronthosting.co.za>
Message-ID: <1323354521.7.0.384383837013.issue13546@psf.upfronthosting.co.za>


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

'e' is "used" in the comment above: "isinstance(e, ValueError) used to fail"...
I agree to use the modern 'as' syntax.

----------

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

From report at bugs.python.org  Thu Dec  8 15:42:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Dec 2011 14:42:16 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1323355336.86.0.500275142544.issue5905@psf.upfronthosting.co.za>


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

Well, it seems defined here:

$ grep HAVE_WCSFTIME pyconfig.h
1071:#define HAVE_WCSFTIME 1

> Attached patch should fix this issue.

I'm sorry, I can't test the patch, because my Linux distro (Mageia) doesn't have the "fr_FR.ISO8859-15" locale anymore :-(

----------

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

From report at bugs.python.org  Thu Dec  8 16:04:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 15:04:11 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323356651.77.0.0709788892576.issue13549@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti
keywords: +patch
nosy: +eric.araujo, terry.reedy
stage: needs patch -> commit review
Added file: http://bugs.python.org/file23882/issue13549.diff

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

From report at bugs.python.org  Thu Dec  8 17:31:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 08 Dec 2011 16:31:54 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323361914.33.0.746658220089.issue13549@psf.upfronthosting.co.za>


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

I welcome improvements to this part of the docs.  Nested list comps had me quite confused at first: I had to write and execute them to understand how it worked.  So, the patch looks good to me.  Remarks:

- I?d recommend a few whitespace beautifications, like in ``for x in [1,2,3]`` and ``range(1,6)``.

- You changed ?If the expression would evaluate to a tuple, it must be parenthesized? to ?If the expression is a tuple (e.g. the ``(x, y)`` +in this example), it must be parenthesized?, I guess because either the concept that an expression evaluates to something is (a) incorrect or (b) not appropriate at this stage of the tutorial.  I think there is an example that makes that line more understandable, but it?s in the section about tuples, not here in the listcomp section; you may or may not want to improve that too.

- +1 for the removal of the half-joking half-recommendation not to use nested list comps (?If you've got the stomach for it, list comprehensions can be nested. They are a powerful tool but -- like all powerful tools -- they need to be used carefully, if at all.?).

- Maybe a link to the itertools module is appropriate (either after the combinations example, or after the link to the built-in zip function).

----------

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

From report at bugs.python.org  Thu Dec  8 17:42:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 08 Dec 2011 16:42:08 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1323362528.81.0.991013682705.issue5689@psf.upfronthosting.co.za>


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

Patch looks great.  I did a review on Rietveld.

----------

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

From report at bugs.python.org  Thu Dec  8 17:48:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 08 Dec 2011 16:48:25 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1323362905.0.0.554637299004.issue6715@psf.upfronthosting.co.za>


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

I?ll commit my doc patch to all branches later.

I checked the 4 red 3.3 builbots and they can?t build _lzma.

----------

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

From report at bugs.python.org  Thu Dec  8 18:08:58 2011
From: report at bugs.python.org (James C. Ahlstrom)
Date: Thu, 08 Dec 2011 17:08:58 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1323364138.05.0.0852800554515.issue1757072@psf.upfronthosting.co.za>


James C. Ahlstrom <ahlstromjc at users.sourceforge.net> added the comment:

I received a bug report from a user.  He had a zip file created by Mac OS 10.5.8 that the zipfile module claimed was not a valid zip file.  The traceback went to function _EndRecData(fpin).  The file had a valid comment appended, but recorded a comment length of zero.  I am posting to this thread because it seems related.

The zero comment length is incorrect, but the file is read without complaint by other software.  Note that this is not end of file garbage; the comment is valid.

The _EndRecData(fpin) function is reading the "End of Central Directory" record.  The endrec[7] is the comment length, but of more interest is endrec[6] which is the start of the Central Directory.  This is a file offset, and if valid it points to a Central Directory record.  These records start with a known string PK\001\002.

I propose that the correct fix is to delete the test for correct comment length, and replace it with a test that reads four bytes at offset endrec[6] and makes sure it is PK\001\002 and a valid record.  This is viewed not as a hack for defective software, but rather as an improved sanity check, since finding the Central Directory is vital to reading a zip file.  This code replaces the end of _EndRecData(fpin), and was taken from Python2.5 (so check against the relevant version):

    if start >= 0:     # Correct signature string was found
        endrec = struct.unpack(structEndArchive, data[start:start+22])
        endrec = list(endrec)
        comment = data[start+22:]

## Relevant changes here
        fpin.seek(endrec[6], 0)		# Seek to the start of the central directory
        dat = fpin.read(4)	# Read four bytes
        # Note: Mac OS is known to add a comment, but record the length as zero.
        if dat == stringCentralDir:     # Success
##
            # Append the archive comment and start offset
            endrec.append(comment)
            endrec.append(filesize - END_BLOCK + start)
            if endrec[-4] == -1 or endrec[-4] == 0xffffffff:
                return _EndRecData64(fpin, - END_BLOCK + start, endrec)
            return endrec
    return      # Error, return None

----------
nosy: +ahlstromjc

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

From report at bugs.python.org  Thu Dec  8 18:10:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 17:10:20 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323364220.0.0.407171061774.issue13549@psf.upfronthosting.co.za>


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

> - I?d recommend a few whitespace beautifications,
> like in ``for x in [1,2,3]`` and ``range(1,6)``.
Leaving the space out in [1,2,3] makes the expression a bit more readable IMHO*.


>  I think there is an example that makes that line more
> understandable, but it?s in the section about tuples, not here in the 
> listcomp section; you may or may not want to improve that too.
What needs to be parenthesized are tuple literals, and I think people at this point of the tutorial still think that () are required to make a tuple, so they would probably put them anyway.  IOW the example that uses them, the note, and the example that fails are probably enough already.

> - Maybe a link to the itertools module is appropriate (either after 
> the combinations example, or after the link to the built-in zip 
> function).
I was going to add it, but then realized that itertools' functions don't return lists, so they are a bit unrelated (and maybe it's too early to introduce itertools at this point of the tutorial).


* the idea is to separate better different elements, even if the single elements are a bit less readable:
2 * 3          is ok (you are multiplying two numbers)
2*3 + 4*5      is ok (you are adding two products)
2 * 3 + 4 * 5  is less readable (you have to parse the operations)
2 * 3+4 * 5    is misleading (it looks like the product of 3 numbers)
Similarly:
[(1,2,3), (3,4,5), (5,6,7)]  is ok (you have a list with 3 tuples)
[(1, 2, 3), (3, 4, 5), (5, 6, 7)]  is less readable (the space are used to separate both the tuples and the elements in there, and you have to parse the () to see where the tuples start and end).
YMMV though.

----------

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

From report at bugs.python.org  Thu Dec  8 18:14:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Dec 2011 17:14:25 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1323364465.34.0.172917833163.issue1757072@psf.upfronthosting.co.za>


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

I'm pretty sure that what you are reporting has been fixed by the 'garbage' fix I mentioned (which might better be called the 'more flexible handling of comments' patch).  Though not in 2.5 (or 2.6) since they are no longer in maintenance.  If you could confirm this by testing against 2.7 or 3.2, that would be great.

----------

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

From report at bugs.python.org  Thu Dec  8 18:22:09 2011
From: report at bugs.python.org (Ray)
Date: Thu, 08 Dec 2011 17:22:09 +0000
Subject: [issue13511] ./configure --includedir, --libdir accept multiple
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1323364929.32.0.97183339187.issue13511@psf.upfronthosting.co.za>


Ray <rpqpro at hotmail.com> added the comment:

Compiling using the includedir/libdir flags with colon as separators for the multiple directories got me an error after performing 'make':

Makefile:782: *** target pattern contains no `%'.  Stop.

Additionally, I would like to emphasize the fact that I could not find another way to specify multiple lib and include directories when compiling Python 2.7 on Linux using the current setup.py.

----------

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

From report at bugs.python.org  Thu Dec  8 18:23:11 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Dec 2011 17:23:11 +0000
Subject: [issue13556] When tzinfo.utcoffset is out-of-bounds,
	the exception message is misleading
Message-ID: <1323364991.44.0.541305100354.issue13556@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

When a timezone produces an out-of-bounds utc offset, the resulting exception always claims that the offset was 1440, rather than whatever it was.  Example:

from datetime import timedelta, datetime, tzinfo

class X(tzinfo):
    def utcoffset(self, time):
        return timedelta(days=2)

datetime.now(tz=X())

----------
components: Library (Lib)
messages: 149046
nosy: exarkun
priority: normal
severity: normal
status: open
title: When tzinfo.utcoffset is out-of-bounds, the exception message is misleading
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  8 18:40:59 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 08 Dec 2011 17:40:59 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1323366059.37.0.0980574629152.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> I?ll commit my doc patch to all branches later.

OK, great.

> I checked the 4 red 3.3 builbots and they can?t build _lzma.

For the record, the 3.x buildbots that currently aren't able to build the
_lzma module are:

* x86 Ubuntu Shared
* sparc solaris10 gcc
* AMD64 Snow Leopard 2
* x86 debian parallel
* ARM Ubuntu
* x86 Tiger
* AMD64 OpenIndiana
* x86 OpenIndiana
* x86 FreeBSD 7.2
* x86 FreeBSD 6.4

Additionally, the AMD64 debian bigmem, PPC Tiger and PPC Leopard builders
have been offline/broken since before changeset 74d182cf0187 was committed.

----------

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

From report at bugs.python.org  Thu Dec  8 18:58:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Dec 2011 17:58:12 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1323366059.37.0.0980574629152.issue6715@psf.upfronthosting.co.za>
Message-ID: <1323366772.3274.15.camel@localhost.localdomain>


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

Le jeudi 08 d?cembre 2011 ? 17:40 +0000, Nadeem Vawda a ?crit :
> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:
> 
> > I?ll commit my doc patch to all branches later.
> 
> OK, great.
> 
> > I checked the 4 red 3.3 builbots and they can?t build _lzma.
> 
> For the record, the 3.x buildbots that currently aren't able to build the
> _lzma module are:

Ok, I've e-mailed the owners.

Will someone write an entry in the "what's new" file for 3.3?
(Doc/whatsnew/3.3.rst)

Regards

Antoine.

----------

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

From report at bugs.python.org  Thu Dec  8 19:57:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 08 Dec 2011 18:57:44 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323370664.73.0.510885106837.issue13555@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> my computer has 122GB free RAM

122, or 1.22?

> Well, replace cPickle by pickle and it works.

cPickle makes some direct call to malloc()/realloc()/free(), contrarily to pickle which uses pymalloc. This could lead to heap fragmentation.

What does the following return ?
$ /usr/bin/time -v python test.py

----------
nosy: +neologix

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

From report at bugs.python.org  Thu Dec  8 21:25:54 2011
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Thu, 08 Dec 2011 20:25:54 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
Message-ID: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>


New submission from Stephan R.A. Deibel <sdeibel at wingware.com>:

Calling exec() on code that includes a list comprehension that references a defined local variable x fails incorrectly on "NameError: global name 'x' not defined".

----------
files: execlistcomp.py
messages: 149050
nosy: sdeibel
priority: normal
severity: normal
status: open
title: exec of list comprehension fails on NameError
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23883/execlistcomp.py

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

From report at bugs.python.org  Thu Dec  8 21:26:14 2011
From: report at bugs.python.org (Trevor Bentley)
Date: Thu, 08 Dec 2011 20:26:14 +0000
Subject: [issue13558] multiprocessing package incompatible with PyObjC
Message-ID: <1323375974.18.0.406983892582.issue13558@psf.upfronthosting.co.za>


New submission from Trevor Bentley <mrmekon at gmail.com>:

The multiprocessing package appears to spawn a new process by calling only fork().  Apple's CoreFoundation libraries (and possibly more, I do not know the full extent) *require* new processes to be spawned with the full fork()+exec*() combo.

When using PyObjC to access native Mac libraries, Python's multithreading library is not usable.  The error thrown is:

------------------------
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
------------------------

Test code: https://gist.github.com/1448398

----------
assignee: ronaldoussoren
components: Macintosh
files: threadtest3.py
messages: 149051
nosy: mrmekon, ronaldoussoren
priority: normal
severity: normal
status: open
title: multiprocessing package incompatible with PyObjC
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23884/threadtest3.py

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

From report at bugs.python.org  Thu Dec  8 21:43:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Dec 2011 20:43:30 +0000
Subject: [issue13558] multiprocessing package incompatible with PyObjC
In-Reply-To: <1323375974.18.0.406983892582.issue13558@psf.upfronthosting.co.za>
Message-ID: <1323377010.97.0.175761788321.issue13558@psf.upfronthosting.co.za>


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


----------
nosy: +ned.deily
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Dec  8 21:47:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Dec 2011 20:47:26 +0000
Subject: [issue13559] Use sendfile where possible in httplib
Message-ID: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

HTTPConnection.send() should use os.sendfile when possible to avoid copying data into userspace and back.

----------
components: Library (Lib)
keywords: easy
messages: 149052
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: Use sendfile where possible in httplib
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Dec  8 21:48:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Dec 2011 20:48:32 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1323377312.57.0.496788710987.issue13559@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, orsenthil

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

From report at bugs.python.org  Thu Dec  8 22:06:26 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2011 21:06:26 +0000
Subject: [issue13558] multiprocessing package incompatible with PyObjC
In-Reply-To: <1323375974.18.0.406983892582.issue13558@psf.upfronthosting.co.za>
Message-ID: <1323378386.83.0.0200532641651.issue13558@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Reference original discussion in pyobjc-dev mailing list archived here:  http://comments.gmane.org/gmane.comp.python.pyobjc.devel/5965)

----------

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

From report at bugs.python.org  Thu Dec  8 22:26:07 2011
From: report at bugs.python.org (Stan Cox)
Date: Thu, 08 Dec 2011 21:26:07 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323379567.47.0.925096521843.issue13405@psf.upfronthosting.co.za>


Stan Cox <scox at redhat.com> added the comment:

The patch works for systemtap except for one minor nit.  pydtrace.h, created by stap from pydtrace.d, is stap specific.  Could pydtrace.h not be included in <srcdir>/Include so that it is always created at build time in <blddir>/Include?   If PyEval_GetFrame() were passed via function__entry then stap would be able to do something akin to what the ustack helper phelper.d is doing.

----------
nosy: +scox

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

From report at bugs.python.org  Thu Dec  8 22:31:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2011 21:31:16 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <E1RYlYh-00052T-1X@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7efad6256e58 by Stefan Krah in branch '3.2':
Issue #11149: Also enable -fwrapv if $CC is a full path
http://hg.python.org/cpython/rev/7efad6256e58

New changeset e48df59af394 by Stefan Krah in branch 'default':
Merge second fix for issue #11149.
http://hg.python.org/cpython/rev/e48df59af394

New changeset 9d329adbbb01 by Stefan Krah in branch '2.7':
Backport second fix for issue #11149.
http://hg.python.org/cpython/rev/9d329adbbb01

----------

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

From report at bugs.python.org  Thu Dec  8 22:43:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 08 Dec 2011 21:43:52 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323380632.13.0.627632508486.issue13549@psf.upfronthosting.co.za>


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

Comments:

1. The first sentence is a bit too opinionated for my taste. Consider:

map(f, seq)
[f(x) for x in seq]

The map is *more* concise, by 8 chars, than the list comp and, in *my* opinion, clearer and easier to read without the extra boilerplate and extraneous dummy variable. I would write the first sentence more like:

"List comprehensions provide a concise way to create lists without having to use either a blank list followed by list.append or combinations of map, filter, and lambda expressions."

2. The added examples are nice and should help.

3. "In a list comprehension might contain arbitrary expressions, including other listcomps." is not a sentence. I think this in meant to say: "The initial expression in a list comprehension can be any arbitrary expression, including another list comprehension."

4. I completely agree with removing the scary hobgoblin stuff. In fact, I think the platitudinous next sentence "Nested list comprehensions are a powerful tool but -- like all powerful tools -- they need to be used carefully, if at all." could also go. It does not add anything not better said in what follows. Python is a powerful tool, but -- like all powerful tools -- it needs to by used carefully. Yeah, right ;-).

I believe the later sentence "To avoid apprehension when nesting list comprehensions, read from right to left." means to say "To avoid mis-apprehandion [or misunderstanding] when nesting list comprehension, read from outside in." But even this only indirectly points to what I think is the real danger -- which is to read the nested l.c. as unnested, and hence to get the order of the clauses wrong. In other words, reading
   [[f(x,y) for x in xseq] for y in yseq]
as
   [ f(x,y) for x in xseq  for y in yseq]
I initally made that mistake when reading the nested example. So I think the appropriate warning sentence should be something like:
"The main danger to avoid is reading nested comprehensions as if they were one comprehension with multiple for clauses." This could go after the revised initial sentence in place of the useless platitude.

4. The example is more confusing than need be because of using a symmetric matrix. The literal [0,1,2] is both range(len(mat)) and range(len(mat[0])) but it is only the latter that is relevant. So I strongly urge using an asymmetric matrix (3x4) and suggest using range(4) instead of [0,1,2,3]

So, change "Consider the following example of a 3x3 matrix held as a list containing three lists, one list per row::" to
"Suppose one has a 3x4 matrix implemented as a list of 3 lists of length 4::"

Change mat display accordingly, using 1 to 12.

Change "Now, if you wanted to swap rows and columns, you could use this list comprehension::" to
"The following list comprehension will transpose rows and columns."
>>> [[row[i] for row in mat] for i in range(4)]
[[1, 5, 9], [2, 6, 10], [3, 7, 11], [4, 8, 12]]

I think the more verbose version (slightly modified to match the below) should be followed by an even more (completely) verbose version:

trans = []
for i in range(4):
    transrow = []
    for row in mat:
        transrow.append(row[i])
    trans.append(transrow)
print(trans)

5. "In real world," should be "In the real world,".

----------

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

From report at bugs.python.org  Thu Dec  8 23:34:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2011 22:34:28 +0000
Subject: [issue13547] Clean Lib/_sysconfigdata.py and Modules/_testembed
In-Reply-To: <1323273209.84.0.652920813208.issue13547@psf.upfronthosting.co.za>
Message-ID: <E1RYmXr-0001t9-20@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8ed2c4d4df62 by Stefan Krah in branch '3.2':
Issue #13547: clean Lib/_sysconfigdata.py and Modules/_testembed
http://hg.python.org/cpython/rev/8ed2c4d4df62

New changeset 053c95ad09cf by Stefan Krah in branch 'default':
Merge fix for issue #13547.
http://hg.python.org/cpython/rev/053c95ad09cf

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Dec  8 23:41:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2011 22:41:01 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RYmeC-0002X3-1M@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 93bab8400ca5 by Victor Stinner in branch 'default':
Issue #13441: Log the locale when localeconv() fails
http://hg.python.org/cpython/rev/93bab8400ca5

----------

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

From report at bugs.python.org  Thu Dec  8 23:42:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 22:42:10 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1323384130.77.0.149073183875.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Changeset 489ea02ed351 changed PyUnicode_FromWideChar() and PyUnicode_FromUnicode(): raise a ValueError if a character in not in range [U+0000; U+10ffff].

test__locale errors:

======================================================================
ERROR: test_float_parsing (test.test__locale._LocaleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 134, in test_float_parsing
    if localeconv()['decimal_point'] != '.':
ValueError: character U+30000020 is not in range [U+0000; U+10ffff]

======================================================================
ERROR: test_lc_numeric_basic (test.test__locale._LocaleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 105, in test_lc_numeric_basic
    li_radixchar = localeconv()[lc]
ValueError: character U+30000020 is not in range [U+0000; U+10ffff]

======================================================================
ERROR: test_lc_numeric_localeconv (test.test__locale._LocaleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 91, in test_lc_numeric_localeconv
    self.numeric_tester('localeconv', localeconv()[lc], lc, loc)
ValueError: character U+30000020 is not in range [U+0000; U+10ffff]

======================================================================
ERROR: test_lc_numeric_nl_langinfo (test.test__locale._LocaleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 79, in test_lc_numeric_nl_langinfo
    self.numeric_tester('nl_langinfo', nl_langinfo(li), lc, loc)
ValueError: character U+30000020 is not in range [U+0000; U+10ffff]

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

If the issue is specific to the hu_HU locale, a possible workaround is to skip this locale on Solaris. I changed to test to display the locale on failure.

----------

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

From report at bugs.python.org  Thu Dec  8 23:42:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 22:42:46 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323384166.98.0.182808384826.issue13549@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23885/issue13549-2.diff

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

From report at bugs.python.org  Fri Dec  9 00:02:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 23:02:16 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
Message-ID: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>


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

To decode byte string from the locale encoding (LC_CTYPE), PyUnicode_DecodeFSDefault() can be used, but this function uses a constant encoding set at startup (the locale encoding at startup). The right method is currently to call _Py_char2wchar() and then PyUnicode_FromWideChar(). _Py_char2wchar() is a low level function, it doesn't raise nice Python exception, but just return NULL on error and write a message to stderr using fprintf() (!).

Attached patch adds PyUnicode_DecodeLocale() and PyUnicode_DecodeLocaleAndSize() to offer a high level API to decode data from the *current* locale encoding. These functions fail with an OSError  or MemoryError if decoding fails (instead of a generic ValueError), and don't write to stderr anymore. They are a surrogateescape argument to choose to escape undecodable bytes or to fail with an error.

The patch only uses the function in _localemodule.c, but other functions may have to be fixed to use the new function. The tzname_encoding.patch of issue #5905 should maybe use it for example.

----------
components: Unicode
messages: 149060
nosy: ezio.melotti, haypo, loewis
priority: normal
severity: normal
status: open
title: Add PyUnicode_DecodeLocale and PyUnicode_DecodeLocaleAndSize
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  9 00:03:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2011 23:03:05 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
In-Reply-To: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>
Message-ID: <1323385385.49.0.153483196259.issue13560@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23886/pyunicode_decodelocale.patch

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

From report at bugs.python.org  Fri Dec  9 00:17:07 2011
From: report at bugs.python.org (ekorn)
Date: Thu, 08 Dec 2011 23:17:07 +0000
Subject: [issue13543] shlex with string ending in space gives "ValueError: No
	closing quotation"
In-Reply-To: <1323210833.77.0.155317327445.issue13543@psf.upfronthosting.co.za>
Message-ID: <1323386227.84.0.701604048477.issue13543@psf.upfronthosting.co.za>


ekorn <jonovik at gmail.com> added the comment:

FYI, Min RK commented on the IPython issue:
https://github.com/ipython/ipython/issues/1109#issuecomment-3071470

In short, 
shlex.shlex('blob f(" ")', posix=False)
fails, whereas 
shlex.shlex('blob f( " ")', posix=False)

"The problem appears to be that Python source obviously doesn't sit well with non-posix whitespace-split shlex. [...] if you lead all your open-quotes with whitespace, you should be fine (works for all given examples, at least). [...] I have no idea whether this is a Python bug or not, since I don't know what the reference standard is, but this is definitely an IPython bug.  We should not be trying to use shlex to parse Python code as if it were command-line arguments."

----------

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

From report at bugs.python.org  Fri Dec  9 00:34:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2011 23:34:39 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <E1RYnU5-0006fo-Ot@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 66df5ace0eee by Nadeem Vawda in branch 'default':
What's New in Python 3.3: Add entry for lzma module (issue #6715).
http://hg.python.org/cpython/rev/66df5ace0eee

----------

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

From report at bugs.python.org  Fri Dec  9 00:58:05 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 08 Dec 2011 23:58:05 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1323388685.75.0.600090267156.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Ok, I've e-mailed the owners.

Thanks. I was just thinking I should send a reminder, in case they
missed the note in my announcement on python-dev.

> Will someone write an entry in the "what's new" file for 3.3?

Done

----------

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

From report at bugs.python.org  Fri Dec  9 01:18:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2011 00:18:21 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RYoAN-0001N9-Lc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 87c6be1e393a by Victor Stinner in branch 'default':
Issue #13441: Don't test the hu_HU locale on Solaris to workaround a mbstowcs()
http://hg.python.org/cpython/rev/87c6be1e393a

----------

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

From report at bugs.python.org  Fri Dec  9 01:50:07 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 09 Dec 2011 00:50:07 +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: <1323391807.79.0.369724060712.issue8515@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I've encountered this bug several times myself. I applied this patch and it corrects the issue.

----------
nosy: +serwy
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Fri Dec  9 01:54:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Dec 2011 00:54:45 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323392085.7.0.663910220772.issue13549@psf.upfronthosting.co.za>


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

v.2 looks great to me.

----------

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

From report at bugs.python.org  Fri Dec  9 01:59:50 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 09 Dec 2011 00:59:50 +0000
Subject: [issue4691] IDLE Code Caching Windows
In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za>
Message-ID: <1323392390.53.0.287531940894.issue4691@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Given Amaury's last message, should this issue be closed as being resolved?

----------
nosy: +serwy

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

From report at bugs.python.org  Fri Dec  9 02:28:44 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 09 Dec 2011 01:28:44 +0000
Subject: [issue7676] IDLE shell shouldn't use TABs
In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za>
Message-ID: <1323394124.39.0.681197177927.issue7676@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Here's a simple patch to fix this bug.

The ">>> " prompt causes the first level of indented code to use 8 spaces. Further indented code should use 4 spaces, but still uses 8 spaces likely due to the bug described in #8285.

----------
keywords: +patch
nosy: +serwy
versions: +Python 3.3
Added file: http://bugs.python.org/file23887/issue7676.patch

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

From report at bugs.python.org  Fri Dec  9 02:42:56 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 09 Dec 2011 01:42:56 +0000
Subject: [issue6321] Reload Python modules when running programs
In-Reply-To: <1245648620.51.0.901061764952.issue6321@psf.upfronthosting.co.za>
Message-ID: <1323394976.83.0.16697592968.issue6321@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Should this issue be closed? It is related to #4691.

----------
nosy: +serwy

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

From report at bugs.python.org  Fri Dec  9 02:50:00 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 09 Dec 2011 01:50:00 +0000
Subject: [issue13561] os.listdir documentation should mention surrogateescape
Message-ID: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>


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

Where os.listdir encounters undecodable bytes from the filesystem it uses the surrogateescape handler. As the resulting strings are invalid they can't be encoded without an errorhandler, and so can't be printed (for example).

This should be documented.

----------
assignee: docs at python
components: Documentation
messages: 149070
nosy: docs at python, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: os.listdir documentation should mention surrogateescape
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  9 03:22:04 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Fri, 09 Dec 2011 02:22:04 +0000
Subject: [issue13562] Notes about module load path
Message-ID: <1323397324.61.0.220189805252.issue13562@psf.upfronthosting.co.za>


New submission from Nam Nguyen <bitsink at gmail.com>:

A doc patch to remind Python embedder to set sys.path prior to Py_Initialize. This is to ensure a controlled module load path to work around these issues:

http://bugs.python.org/issue12989
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5983

----------
assignee: docs at python
components: Documentation
files: module.load.path.diff
keywords: patch
messages: 149071
nosy: Nam.Nguyen, docs at python
priority: normal
severity: normal
status: open
title: Notes about module load path
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23888/module.load.path.diff

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

From report at bugs.python.org  Fri Dec  9 03:39:47 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 09 Dec 2011 02:39:47 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323398387.59.0.129987475857.issue13505@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

sbt, the bug is not that the encoding is inefficient. The problem is we cannot unpickle bytes streams from Python 3 using Python 2.

----------

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

From report at bugs.python.org  Fri Dec  9 05:52:31 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Dec 2011 04:52:31 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1323406351.42.0.655415580211.issue13559@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This is not possible for two reasons:

- on most POSIX systems, sendfile() works with mmap-like ("regular") files only, while HTTPConnection.send() accepts any file-like object as long as it provides a read() method

- after read()ing a chunk of data from the file and before send()ing it over the socket, the data can be subject to an intermediate conversion (datablock.encode("iso-8859-1")):
http://hg.python.org/cpython/file/87c6be1e393a/Lib/http/client.py#l839
...whereas sendfile() can only be used to send a binary file "as-is"

I think we can use sendfile() in ftplib.py though .
I'll open a ticket for that.

----------

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

From report at bugs.python.org  Fri Dec  9 06:21:53 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Dec 2011 05:21:53 +0000
Subject: [issue13563] Make use of with statement in ftplib
Message-ID: <1323408112.97.0.52252786609.issue13563@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Patch in attachment.

----------
files: ftplib.patch
keywords: patch
messages: 149074
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Make use of with statement in ftplib
versions: Python 3.3
Added file: http://bugs.python.org/file23889/ftplib.patch

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

From report at bugs.python.org  Fri Dec  9 07:08:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Dec 2011 06:08:50 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323406351.42.0.655415580211.issue13559@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o-SiEQhM1yK0BKg2dvNJ10i-d=1+8KkJzXQUWaV3D=_nA@mail.gmail.com>


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

2011/12/8 Giampaolo Rodola' <report at bugs.python.org>:
>
> Giampaolo Rodola' <g.rodola at gmail.com> added the comment:
>
> This is not possible for two reasons:
>
> - on most POSIX systems, sendfile() works with mmap-like ("regular") files only, while HTTPConnection.send() accepts any file-like object as long as it provides a read() method
>
> - after read()ing a chunk of data from the file and before send()ing it over the socket, the data can be subject to an intermediate conversion (datablock.encode("iso-8859-1")):
> http://hg.python.org/cpython/file/87c6be1e393a/Lib/http/client.py#l839
> ...whereas sendfile() can only be used to send a binary file "as-is"

I presume you could check for a binary mode, though? Also, you can
catch EINVAl on invalid fds.

----------

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

From report at bugs.python.org  Fri Dec  9 07:56:07 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Dec 2011 06:56:07 +0000
Subject: [issue13564] ftplib and sendfile()
Message-ID: <1323413767.49.0.378147798214.issue13564@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

In attachment.
This is actually just an excuse to store the patch somewhere and possibly collect opinions as I don't really think this should go in because:

- it's UNIX only
- as such, deciding whether using sendfile() should probably be done silently (no explicit argument)
- on the other hand, I don't think it's safe to decide this automatically because:
    - the input fd should be a regular file and it's not clear how to determine this beforehand 
    - in case of disconnection OSError is raised instead of socket.error (minor backward compatibility issue)

----------
files: ftplib-sendfile.patch
keywords: patch
messages: 149076
nosy: giampaolo.rodola
priority: normal
severity: normal
stage: patch review
status: open
title: ftplib and sendfile()
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23890/ftplib-sendfile.patch

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

From report at bugs.python.org  Fri Dec  9 08:00:55 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Dec 2011 07:00:55 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1323414055.38.0.436465743681.issue13559@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

ftplib's sendfile support is not tracked as issue13559.
Considerations I made there should apply here as well.

----------

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

From report at bugs.python.org  Fri Dec  9 08:01:53 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Dec 2011 07:01:53 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1323414113.13.0.95527432745.issue13559@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Ops! I meant issue13564.

----------

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

From report at bugs.python.org  Fri Dec  9 08:08:01 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 09 Dec 2011 07:08:01 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1323414481.44.0.204566717742.issue2775@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Brett, issue 2919 had a patch that merges profile/cProfile for a while now but nobody test it yet.

All I need it someone to download the patch, install it, test it on some random script and tell me if it works. I don't need more.

----------

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

From report at bugs.python.org  Fri Dec  9 09:44:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Dec 2011 08:44:24 +0000
Subject: [issue13547] Clean Lib/_sysconfigdata.py and Modules/_testembed
In-Reply-To: <1323273209.84.0.652920813208.issue13547@psf.upfronthosting.co.za>
Message-ID: <1323420264.86.0.669581625793.issue13547@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I guess this still needs to be fixed for Visual Studio.

----------

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

From report at bugs.python.org  Fri Dec  9 09:47:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Dec 2011 08:47:32 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
In-Reply-To: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>
Message-ID: <1323420452.16.0.689428735446.issue13560@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/issue13560>
_______________________________________

From report at bugs.python.org  Fri Dec  9 10:28:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2011 09:28:41 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RYwky-0008Ay-31@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2a2d0872d993 by Victor Stinner in branch 'default':
Issue #13441: Skip some locales (e.g. cs_CZ and hu_HU) on Solaris to workaround
http://hg.python.org/cpython/rev/2a2d0872d993

----------

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

From report at bugs.python.org  Fri Dec  9 10:53:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 09:53:36 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1323424416.44.0.364150917622.issue12428@psf.upfronthosting.co.za>


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

Brian's patch looks ok to me. There's a missing newline (or two) just before test_main() but that can easily be fixed on commit.

----------
nosy: +pitrou
stage:  -> commit review
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Dec  9 11:05:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 10:05:23 +0000
Subject: [issue13563] Make use of with statement in ftplib
In-Reply-To: <1323408112.97.0.52252786609.issue13563@psf.upfronthosting.co.za>
Message-ID: <1323425123.79.0.766828045608.issue13563@psf.upfronthosting.co.za>


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

The first hunk of the patch doesn't look right: ntransfercmd() is supposed to return the connection but the "with" statement closes it.

----------

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

From report at bugs.python.org  Fri Dec  9 11:11:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 10:11:37 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1323425497.92.0.531929687245.issue13550@psf.upfronthosting.co.za>


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

Tim, do you happen to know what the goal was with the threading._VERBOSE hack and the undocumented _Verbose class?

----------
nosy: +pitrou, tim_one

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

From report at bugs.python.org  Fri Dec  9 11:29:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2011 10:29:16 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RYxhZ-0004df-DB@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7ffe3d304487 by Victor Stinner in branch 'default':
Issue #13441: Enable the workaround for Solaris locale bug
http://hg.python.org/cpython/rev/7ffe3d304487

----------

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

From report at bugs.python.org  Fri Dec  9 11:34:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 10:34:18 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1323426858.61.0.911558019607.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I collected the locale list triggering the mbstowcs() bug thanks my previous commit:

 * hu_HU (ISO8859-2): character U+30000020
 * de_AT (ISO8859-1): character U+30000076
 * cs_CZ (ISO8859-2): character U+30000020
 * sk_SK (ISO8859-2): character U+30000020
 * pl_PL (ISO8859-2): character U+30000020
 * fr_CA (ISO8859-1): character U+30000020

Hum, the bug occurs maybe on all locales... I suppose that all "xx_XX" locales use an encoding different than UTF-8 and that the bug is specific to encodings different than UTF-8.

I don't understand why locale.strxfrm('?') doesn't crash anymore.

----------

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

From report at bugs.python.org  Fri Dec  9 13:05:13 2011
From: report at bugs.python.org (Serg Asminog)
Date: Fri, 09 Dec 2011 12:05:13 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1323432313.11.0.353199681387.issue4352@psf.upfronthosting.co.za>


Serg Asminog <akudovich at gmail.com> added the comment:

dirname = 'A-Za-z\xc4\xd6\xdc\xe4\xf6\xfc\xdf'

Traceback (most recent call last):
  File "D:\temp\python bug\test.py", line 19, in <module>
    file_object, file_path, description = imp.find_module(basename, [dirname])
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character

----------
nosy: +Serg.Asminog
Added file: http://bugs.python.org/file23891/test.py

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

From report at bugs.python.org  Fri Dec  9 13:58:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 12:58:06 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1323435486.48.0.751469348094.issue4352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Serg Asminog: What is your Python version? What is your locale encoding (print(sys.getfilesystemencoding())? What is your Windows version?

----------

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

From report at bugs.python.org  Fri Dec  9 13:58:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 12:58:59 +0000
Subject: [issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64
	Snow Leopard 02 03.x"
Message-ID: <1323435539.17.0.162534043929.issue13565@psf.upfronthosting.co.za>


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

[333/363] test_multiprocessing
Timeout (1:00:00)!
Thread 0x0000000112d0b000:
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 411 in _recv
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 432 in _recv_bytes
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 275 in recv
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/managers.py", line 758 in _callmethod
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/managers.py", line 994 in wait
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_multiprocessing.py", line 734 in f
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/threading.py", line 682 in run
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/threading.py", line 729 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/threading.py", line 702 in _bootstrap

Thread 0x0000000112908000:
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 411 in _recv
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 432 in _recv_bytes
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 275 in recv
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/managers.py", line 758 in _callmethod
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/managers.py", line 994 in wait
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_multiprocessing.py", line 734 in f
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/threading.py", line 682 in run
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/threading.py", line 729 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/threading.py", line 702 in _bootstrap

Thread 0x00007fff7022ccc0:
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 411 in _recv
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 432 in _recv_bytes
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/connection.py", line 275 in recv
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/managers.py", line 758 in _callmethod
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/multiprocessing/managers.py", line 982 in acquire
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_multiprocessing.py", line 833 in test_notify_all
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/case.py", line 440 in run
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/case.py", line 492 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/unittest/runner.py", line 168 in run
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/support.py", line 1368 in _run_suite
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/support.py", line 1402 in run_unittest
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_multiprocessing.py", line 2392 in test_main
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/regrtest.py", line 1221 in runtest_inner
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/regrtest.py", line 907 in runtest
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/regrtest.py", line 710 in main
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/__main__.py", line 13 in <module>
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/runpy.py", line 73 in _run_code
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/runpy.py", line 160 in _run_module_as_main
make: *** [buildbottest] Error 1

command timed out: 3900 seconds without output, attempting to kill
program finished with exit code 2
elapsedTime=9486.934561

----------
components: Library (Lib)
messages: 149089
nosy: haypo
priority: normal
severity: normal
status: open
title: test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Leopard 02 03.x"
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  9 14:00:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 13:00:22 +0000
Subject: [issue11894] test_multiprocessing failure on "AMD64 OpenIndiana 3.x":
	KeyError on id_to_obj[ident] in serve_client()
In-Reply-To: <1303334571.86.0.241463514894.issue11894@psf.upfronthosting.co.za>
Message-ID: <1323435622.04.0.137558831703.issue11894@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I didn't see this failure again since the issue was opened, so I close it as invalid.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Dec  9 14:21:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 13:21:19 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1323436879.72.0.446569511221.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The Solaris buildbot is green, let's close it. I didn't report the bug upstream. Feel free to report it to Oracle!

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

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

From report at bugs.python.org  Fri Dec  9 14:25:04 2011
From: report at bugs.python.org (sbt)
Date: Fri, 09 Dec 2011 13:25:04 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
Message-ID: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

If you pickle an array object on python 3 the typecode is encoded as a unicode string rather than as a byte string.  This makes python 2 reject the pickle.

#########################################

Python 3.3.0a0 (default, Dec  8 2011, 17:56:13) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle, array
>>> pickle.dumps(array.array('i', [1,2,3]), 2)
b'\x80\x02carray\narray\nq\x00X\x01\x00\x00\x00iq\x01]q\x02(K\x01K\x02K\x03e\x86q\x03Rq\x04.'

#########################################

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> pickle.loads(b'\x80\x02carray\narray\nq\x00X\x01\x00\x00\x00iq\x01]q\x02(K\x01K\x02K\x03e\x86q\x03Rq\x04.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Python27\lib\pickle.py", line 1382, in loads
    return Unpickler(file).load()
  File "c:\Python27\lib\pickle.py", line 858, in load
    dispatch[key](self)
  File "c:\Python27\lib\pickle.py", line 1133, in load_reduce
    value = func(*args)
TypeError: must be char, not unicode

----------
components: Library (Lib)
messages: 149092
nosy: sbt
priority: normal
severity: normal
status: open
title: Array objects pickled in 3.x with protocol <=2 are unpickled incorrectly in 2.x
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec  9 14:26:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 13:26:30 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1323437191.0.0.067879275298.issue13566@psf.upfronthosting.co.za>


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


----------
nosy: +alexandre.vassalotti, pitrou

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

From report at bugs.python.org  Fri Dec  9 14:31:17 2011
From: report at bugs.python.org (sbt)
Date: Fri, 09 Dec 2011 13:31:17 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323437477.44.0.583799811722.issue13505@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> sbt, the bug is not that the encoding is inefficient. The problem is we 
> cannot unpickle bytes streams from Python 3 using Python 2.

Ah.  Well you can do it using codecs.encode.

Python 3.3.0a0 (default, Dec  8 2011, 17:56:13) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle, codecs
>>>
>>> class MyBytes(bytes):
...     def __reduce__(self):
...         return codecs.encode, (self.decode('latin1'), 'latin1')
...
>>> pickle.dumps(MyBytes(b"hello"), 2)
b'\x80\x02c_codecs\nencode\nq\x00X\x05\x00\x00\x00helloq\x01X\x06\x00\x00\x00latin1q\x02\x86q\x03Rq\x04.'

Actually, I notice that array objects created by Python 3 are not decodable on Python 2.  See Issue 13566.

----------

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

From report at bugs.python.org  Fri Dec  9 14:42:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 13:42:09 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1323438129.14.0.749630181946.issue2775@psf.upfronthosting.co.za>


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

> Brett, issue 2919 had a patch that merges profile/cProfile for a while 
> now but nobody test it yet.

> All I need it someone to download the patch, install it, test it on
> some random script and tell me if it works. I don't need more.

I don't see any patch there, only a .tgz and two Python files.

----------

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

From report at bugs.python.org  Fri Dec  9 14:44:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Dec 2011 13:44:40 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323438280.79.0.520887157014.issue13549@psf.upfronthosting.co.za>


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

In the first patch I included this example:
+   >>> swapped = []
+   >>> for i in [0, 1, 2]:
+   ...     swapped.append([row[i] for row in mat])
+   ...
+   >>> print swapped
+   [[1, 4, 7], [2, 5, 8], [3, 6, 9]]

Because I applied the following transformation without looking at what expr was (another listcomp in this case):
    res = [expr for elem in seq]
==>
   res = []
   for elem in seq:
       res.append(expr)

If the reader does the same he/she wouldn't have any problem figuring out what is the order of the `for`s, but the second version of the patch only includes a "fully expanded" example:
+   >>> transposed = []
+   >>> for i in range(4):
+   ...     # the following 3 lines implement the nested listcomp
+   ...     transposed_row = []
+   ...     for row in matrix:
+   ...         transposed_row.append(row[i])
+   ...     transposed.append(transposed_row)
+   ...
+   >>> transposed

Here it's easier to confuse the two `for` (not because they are similar, but because there are two of them, whereas in the previous example there's only one).

I added a comment to clarify that the inner loop is the listcomp, but maybe it would be better to show the first example too, followed by the "fully expanded" one, i.e.:

+   [[row[i] for row in mat] for i in range(4)]

+   >>> transposed = []
+   >>> for i in range(4):
+   ...     transposed.append([row[i] for row in mat])
+   ...
+   >>> transposed

+   >>> transposed = []
+   >>> for i in range(4):
+   ...     # the following 3 lines implement the nested listcomp
+   ...     transposed_row = []
+   ...     for row in matrix:
+   ...         transposed_row.append(row[i])
+   ...     transposed.append(transposed_row)
+   ...
+   >>> transposed

The step in the middle shows that in order to get to the "fully expanded" form, it's enough to apply the "usual" listcomp->for+append transformation twice, without worrying about left-to-right vs right-to-left.  Do you think it's worth adding this?

----------

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

From report at bugs.python.org  Fri Dec  9 15:11:01 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Dec 2011 14:11:01 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1323439861.21.0.160594304585.issue13557@psf.upfronthosting.co.za>


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

This is expected and documented: http://docs.python.org/py3k/reference/executionmodel.html#interaction-with-dynamic-features
"Free variables are not resolved in the nearest enclosing namespace, but in the global namespace.", a free variable being a variable "used in a code block but not defined there".
And yes, a list comprehension defines a code block.

Try using exec(code, locals()). It's a good habit anyway to always pass a namespace to exec().

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Fri Dec  9 15:11:52 2011
From: report at bugs.python.org (Serg Asminog)
Date: Fri, 09 Dec 2011 14:11:52 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1323439912.15.0.888386096081.issue4352@psf.upfronthosting.co.za>


Serg Asminog <akudovich at gmail.com> added the comment:

print(sys.getfilesystemencoding())
print(os.name)
print(sys.version)
print(sys.version_info)
print(sys.platform)

-----
mbcs
nt
3.2.2 (default, Sep  4 2011, 09:07:29) [MSC v.1500 64 bit (AMD64)]
sys.version_info(major=3, minor=2, micro=2, releaselevel='final', serial=0)
win32

-----------
Windows 7 64bit

----------

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

From report at bugs.python.org  Fri Dec  9 15:16:18 2011
From: report at bugs.python.org (Serg Asminog)
Date: Fri, 09 Dec 2011 14:16:18 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1323440178.15.0.145071901809.issue4352@psf.upfronthosting.co.za>


Serg Asminog <akudovich at gmail.com> added the comment:

Also 

Traceback (most recent call last):
  File "D:\temp\python bug\test.py", line 20, in <module>
    file_object, file_path, description = imp.find_module(basename, [dirname])
ImportError: No module named mymodule

with python  2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)]

----------

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

From report at bugs.python.org  Fri Dec  9 15:18:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 14:18:36 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1323440316.91.0.113184093539.issue4352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, it's not sys.getfilesystemencoding(), but locale.getpreferredencoding() which is interesting. Can you give me your locale encoding?

----------

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

From report at bugs.python.org  Fri Dec  9 15:20:54 2011
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Fri, 09 Dec 2011 14:20:54 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1323440454.27.0.46617962677.issue13557@psf.upfronthosting.co.za>


Stephan R.A. Deibel <sdeibel at wingware.com> added the comment:

Ah, thanks, there it is... I thought this must be dealt with somewhere but couldn't find it.  Maybe should add something to the 'exec' statement docs http://docs.python.org/py3k/library/functions.html#exec to reference this (from a usability-of-docs standpoint).

BTW, my code already sends the namespaces to exec (from current stack frame; it's part of a debugger) and probably would break other cases to alter this.

Well, anyway, sorry for the invalid bug report...

----------
status: pending -> open

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

From report at bugs.python.org  Fri Dec  9 15:23:59 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 09 Dec 2011 14:23:59 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1323440639.5.0.00598237235239.issue13566@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

The problem is that pickle is calling array.array(u'i',[1,2,3]) and array.array in Python 2 doesn't allow unicode strings as a typecode (typecode is the first argument)

The docs in Python 2 and Py3k doesn't specify the type of the typecode argument of array.array.
In Python 2 it seems that typecode has to be a bytes string.
In Python 3 it seems that typecode has to be a unicode string.

I suggest that array.array be changed in Python 2 to allow unicode strings as a typecode or that pickle detects array.array being called and fixes the call.

----------
nosy: +maniram.maniram

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

From report at bugs.python.org  Fri Dec  9 15:55:45 2011
From: report at bugs.python.org (Serg Asminog)
Date: Fri, 09 Dec 2011 14:55:45 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1323442545.04.0.151822197628.issue4352@psf.upfronthosting.co.za>


Serg Asminog <akudovich at gmail.com> added the comment:

cp1251

----------

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

From report at bugs.python.org  Fri Dec  9 15:58:36 2011
From: report at bugs.python.org (James C. Ahlstrom)
Date: Fri, 09 Dec 2011 14:58:36 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1323442716.49.0.63631935705.issue1757072@psf.upfronthosting.co.za>


James C. Ahlstrom <jahlstr at gmail.com> added the comment:

Problem was reported on 2.7.  I will check in detail this weekend.  Please stand by.

----------

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

From report at bugs.python.org  Fri Dec  9 16:27:03 2011
From: report at bugs.python.org (sbt)
Date: Fri, 09 Dec 2011 15:27:03 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1323444423.89.0.587830819909.issue13566@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> I suggest that array.array be changed in Python 2 to allow unicode strings 
> as a typecode or that pickle detects array.array being called and fixes 
> the call.

Interestingly, py3 does understand arrays pickled by py2.  This appears to be because py2 pickles str using BINSTRING or SHORT_BINSTRING which will unpickle as str on py2 and py3.  py3 pickles str using BINUNICODE which will unpickle as unicode on py2 and str on py3.

I think it would be better to fix this in py3 if possible, but that does not look easy: modifying array.__reduce_ex__ alone would not be enough.

The only thing I can think of is for py3 to grow a "_binstr" type which only supports ascii strings and is special-cased by pickle to be pickled using BINSTRING.  Then array.__reduce_ex__ could be something like:

  def __reduce_ex__(self, protocol):
    if protocol <= 2:
      return array.array, (_binstr(self.typecode), list(self))
    else:
      ...

----------

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

From report at bugs.python.org  Fri Dec  9 16:38:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Dec 2011 15:38:38 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1323445118.82.0.557639351285.issue12428@psf.upfronthosting.co.za>


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

Ezio and I made further minor comments that can be handled by the person doing the commit; I?d like to do it.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Dec  9 16:54:42 2011
From: report at bugs.python.org (Pami Ketolainen)
Date: Fri, 09 Dec 2011 15:54:42 +0000
Subject: [issue13567] HTTPError interface changes / breaks depending on what
	was passed to constructor
Message-ID: <1323446082.73.0.0465562779799.issue13567@psf.upfronthosting.co.za>


New submission from Pami Ketolainen <pami.ketolainen at gmail.com>:

In case of authentication error, HTTPError gets initialized without file object and constructor of addinfourl is not called. This means that url attribute is not set and geturl() (inherited from addinfourl) raises AttributeError.

geturl() is not documented as part of HTTPError interface, so I'm not sure if it is correct to expect it to work. And of course this can be worked around by using the HTTPError.filename which always contains the url passed to constructor.

How ever, I have made a simple patch to fix the missing attribute.


There is also Issue5286 with a patch, which makes the http_error_auth_reqed pass the fp to HTTPError making it a file-like object as stated in the documentation. So that would probably be the correct solution.

IMHO it's a bit bad design, when objects interface changes depending on how it was initialized.

----------
components: Library (Lib)
files: httperror-geturl-fix-2.patch
keywords: patch
messages: 149106
nosy: Keto
priority: normal
severity: normal
status: open
title: HTTPError interface changes / breaks depending on what was passed to constructor
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23892/httperror-geturl-fix-2.patch

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

From report at bugs.python.org  Fri Dec  9 17:18:22 2011
From: report at bugs.python.org (Pami Ketolainen)
Date: Fri, 09 Dec 2011 16:18:22 +0000
Subject: [issue13567] HTTPError interface changes / breaks depending on what
	was passed to constructor
In-Reply-To: <1323446082.73.0.0465562779799.issue13567@psf.upfronthosting.co.za>
Message-ID: <1323447502.63.0.0841790950875.issue13567@psf.upfronthosting.co.za>


Pami Ketolainen <pami.ketolainen at gmail.com> added the comment:

Patch adapted to 3.3

----------
Added file: http://bugs.python.org/file23893/httperror-geturl-fix-3.patch

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

From report at bugs.python.org  Fri Dec  9 18:00:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Dec 2011 17:00:01 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1323450001.79.0.397594333108.issue3786@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/issue3786>
_______________________________________

From report at bugs.python.org  Fri Dec  9 18:02:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 17:02:02 +0000
Subject: [issue13547] Clean Lib/_sysconfigdata.py and Modules/_testembed
In-Reply-To: <1323273209.84.0.652920813208.issue13547@psf.upfronthosting.co.za>
Message-ID: <1323450122.48.0.706341825142.issue13547@psf.upfronthosting.co.za>


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

None of these two files is generated under Windows (_sysconfigdata.py by design and _testembed because nobody volunteered to do it).

----------

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

From report at bugs.python.org  Fri Dec  9 18:11:07 2011
From: report at bugs.python.org (James C. Ahlstrom)
Date: Fri, 09 Dec 2011 17:11:07 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1323450667.55.0.103263455755.issue1757072@psf.upfronthosting.co.za>


James C. Ahlstrom <jahlstr at gmail.com> added the comment:

I grabbed a 2.7.2 zipfile.py, and my original comments stand.  If there is a "garbage at end of file" patch, I can't find it; please provide a line number or a hint.  The user at yale.edu reports that the patch works.  Here is a diff of my changes.  To test, append some junk to a good zipfile: echo junk >> good.zip, and try reading it.  Let me know if you want me to do anything else; maybe look at 3.2; or email me offline.

*** zipfile.py	2011-12-09 11:25:07.000000000 -0500
--- ../zipfile.py	2011-12-09 05:48:00.000000000 -0500
***************
*** 237,248 ****
          recData = data[start:start+sizeEndCentDir]
          endrec = list(struct.unpack(structEndArchive, recData))
          comment = data[start+sizeEndCentDir:]
! ## Remove       # check that comment length is correct
! ## Remove       if endrec[_ECD_COMMENT_SIZE] == len(comment):
!         # check that the offset to the Central Directory points to a valid item
!         fpin.seek(endrec[_ECD_OFFSET], 0)
!         dat = fpin.read(4)
!         if dat == stringCentralDir:
              # Append the archive comment and start offset
              endrec.append(comment)
              endrec.append(maxCommentStart + start)

----------

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

From report at bugs.python.org  Fri Dec  9 18:16:20 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Dec 2011 17:16:20 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1323450980.39.0.107045646814.issue12567@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Victor, I have these notes I wrote down when I set up the OpenIndiana buildbots. Maybe can be useful to you: (compiling from source)

"""
  * ncurses 5.7: Instalaci?n est?ndar "./configure --with-shared --without-normal --enable-widec --without-cxx-binding". Al curses que viene con OpenIndiana le faltan un par de funciones: "mvwchgat" y "wchgat".

"""

I installed ncurses because the lack of "mvwchgat" and "wchgat".

When compiling Python, I add export "CFLAGS=-I/usr/local/include/ncursesw" to help it to find the right lib.

Hope to be useful.

----------

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

From report at bugs.python.org  Fri Dec  9 18:31:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 17:31:46 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1323451906.47.0.213248621386.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I wrote down when I set up the OpenIndiana buildbots

Hum, please use the issue #13552 for curses issues on OpenIndiana/Solaris.

> ... de funciones: "mvwchgat" y "wchgat"

See issues #3786 and  #13552 for this problem.

> I installed ncurses ... I add export "CFLAGS=-I/usr/local/include/ncursesw"

The curses module is compiled by setup.py, not Makefile. It looks that setup.py ignores CFLAGS. I don't know if setup.py permits to specify such option.

----------

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

From report at bugs.python.org  Fri Dec  9 18:32:06 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Dec 2011 17:32:06 +0000
Subject: [issue13547] Clean Lib/_sysconfigdata.py and Modules/_testembed
In-Reply-To: <1323273209.84.0.652920813208.issue13547@psf.upfronthosting.co.za>
Message-ID: <1323451926.9.0.796326442625.issue13547@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Excellent, closing then.

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

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

From report at bugs.python.org  Fri Dec  9 18:57:23 2011
From: report at bugs.python.org (Gianluigi Tiesi)
Date: Fri, 09 Dec 2011 17:57:23 +0000
Subject: [issue13568] sqlite3 convert_date error with DATE type
Message-ID: <1323453443.17.0.752390748467.issue13568@psf.upfronthosting.co.za>


New submission from Gianluigi Tiesi <sherpya at gmail.com>:

When using the 'DATE' datatype in a sqlite3 db and type converters are enabled the function in sqlite3/dbapi2.py fails

I'm not sure why sqlite3 returns something like 10-JAN-11, but the function expects a ts

example:

import sqlite3
d = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES)
c = d.cursor()
c.execute("create table testdate (t1 date)")
c.execute("insert into testdate values ('now')")
c.execute("select * from testdate")

----------
components: Library (Lib)
messages: 149113
nosy: sherpya
priority: normal
severity: normal
status: open
title: sqlite3 convert_date error with DATE type
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec  9 19:12:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 18:12:58 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1323437477.44.0.583799811722.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323454058.3297.2.camel@localhost.localdomain>


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

> > sbt, the bug is not that the encoding is inefficient. The problem is we 
> > cannot unpickle bytes streams from Python 3 using Python 2.
> 
> Ah.  Well you can do it using codecs.encode.

Great. A bit hackish but functional and not too inefficient (50% average
expansion).

----------

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

From report at bugs.python.org  Fri Dec  9 20:19:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2011 19:19:18 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <E1RZ5yR-0001am-B8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8620e6901e58 by Victor Stinner in branch '3.2':
Issue #5905: time.strftime() is now using the locale encoding, instead of
http://hg.python.org/cpython/rev/8620e6901e58

New changeset bee7694988a4 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #5905: time.strftime() is now using the locale encoding,
http://hg.python.org/cpython/rev/bee7694988a4

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Dec  9 20:19:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 19:19:41 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1323458381.05.0.200651924682.issue5905@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/issue5905>
_______________________________________

From report at bugs.python.org  Fri Dec  9 20:26:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 19:26:31 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
In-Reply-To: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>
Message-ID: <1323458791.19.0.348139259277.issue13560@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed issue #5905 (strptime fails in non-UTF locale). The fix is not enough if the locale is changed in Python.

Update the patch to fix time.strftime() (if wcsftime() is not available).

----------
Added file: http://bugs.python.org/file23894/pyunicode_decodelocale-2.patch

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

From report at bugs.python.org  Fri Dec  9 20:31:37 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 09 Dec 2011 19:31:37 +0000
Subject: [issue6699] IDLE: Warn user about overwriting a file that has a newer
	version on filesystem
In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
Message-ID: <1323459097.58.0.808956149773.issue6699@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The patch won't apply against 3.3a0 because "self.set_saved(1)" became "self.set_saved(True)" in r70054 (da7a120c0478)

After correcting this minor point, the patch works as expected.

----------
nosy: +serwy
versions: +Python 3.3

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

From report at bugs.python.org  Fri Dec  9 20:32:16 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 09 Dec 2011 19:32:16 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1323459136.55.0.571000583478.issue2919@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Dec  9 20:57:43 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Fri, 09 Dec 2011 19:57:43 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
Message-ID: <1323460662.18.0.0684362650144.issue13569@psf.upfronthosting.co.za>


New submission from Nikita Pchelin <nikita.pchelin at gmail.com>:

I've wrote a little application that uses multiprocessing module:
https://github.com/jango/PC/blob/master/pc/pc-example.py

When I run it in my Linux setup, I get the expected output (Python 2.7.1+):
2011-12-09 14:16:29,014 Started Producer 0.
2011-12-09 14:16:29,076 Started Producer 1.
2011-12-09 14:16:29,076 Producer process (0) exited...
2011-12-09 14:16:29,131 Started Producer 2.
2011-12-09 14:16:29,188 Started Producer 3.
2011-12-09 14:16:29,218 Started Producer 4.
2011-12-09 14:16:29,281 Started Producer 5.
2011-12-09 14:16:29,327 Started Producer 6.
2011-12-09 14:16:29,377 Started Producer 7.
2011-12-09 14:16:29,403 Producer process (1) exited...
2011-12-09 14:16:29,412 Started Producer 8.
2011-12-09 14:16:29,504 Started Producer 9.
2011-12-09 14:16:29,528 Producer process (4) exited...
2011-12-09 14:16:29,570 Started Producer 10.
2011-12-09 14:16:29,615 Started Producer 11.
2011-12-09 14:16:29,622 Producer process (3) exited...
2011-12-09 14:16:29,637 Producer process (7) exited...
2011-12-09 14:16:29,653 Producer process (5) exited...
2011-12-09 14:16:29,692 Started Producer 12.
2011-12-09 14:16:29,731 Producer process (12) exited...
2011-12-09 14:16:29,747 Started Producer 13.
2011-12-09 14:16:29,809 Started Producer 14.
2011-12-09 14:16:29,860 Started Producer 15.
2011-12-09 14:16:29,903 Producer process (2) exited...
2011-12-09 14:16:29,905 Started Producer 16.
2011-12-09 14:16:29,918 Producer process (8) exited...
2011-12-09 14:16:29,970 Started Producer 17.
2011-12-09 14:16:30,001 Started Producer 18.
2011-12-09 14:16:30,070 Started Producer 19.
2011-12-09 14:16:30,090 Producer process (11) exited...
2011-12-09 14:16:30,105 Producer process (10) exited...
2011-12-09 14:16:30,137 Started Producer 20.
2011-12-09 14:16:30,152 Producer process (6) exited...
2011-12-09 14:16:30,183 Producer process (9) exited...
2011-12-09 14:16:30,183 Producer process (17) exited...
2011-12-09 14:16:30,251 Started Producer 21.
2011-12-09 14:16:30,288 Started Producer 22.
2011-12-09 14:16:30,308 Producer process (18) exited...
2011-12-09 14:16:30,308 Producer process (20) exited...
2011-12-09 14:16:30,355 Producer process (16) exited...
2011-12-09 14:16:30,380 Started Producer 23.
2011-12-09 14:16:30,436 Started Producer 24.
2011-12-09 14:16:30,472 Started Producer 25.
2011-12-09 14:16:30,480 Producer process (22) exited...
2011-12-09 14:16:30,509 Started Producer 26.
2011-12-09 14:16:30,554 Started Producer 27.
2011-12-09 14:16:30,609 Started Producer 28.
2011-12-09 14:16:30,620 Producer process (14) exited...
2011-12-09 14:16:30,636 Producer process (15) exited...
2011-12-09 14:16:30,660 Started Producer 29.
2011-12-09 14:16:30,667 Producer process (19) exited...
2011-12-09 14:16:30,667 Producer process (13) exited...
2011-12-09 14:16:30,667 Producer process (27) exited...
2011-12-09 14:16:30,750 Started Consumer 0.
2011-12-09 14:16:30,761 --> 0 produces 0.
2011-12-09 14:16:30,776 Producer process (28) exited...
2011-12-09 14:16:30,770 --> 1 produces 10.
2011-12-09 14:16:30,783 --> 4 produces 40.
2011-12-09 14:16:30,797 Started Consumer 1.
2011-12-09 14:16:30,807 --> 3 produces 30.
2011-12-09 14:16:30,816 --> 5 produces 50.
2011-12-09 14:16:30,817 --> 12 produces 120.
2011-12-09 14:16:30,819 --> 2 produces 20.
2011-12-09 14:16:30,826 --> 8 produces 80.
2011-12-09 14:16:30,835 --> 11 produces 110.
2011-12-09 14:16:30,848 --> 10 produces 100.
2011-12-09 14:16:30,849 --> 6 produces 60.
2011-12-09 14:16:30,852 --> 17 produces 170.
2011-12-09 14:16:30,853 --> 9 produces 90.
2011-12-09 14:16:30,859 --> 18 produces 180.
2011-12-09 14:16:30,860 --> 20 produces 200.
2011-12-09 14:16:30,865 --> 16 produces 160.
2011-12-09 14:16:30,866 --> 22 produces 220.
2011-12-09 14:16:30,867 --> 14 produces 140.
2011-12-09 14:16:30,868 --> 15 produces 150.
2011-12-09 14:16:30,869 --> 19 produces 190.
2011-12-09 14:16:30,874 --> 13 produces 130.
2011-12-09 14:16:30,823 Producer process (21) exited...
2011-12-09 14:16:30,812 --> 7 produces 70.
2011-12-09 14:16:30,893 --> 28 produces 280.
2011-12-09 14:16:30,854 Producer process (25) exited...
2011-12-09 14:16:30,894 Started Consumer 2.
2011-12-09 14:16:30,875 --> 27 produces 270.
2011-12-09 14:16:30,905 --> 25 produces 250.
2011-12-09 14:16:30,917 --> 21 produces 210.
2011-12-09 14:16:30,943 Started Consumer 3.
2011-12-09 14:16:31,002 Started Consumer 4.
2011-12-09 14:16:31,049 Started Consumer 5.
2011-12-09 14:16:31,091 Started Consumer 6.
2011-12-09 14:16:31,137 Started Consumer 7.
2011-12-09 14:16:31,197 Producer process (23) exited...
2011-12-09 14:16:31,213 --> 23 produces 230.
2011-12-09 14:16:31,206 Started Consumer 8.
2011-12-09 14:16:31,263 Started Consumer 9.
2011-12-09 14:16:31,275 Producer process (24) exited...
2011-12-09 14:16:31,307 Started Consumer 10.
2011-12-09 14:16:31,322 --> 24 produces 240.
2011-12-09 14:16:31,357 Started Consumer 11.
2011-12-09 14:16:31,386 Started Consumer 12.
2011-12-09 14:16:31,400 Producer process (26) exited...
2011-12-09 14:16:31,432 Started Consumer 13.
2011-12-09 14:16:31,431 --> 26 produces 260.
2011-12-09 14:16:31,476 Started Consumer 14.
2011-12-09 14:16:31,527 Started Consumer 15.
2011-12-09 14:16:31,556 Producer process (29) exited...
2011-12-09 14:16:31,570 Started Consumer 16.
2011-12-09 14:16:31,587 --> 29 produces 290.
2011-12-09 14:16:31,630 Started Consumer 17.
2011-12-09 14:16:31,664 Started Consumer 18.
2011-12-09 14:16:31,714 Started Consumer 19.
2011-12-09 14:16:31,768 Started Consumer 20.
2011-12-09 14:16:31,815 Started Consumer 21.
2011-12-09 14:16:31,847 Started Consumer 22.
2011-12-09 14:16:31,903 Started Consumer 23.
2011-12-09 14:16:31,932 Started Consumer 24.
2011-12-09 14:16:31,981 Started Consumer 25.
2011-12-09 14:16:32,023 Started Consumer 26.
2011-12-09 14:16:32,073 Started Consumer 27.
2011-12-09 14:16:32,121 Started Consumer 28.
2011-12-09 14:16:32,175 Started Consumer 29.
2011-12-09 14:16:32,181 Consumer (0): instance received shutdown call...
2011-12-09 14:16:32,182 Consumer (1): instance received shutdown call...
2011-12-09 14:16:32,185 Consumer (2): instance received shutdown call...
2011-12-09 14:16:32,186 Consumer (3): instance received shutdown call...
2011-12-09 14:16:32,187 Consumer (4): instance received shutdown call...
2011-12-09 14:16:32,188 Consumer (5): instance received shutdown call...
2011-12-09 14:16:32,189 Consumer (6): instance received shutdown call...
2011-12-09 14:16:32,190 Consumer (7): instance received shutdown call...
2011-12-09 14:16:32,191 Consumer (8): instance received shutdown call...
2011-12-09 14:16:32,192 Consumer (9): instance received shutdown call...
2011-12-09 14:16:32,193 Consumer (10): instance received shutdown call...
2011-12-09 14:16:32,194 Consumer (11): instance received shutdown call...
2011-12-09 14:16:32,195 Consumer (12): instance received shutdown call...
2011-12-09 14:16:32,196 Consumer (13): instance received shutdown call...
2011-12-09 14:16:32,197 Consumer (14): instance received shutdown call...
2011-12-09 14:16:32,198 Consumer (15): instance received shutdown call...
2011-12-09 14:16:32,199 Consumer (16): instance received shutdown call...
2011-12-09 14:16:32,201 Consumer (17): instance received shutdown call...
2011-12-09 14:16:32,207 Consumer (18): instance received shutdown call...
2011-12-09 14:16:32,208 Consumer (19): instance received shutdown call...
2011-12-09 14:16:32,209 Consumer (20): instance received shutdown call...
2011-12-09 14:16:32,210 Consumer (21): instance received shutdown call...
2011-12-09 14:16:32,211 Consumer (22): instance received shutdown call...
2011-12-09 14:16:32,212 Consumer (23): instance received shutdown call...
2011-12-09 14:16:32,213 Consumer (24): instance received shutdown call...
2011-12-09 14:16:32,213 Consumer (25): instance received shutdown call...
2011-12-09 14:16:32,214 Consumer (26): instance received shutdown call...
2011-12-09 14:16:32,215 Consumer (27): instance received shutdown call...
2011-12-09 14:16:32,216 Consumer (28): instance received shutdown call...
2011-12-09 14:16:32,217 Consumer (29): instance received shutdown call...
2011-12-09 14:16:32,226 Last call to consumer.
2011-12-09 14:16:32,231 Consumer instance (8) exited...
2011-12-09 14:16:32,274 Last call to consumer.
2011-12-09 14:16:32,276 Consumer instance (9) exited...
2011-12-09 14:16:32,337 Last call to consumer.
2011-12-09 14:16:32,338 Consumer instance (10) exited...
2011-12-09 14:16:32,367 Last call to consumer.
2011-12-09 14:16:32,371 Consumer instance (11) exited...
2011-12-09 14:16:32,399 Last call to consumer.
2011-12-09 14:16:32,404 Consumer instance (12) exited...
2011-12-09 14:16:32,440 Last call to consumer.
2011-12-09 14:16:32,441 Consumer instance (13) exited...
2011-12-09 14:16:32,492 Last call to consumer.
2011-12-09 14:16:32,504 Consumer instance (14) exited...
2011-12-09 14:16:32,539 Last call to consumer.
2011-12-09 14:16:32,540 Consumer instance (15) exited...
2011-12-09 14:16:32,598 Last call to consumer.
2011-12-09 14:16:32,599 Consumer instance (16) exited...
2011-12-09 14:16:32,633 Last call to consumer.
2011-12-09 14:16:32,634 Consumer instance (17) exited...
2011-12-09 14:16:32,679 Last call to consumer.
2011-12-09 14:16:32,687 Consumer instance (18) exited...
2011-12-09 14:16:32,726 Last call to consumer.
2011-12-09 14:16:32,727 Consumer instance (19) exited...
2011-12-09 14:16:32,789 Last call to consumer.
2011-12-09 14:16:32,790 Consumer instance (20) exited...
2011-12-09 14:16:32,820 Last call to consumer.
2011-12-09 14:16:32,833 Consumer instance (21) exited...
2011-12-09 14:16:32,867 Last call to consumer.
2011-12-09 14:16:32,873 Consumer instance (22) exited...
2011-12-09 14:16:32,913 Last call to consumer.
2011-12-09 14:16:32,918 Consumer instance (23) exited...
2011-12-09 14:16:32,936 Last call to consumer.
2011-12-09 14:16:32,940 Consumer instance (0) exited...
2011-12-09 14:16:32,936 Last call to consumer.
2011-12-09 14:16:32,960 Consumer instance (1) exited...
2011-12-09 14:16:32,945 Last call to consumer.
2011-12-09 14:16:32,960 Last call to consumer.
2011-12-09 14:16:32,994 Consumer instance (3) exited...
2011-12-09 14:16:32,991 Last call to consumer.
2011-12-09 14:16:33,015 Consumer instance (25) exited...
2011-12-09 14:16:32,946 Last call to consumer.
2011-12-09 14:16:33,063 Consumer instance (2) exited...
2011-12-09 14:16:33,023 Last call to consumer.
2011-12-09 14:16:33,080 Consumer instance (4) exited...
2011-12-09 14:16:32,989 Consumer instance (24) exited...
2011-12-09 14:16:33,038 Last call to consumer.
2011-12-09 14:16:33,191 Consumer instance (26) exited...
2011-12-09 14:16:33,085 Last call to consumer.
2011-12-09 14:16:33,242 Consumer instance (5) exited...
2011-12-09 14:16:33,147 Last call to consumer.
2011-12-09 14:16:33,265 Consumer instance (28) exited...
2011-12-09 14:16:33,194 Last call to consumer.
2011-12-09 14:16:33,309 Consumer instance (29) exited...
2011-12-09 14:16:33,101 Last call to consumer.
2011-12-09 14:16:33,336 Consumer instance (6) exited...
2011-12-09 14:16:33,085 Last call to consumer.
2011-12-09 14:16:33,380 Consumer instance (27) exited...
2011-12-09 14:16:33,147 Last call to consumer.
2011-12-09 14:16:33,455 Consumer instance (7) exited...

However, when the same is run from Windows (Python 2.7.2), I get a very long and strange exception trace which revolves around pickle.py:
Traceback (most recent call last):
  File "pc-example.py", line 39, in <module>
    pc.start() 
  File "C:\cygwin\home\jango\workspace\pc\pc\pc.py", line 103, in start
    p_proc.start()
  File "C:\Python27\lib\multiprocessing\process.py", line 130, in start
    self._popen = Popen(self)
  File "C:\Python27\lib\multiprocessing\forking.py", line 271, in __init__
    dump(process_obj, to_child, HIGHEST_PROTOCOL)
  File "C:\Python27\lib\multiprocessing\forking.py", line 193, in dump
    ForkingPickler(file, protocol).dump(obj)
  File "C:\Python27\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "C:\Python27\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python27\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Python27\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python27\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 600, in save_list
    self._batch_appends(iter(obj))
  File "C:\Python27\lib\pickle.py", line 636, in _batch_appends
    save(tmp[0])
  File "C:\Python27\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python27\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Python27\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python27\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Python27\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python27\lib\pickle.py", line 396, in save_reduce
    save(cls)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 748, in save_global
    (obj, module, name))
pickle.PicklingError: Can't pickle <type 'thread.lock'>: it's not found as thread.lock
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python27\lib\multiprocessing\forking.py", line 374, in main
    self = load(from_parent)
  File "C:\Python27\lib\pickle.py", line 1378, in load
    return Unpickler(file).load()
  File "C:\Python27\lib\pickle.py", line 858, in load
    dispatch[key](self)
  File "C:\Python27\lib\pickle.py", line 880, in load_eof
    raise EOFError
EOFError

----------
components: Library (Lib)
messages: 149118
nosy: jango
priority: normal
severity: normal
status: open
title: multiprocessing module: Process.start() fails with EOFError: pickle.PicklingError: Can't pickle <type 'thread.lock'>: it's not found as thread.lock
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec  9 21:00:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 20:00:47 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323460662.18.0.0684362650144.issue13569@psf.upfronthosting.co.za>
Message-ID: <1323460847.0.0.861192407016.issue13569@psf.upfronthosting.co.za>


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

Yes, Windows needs to pickle objects which are sent to (or returned from) a child process. Now you should wonder why you are sending a threading lock to the child. Are you sure this is deliberate?

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Fri Dec  9 21:28:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 20:28:07 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1323462487.24.0.803768017997.issue11886@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The FreeBSD 7.2 3.x buildbot is green.

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

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

From report at bugs.python.org  Fri Dec  9 21:28:28 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Fri, 09 Dec 2011 20:28:28 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323460847.0.0.861192407016.issue13569@psf.upfronthosting.co.za>
Message-ID: <CAL8R3cjVgwC_O88GeopHVFjUfjaJSjiWS-dx74rihA3-zJ8uQg@mail.gmail.com>


Nikita Pchelin <nikita.pchelin at gmail.com> added the comment:

I am not sending locks explicetly (i.e. I am not using locks), but I do
pass a Queue object from PC instance to _Consumer and _Producer instances
that get/put values from/to the queue -- this is done deliberately.

2011/12/9 Antoine Pitrou <report at bugs.python.org>

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Yes, Windows needs to pickle objects which are sent to (or returned from)
> a child process. Now you should wonder why you are sending a threading lock
> to the child. Are you sure this is deliberate?
>
> ----------
> nosy: +pitrou
> versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13569>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Dec  9 21:34:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 20:34:45 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <CAL8R3cjVgwC_O88GeopHVFjUfjaJSjiWS-dx74rihA3-zJ8uQg@mail.gmail.com>
Message-ID: <1323462564.3297.3.camel@localhost.localdomain>


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

> I am not sending locks explicetly (i.e. I am not using locks), but I do
> pass a Queue object from PC instance to _Consumer and _Producer instances
> that get/put values from/to the queue -- this is done deliberately.

Is it a Queue.Queue or a multiprocessing.Queue?

----------

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

From report at bugs.python.org  Fri Dec  9 21:48:03 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Fri, 09 Dec 2011 20:48:03 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323462564.3297.3.camel@localhost.localdomain>
Message-ID: <CAL8R3ciQfTyA7CRNX0yG68pk7r=HVr5GdCKHVrffg7KGq9Fudw@mail.gmail.com>


Nikita Pchelin <nikita.pchelin at gmail.com> added the comment:

It's multiprocessing Queue:

from multiprocessing import Process, Queue, Event

----------

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

From report at bugs.python.org  Fri Dec  9 22:12:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Dec 2011 21:12:32 +0000
Subject: [issue13570] Expose faster unicode<->ascii functions in the C-API
Message-ID: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I just ran the telco benchmark ...

  http://www.bytereef.org/mpdecimal/quickstart.html#telco-benchmark

... on _decimal to see how the PEP-393 changes affect the module.
The benchmark reads numbers from a binary file, does some calculations
and prints the result strings to a file.


Average results (10 iterations each):

Python 2.7:            5.87s
Revision 1726fa560112: 6.07s
Revision 7ffe3d304487: 6.56s


The bottleneck in telco.py is the line that writes a Decimal to the
output file:

  outfil.write("%s\n" % t)

The bottleneck in _decimal is (res is ascii):

   PyUnicode_FromString(res);

PyUnicode_DecodeASCII(res) has the same performance.


With this function ...

  static PyObject*
unicode_fromascii(const char* s, Py_ssize_t size)
{
    PyObject *res;
    res = PyUnicode_New(size, 127);
    if (!res)
        return NULL;
    memcpy(PyUnicode_1BYTE_DATA(res), s, size);
    return res;
}

... I get the same performance as with Python 2.7 (5.85s)!


I think it would be really beneficial for C-API users to have
more ascii low level functions that don't do error checking and
are simply as fast as possible.

----------
components: Unicode
messages: 149124
nosy: ezio.melotti, haypo, loewis, skrah
priority: normal
severity: normal
status: open
title: Expose faster unicode<->ascii functions in the C-API
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  9 22:19:39 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 09 Dec 2011 21:19:39 +0000
Subject: [issue10364] IDLE: make .py default added extension on save
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1323465579.52.0.53203419447.issue10364@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This is a duplicate of #4832.

----------
nosy: +serwy

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

From report at bugs.python.org  Fri Dec  9 22:25:50 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 09 Dec 2011 21:25:50 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1323465950.54.0.891950496417.issue11886@psf.upfronthosting.co.za>


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

thank you for this fix.
I agree a posteriori.

----------

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

From report at bugs.python.org  Fri Dec  9 22:30:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 21:30:25 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323460662.18.0.0684362650144.issue13569@psf.upfronthosting.co.za>
Message-ID: <1323466225.33.0.286870971345.issue13569@psf.upfronthosting.co.za>


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

I don't think it's the queue. Try removing the logger instead (or creating it in the child).

----------

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

From report at bugs.python.org  Fri Dec  9 22:37:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2011 21:37:25 +0000
Subject: [issue2979] use_builtin_types in xmlrpc.server
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <E1RZ885-0004hD-Te@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b3c1a504ebc1 by Florent Xicluna in branch 'default':
Closes #2979: add parameter 'use_builtin_types' to the SimpleXMLRPCServer.
http://hg.python.org/cpython/rev/b3c1a504ebc1

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  9 22:46:16 2011
From: report at bugs.python.org (ekorn)
Date: Fri, 09 Dec 2011 21:46:16 +0000
Subject: [issue13543] shlex with string ending in space gives "ValueError: No
	closing quotation"
In-Reply-To: <1323210833.77.0.155317327445.issue13543@psf.upfronthosting.co.za>
Message-ID: <1323467176.02.0.0987846994528.issue13543@psf.upfronthosting.co.za>


ekorn <jonovik at gmail.com> added the comment:

https://github.com/ipython/ipython/issues/1109#issuecomment-3072571
It seems this was an IPython bug due to slight abuse of the shlex module. Closing as invalid; thanks for your help.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Dec  9 23:03:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Dec 2011 22:03:26 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1323468206.2.0.462284605234.issue13502@psf.upfronthosting.co.za>


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

"set to True, either before the wait call or after the wait starts"

----------

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

From report at bugs.python.org  Fri Dec  9 23:06:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Dec 2011 22:06:08 +0000
Subject: [issue13543] shlex with string ending in space gives "ValueError: No
	closing quotation"
In-Reply-To: <1323210833.77.0.155317327445.issue13543@psf.upfronthosting.co.za>
Message-ID: <1323468368.5.0.228104381995.issue13543@psf.upfronthosting.co.za>


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

And just for your information, as far as I know *no one* knows what standard (or model) non-posix mode shlex is based on.

----------

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

From report at bugs.python.org  Fri Dec  9 23:11:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Dec 2011 22:11:08 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1323468668.04.0.33350419984.issue1757072@psf.upfronthosting.co.za>


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

Here's the patch:

http://hg.python.org/cpython/rev/cc3255a707c7/

I thought I remembered getting it in to 2.7.2, but my memory is evidently wrong.  It has been applied, but is not yet in the released version of 2.7.

----------

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

From report at bugs.python.org  Fri Dec  9 23:11:45 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 09 Dec 2011 22:11:45 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1323468705.74.0.701209655303.issue13378@psf.upfronthosting.co.za>


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

Updated with documentation.
Thank you for the review.

I know this does not cover different namespaces in subtree.
But this use case seems very specific. The user could find other means to achieve it.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file23895/issue13378_non_global_namespaces_v3.diff

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

From report at bugs.python.org  Fri Dec  9 23:16:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2011 22:16:44 +0000
Subject: [issue13528] Rework performance FAQ
In-Reply-To: <1323018091.73.0.846706598362.issue13528@psf.upfronthosting.co.za>
Message-ID: <E1RZ8kE-0008AH-JT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eb30f2becb79 by Antoine Pitrou in branch '3.2':
Issue #13528: rework the performance question in the programming FAQ
http://hg.python.org/cpython/rev/eb30f2becb79

New changeset 9fe28f52eaaa by Antoine Pitrou in branch 'default':
Issue #13528: rework the performance question in the programming FAQ
http://hg.python.org/cpython/rev/9fe28f52eaaa

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Dec  9 23:17:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 22:17:19 +0000
Subject: [issue13528] Rework performance FAQ
In-Reply-To: <1323018091.73.0.846706598362.issue13528@psf.upfronthosting.co.za>
Message-ID: <1323469039.79.0.718466191309.issue13528@psf.upfronthosting.co.za>


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

Done.

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

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

From report at bugs.python.org  Fri Dec  9 23:30:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Dec 2011 22:30:54 +0000
Subject: [issue13570] Expose faster unicode<->ascii functions in the C-API
In-Reply-To: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
Message-ID: <1323469854.97.0.693608440159.issue13570@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/issue13570>
_______________________________________

From report at bugs.python.org  Sat Dec 10 00:20:20 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Fri, 09 Dec 2011 23:20:20 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323466225.33.0.286870971345.issue13569@psf.upfronthosting.co.za>
Message-ID: <4EE297B2.7070903@gmail.com>


Nikita Pchelin <nikita.pchelin at gmail.com> added the comment:

Hi Antoine,

* If I don't pass a logger and do print statements instead, works like a 
charm.

* If I getLogger() in the child instead, example fails with the same trace.

However, according to this ( http://docs.python.org/library/logging.html 
): "The logging module is intended to be thread-safe without any special 
work needing to be done by its clients. It achieves this though using 
threading locks; there is one lock to serialize access to the module?s 
shared data, and each handler also creates a lock to serialize access to 
its underlying I/O."

Which is why I assumed I could use logging safely.

Thanks,
Nikita

On 11-12-09 04:30 PM, Antoine Pitrou wrote:
> Antoine Pitrou<pitrou at free.fr>  added the comment:
>
> I don't think it's the queue. Try removing the logger instead (or creating it in the child).
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue13569>
> _______________________________________

----------

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

From report at bugs.python.org  Sat Dec 10 01:23:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Dec 2011 00:23:40 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323460662.18.0.0684362650144.issue13569@psf.upfronthosting.co.za>
Message-ID: <1323476620.95.0.430209740825.issue13569@psf.upfronthosting.co.za>


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

> If I getLogger() in the child instead, example fails with the same trace.

That sounds rather unlikely. Are you sure you don't store the logger in your process' __init__ method? The __init__ method is called in the parent and the process instance is transfered to the child when you call start() on the process.

----------

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

From report at bugs.python.org  Sat Dec 10 01:55:33 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Sat, 10 Dec 2011 00:55:33 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323476620.95.0.430209740825.issue13569@psf.upfronthosting.co.za>
Message-ID: <4EE2AE03.3020401@gmail.com>


Nikita Pchelin <nikita.pchelin at gmail.com> added the comment:

>>Are you sure you don't store the logger in your process' __init__ 
method? The __init__ method is called in the parent and the process 
instance is transfered to the child when you call start() on the process.

To make sure we are on the same page, here is what I changed it to:
https://github.com/jango/PC/blob/test/pc/pc.py

-> lines 47-50 commented out (init of PC class that initialises threads);
-> lines 64, 65, 77, 78 getLogger within the PC class and print some 
messages;
-> lines 59, 61 71, 74 -- None is passed to the constructor of _Consumer 
and _Producer;
-> lines 135, 203 -- children user logger;

With this code, I still get the exception.

On 11-12-09 07:23 PM, Antoine Pitrou wrote:
> Antoine Pitrou<pitrou at free.fr>  added the comment:
>
>> If I getLogger() in the child instead, example fails with the same trace.
> That sounds rather unlikely. Are you sure you don't store the logger in your process' __init__ method? The __init__ method is called in the parent and the process instance is transfered to the child when you call start() on the process.
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue13569>
> _______________________________________

----------

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

From report at bugs.python.org  Sat Dec 10 03:13:35 2011
From: report at bugs.python.org (Mathieu Pasquet)
Date: Sat, 10 Dec 2011 02:13:35 +0000
Subject: [issue1410680] Add 'surgical editing' to ConfigParser
Message-ID: <1323483215.21.0.0473910358426.issue1410680@psf.upfronthosting.co.za>


Mathieu Pasquet <mathieui at mathieui.net> added the comment:

What is the state of that feature, as of today?

----------
nosy: +mathieui

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

From report at bugs.python.org  Sat Dec 10 04:09:32 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 10 Dec 2011 03:09:32 +0000
Subject: [issue13571] Backup files support in IDLE
Message-ID: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

Automatically save files in IDLE's editor which are not saved to backup file(s) (perhaps in .idlerc) every minute.

If IDLE crashes, save all files that are not saved to backup file(s) and then re-raise the error (like a finally statement)

When IDLE detects a backup file make it prompt the user whether (s)he wants to move the backup file to the original file and also have a button to view the backup file and a button to view the original file (both the buttons are in the prompt).

----------
components: IDLE
messages: 149140
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: Backup files support in IDLE

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

From report at bugs.python.org  Sat Dec 10 04:47:43 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Dec 2011 03:47:43 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323488863.42.0.786375924371.issue13549@psf.upfronthosting.co.za>


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

Showing both was the intent of my comment. Since I am about 60:40 on that, I was and am  willing for you, having grabbed and pushed the issue, to drop the half-expanded version if you thought it better. With or without, we have improved this section. But I still think showing the intermediate step adds sufficient extra clarity to be worth the 5 or 6 extra lines. While nested list comps are not scary, they can, as I discovered, be confusing with a rushed reading. Anyone who wants to compress nested append loops should also do it in two steps.

----------

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

From report at bugs.python.org  Sat Dec 10 04:52:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Dec 2011 03:52:09 +0000
Subject: [issue10364] IDLE: make .py default added extension on save
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1323489129.76.0.912553648798.issue10364@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> idle filename extension

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

From report at bugs.python.org  Sat Dec 10 05:01:31 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 10 Dec 2011 04:01:31 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323489691.49.0.469696849164.issue13521@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Sat Dec 10 05:28:37 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 10 Dec 2011 04:28:37 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323491317.35.0.0876975290755.issue13521@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

+1 for atomic and more robust

----------
nosy: +maniram.maniram

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

From report at bugs.python.org  Sat Dec 10 07:32:56 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 10 Dec 2011 06:32:56 +0000
Subject: [issue13571] Backup files support in IDLE
In-Reply-To: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>
Message-ID: <1323498776.07.0.664101561033.issue13571@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
type:  -> feature request
versions: +Python 3.2

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

From report at bugs.python.org  Sat Dec 10 08:03:06 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 10 Dec 2011 07:03:06 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1323500586.96.0.11223323248.issue13378@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
nosy: +effbot

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

From report at bugs.python.org  Sat Dec 10 08:04:26 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 10 Dec 2011 07:04:26 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1323500666.35.0.133046981065.issue13378@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Given that this is a major new feature for the serialiser in ElementTree, I think it's worth asking Fredrik for any comments.

----------

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

From report at bugs.python.org  Sat Dec 10 09:37:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Dec 2011 08:37:06 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1323506226.13.0.0016216328086.issue13453@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


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

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

From grickert at coldstorage.com  Fri Dec  9 17:27:49 2011
From: grickert at coldstorage.com (Gerrat Rickert)
Date: Fri, 9 Dec 2011 11:27:49 -0500
Subject: Dict.update documentation bug
Message-ID: <BB13E4C4D649234F84A01F6DF64BB87F07BF70BA@ccs-ex01.coldstorage.com>

The current docstring for dict.update shows:

========================================================================
====
>>> help(dict.update)
Help on method_descriptor:

update(...)
    D.update(E, **F) -> None.  Update D from dict/iterable E and F.
    If E has a .keys() method, does:     for k in E: D[k] = E[k]
    If E lacks .keys() method, does:     for (k, v) in E: D[k] = v
    In either case, this is followed by: for k in F: D[k] = F[k]

>>>
========================================================================
====

Better, would be something like:

========================================================================
====
update(...)
    D.update(E=None, **F) -> None.  Update D from dict/iterable E and F.
    If E is not None then:
        If E has a .keys() method, does:     for k in E: D[k] = E[k]
        If E lacks .keys() method, does:     for (k, v) in E: D[k] = v

    In either case, this is followed by: for k in F: D[k] = F[k]
========================================================================
====

The current signature states that argument "E" is mandatory, when it is
not.

eg.
>>> d = {}
>>> d.update(mykey={1:2})  # just keywords passed in, no "E"
>>>


I tried subclassing the builtin dict using the current signature as a
guide, 
but my implementation was incorrect since I had assumed there was a
mandatory 
argument, "E".


Regards,
	Gerrat



From report at bugs.python.org  Sat Dec 10 10:43:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Dec 2011 09:43:21 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <4EE2AE03.3020401@gmail.com>
Message-ID: <1323509877.3276.1.camel@localhost.localdomain>


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

> To make sure we are on the same page, here is what I changed it to:
> https://github.com/jango/PC/blob/test/pc/pc.py
> 
> -> lines 47-50 commented out (init of PC class that initialises threads);
> -> lines 64, 65, 77, 78 getLogger within the PC class and print some 
> messages;
> -> lines 59, 61 71, 74 -- None is passed to the constructor of _Consumer 
> and _Producer;
> -> lines 135, 203 -- children user logger;

Ok, can you try to move the getLogger call from _Producer.__init__ to
_Producer.run?
(same for _Consumer)

(note these aren't threads, but processes)

----------

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

From report at bugs.python.org  Sat Dec 10 11:08:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2011 10:08:24 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <E1RZJqw-0000Fq-GC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f82ebf9b3a52 by Florent Xicluna in branch 'default':
Issue #13248: turn 3.2's PendingDeprecationWarning into 3.3's DeprecationWarning (cgi, importlib, nntplib, smtpd).
http://hg.python.org/cpython/rev/f82ebf9b3a52

----------

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

From report at bugs.python.org  Sat Dec 10 11:37:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Dec 2011 10:37:35 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1323513455.54.0.974843796445.issue13453@psf.upfronthosting.co.za>


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

Wow, the error description ("Non-recoverable failure in name resolution") is as useful as a Windows error message.
Ok for the patch.

----------

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

From report at bugs.python.org  Sat Dec 10 12:29:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Dec 2011 11:29:00 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1323516540.82.0.129469244432.issue10408@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

This paper might be of interest:
http://www.siam.org/meetings/alenex05/papers/13gheileman.pdf

Basically, it concludes that most of the time, there's no speedup to be gained from the increased cached locality incurred by linear probing when the input sample differ from a uniform distribution. However, figure 1 shows a clear win with a uniform distribution, and figure 2 shows that even with a non-uniform distribution, there's still a gain as the load factor increases.
So if experiments show measurable improvements, this might be an interesting idea.
However, the problem with linear probing is that the performance will be much more dependent on the input distribution that with quadratic probing/double hashing, so this will definitely degrade with some workloads.

> The problem with linear probing, as noted in the comments, is that it 
> degrades performance quite a lot when the hashing function clusters 
> results. The solution I'm proposing is to apply an *initial* 
> perturbation, by multiplying the hash() with a prime number. 

I fail to see how this would avoid primary clustering: IIUC, you replace the hash function h(k) by h'(k), but you still use linear probing: an empty slot preceded by i filled slots has a probablility (i+1)/N of getting filled next (N being the total number of slots).

----------
nosy: +neologix

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

From report at bugs.python.org  Sat Dec 10 13:03:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Dec 2011 12:03:44 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1323518624.73.0.685634805062.issue11870@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch to help nail this down.

----------
Added file: http://bugs.python.org/file23896/debug_stuck.diff

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

From report at bugs.python.org  Sat Dec 10 13:22:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2011 12:22:47 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <E1RZLsl-0008Si-Ay@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5ba1a22c8988 by Charles-Fran?ois Natali in branch '2.7':
Issue #13453: Catch EAI_FAIL in support.transient_internet.
http://hg.python.org/cpython/rev/5ba1a22c8988

New changeset c998c6f5464b by Charles-Fran?ois Natali in branch '3.2':
Issue #13453: Catch EAI_FAIL in support.transient_internet.
http://hg.python.org/cpython/rev/c998c6f5464b

New changeset 767badea87c3 by Charles-Fran?ois Natali in branch 'default':
Issue #13453: Catch EAI_FAIL in support.transient_internet.
http://hg.python.org/cpython/rev/767badea87c3

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Dec 10 13:57:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Dec 2011 12:57:28 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <1323468206.2.0.462284605234.issue13502@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1+=3+yO_VHrHcZmMUqEa1EpMbLTOYCU2UxawRUxSZ9jA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks, here's a patch updated accordingly.

----------
Added file: http://bugs.python.org/file23897/event_wait_cleared-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -804,8 +804,10 @@
       floating point number specifying a timeout for the operation in seconds
       (or fractions thereof).
 
-      This method returns the internal flag on exit, so it will always return
-      ``True`` except if a timeout is given and the operation times out.
+      This method returns true if and only if the internal flag has been set to
+      true, either before the wait call or after the wait starts, so it will
+      always return ``True`` except if a timeout is given and the operation
+      times out.
 
       .. versionchanged:: 3.1
          Previously, the method always returned ``None``.
diff --git a/Lib/test/lock_tests.py b/Lib/test/lock_tests.py
--- a/Lib/test/lock_tests.py
+++ b/Lib/test/lock_tests.py
@@ -353,6 +353,22 @@
         for r, dt in results2:
             self.assertTrue(r)
 
+    def test_set_and_clear(self):
+        # Issue #13502: check that wait() returns true even when the event is
+        # cleared before the waiting thread is woken up.
+        evt = self.eventtype()
+        results = []
+        N = 5
+        def f():
+            results.append(evt.wait(1))
+        b = Bunch(f, N)
+        b.wait_for_started()
+        time.sleep(0.5)
+        evt.set()
+        evt.clear()
+        b.wait_for_finished()
+        self.assertEqual(results, [True] * N)
+
 
 class ConditionTests(BaseTestCase):
     """
diff --git a/Lib/threading.py b/Lib/threading.py
--- a/Lib/threading.py
+++ b/Lib/threading.py
@@ -408,9 +408,10 @@
     def wait(self, timeout=None):
         self._cond.acquire()
         try:
-            if not self._flag:
-                self._cond.wait(timeout)
-            return self._flag
+            signaled = self._flag
+            if not signaled:
+                signaled = self._cond.wait(timeout)
+            return signaled
         finally:
             self._cond.release()
 

From report at bugs.python.org  Sat Dec 10 14:15:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Dec 2011 13:15:50 +0000
Subject: [issue13570] Expose faster unicode<->ascii functions in the C-API
In-Reply-To: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
Message-ID: <4EE35B06.7060300@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le 09/12/2011 22:12, Stefan Krah a ?crit :
> The bottleneck in _decimal is (res is ascii):
>
>     PyUnicode_FromString(res);
>
> PyUnicode_DecodeASCII(res) has the same performance.
>
>
> With this function ...
>
>    static PyObject*
> unicode_fromascii(const char* s, Py_ssize_t size)
> {
>      PyObject *res;
>      res = PyUnicode_New(size, 127);
>      if (!res)
>          return NULL;
>      memcpy(PyUnicode_1BYTE_DATA(res), s, size);
>      return res;
> }
>
> ... I get the same performance as with Python 2.7 (5.85s)!

The problem is that  unicode_fromascii() is unsafe: it doesn't check 
that the string is pure ASCII. That's why this function is private.

Because of the PEP 383, ASCII and UTF-8 decoders (PyUnicode_DecodeASCII 
and PyUnicode_FromString) have to first scan the input to check for 
errors, and then do a fast memcpy. The scanner of these two decoders is 
already optimized to process the input string word by word (word=the C 
long type), instead of byte by byte, using a bit mask.

--

You can write your own super fast ASCII decoder using two lines:

     res = PyUnicode_New(size, 127);
     memcpy(PyUnicode_1BYTE_DATA(res), s, size);

(this is exactly what unicode_fromascii does)

> I think it would be really beneficial for C-API users to have
> more ascii low level functions that don't do error checking and
> are simply as fast as possible.

It is really important to ensure that a ASCII string doesn't contain 
characters outside [U+0000; U+007F] because many operations on ASCII 
string are optimized (e.g. UTF-8 pointer is shared with the ASCII pointer).

I prefer to not expose such function or someone will use it without 
understanding exactly how dangerous it is.

Martin and other may disagree with me.

Do you know Murphy's Law? :-)
http://en.wikipedia.org/wiki/Murphy%27s_law

----------

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

From report at bugs.python.org  Sat Dec 10 14:33:00 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 10 Dec 2011 13:33:00 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1323523980.26.0.633366143764.issue13559@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Sat Dec 10 14:33:03 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 10 Dec 2011 13:33:03 +0000
Subject: [issue13564] ftplib and sendfile()
In-Reply-To: <1323413767.49.0.378147798214.issue13564@psf.upfronthosting.co.za>
Message-ID: <1323523983.47.0.985775694598.issue13564@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Sat Dec 10 14:33:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Dec 2011 13:33:44 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <E1RZLsl-0008Si-Ay@dinsdale.python.org>
Message-ID: <CAH_1eM0VkAi_KxiONm3jT9qoTczNQ8wrxiw5ahJ=05MymSsf3A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test_poplib failures are likely due to this obvious race:

"""
    def setUp(self):
[...]
        threading.Thread(target=self.server, args=(self.evt,self.sock)).start()
        time.sleep(.1)

[...]
    def server(self, evt, serv):
        serv.listen(5)
"""

If the server thread doesn't call listen() before sleep(.1) returns,
the client will receive ECONNREFUSED (the test fail consistently
without the sleep).
The patch attached fixes this, and also does the same type of cleanup
as for test_telnetlib in #11812.

----------
Added file: http://bugs.python.org/file23898/fix_poplib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_poplib.py b/Lib/test/test_poplib.py
--- a/Lib/test/test_poplib.py
+++ b/Lib/test/test_poplib.py
@@ -320,32 +320,34 @@
     def setUp(self):
         self.evt = threading.Event()
         self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        self.sock.settimeout(3)
+        self.sock.settimeout(60)  # Safety net. Look issue 11812
         self.port = test_support.bind_port(self.sock)
-        threading.Thread(target=self.server, args=(self.evt,self.sock)).start()
-        time.sleep(.1)
+        self.thread = threading.Thread(target=self.server, args=(self.evt,self.sock))
+        self.thread.setDaemon(True)
+        self.thread.start()
+        self.evt.wait()
 
     def tearDown(self):
-        self.evt.wait()
+        self.thread.join()
+        del self.thread  # Clear out any dangling Thread objects.
 
     def server(self, evt, serv):
         serv.listen(5)
+        evt.set()
         try:
             conn, addr = serv.accept()
+            conn.send(b"+ Hola mundo\n")
+            conn.close()
         except socket.timeout:
             pass
-        else:
-            conn.send(b"+ Hola mundo\n")
-            conn.close()
         finally:
             serv.close()
-            evt.set()
 
     def testTimeoutDefault(self):
         self.assertTrue(socket.getdefaulttimeout() is None)
         socket.setdefaulttimeout(30)
         try:
-            pop = poplib.POP3("localhost", self.port)
+            pop = poplib.POP3(HOST, self.port)
         finally:
             socket.setdefaulttimeout(None)
         self.assertEqual(pop.sock.gettimeout(), 30)
@@ -362,7 +364,7 @@
         pop.sock.close()
 
     def testTimeoutValue(self):
-        pop = poplib.POP3("localhost", self.port, timeout=30)
+        pop = poplib.POP3(HOST, self.port, timeout=30)
         self.assertEqual(pop.sock.gettimeout(), 30)
         pop.sock.close()
 

From report at bugs.python.org  Sat Dec 10 14:34:46 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 10 Dec 2011 13:34:46 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1323524086.37.0.481257743854.issue13530@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Sat Dec 10 14:37:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2011 13:37:59 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <E1RZN7l-0004kH-OH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e37a7dc8944e by Victor Stinner in branch 'default':
Issue #11886: Fix also test_time for the non-DST timezone name (EST/AEST)
http://hg.python.org/cpython/rev/e37a7dc8944e

----------

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

From report at bugs.python.org  Sat Dec 10 14:44:23 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Sat, 10 Dec 2011 13:44:23 +0000
Subject: [issue13569] multiprocessing module: Process.start() fails with
	EOFError: pickle.PicklingError: Can't pickle <type
	'thread.lock'>: it's not found as thread.lock
In-Reply-To: <1323509877.3276.1.camel@localhost.localdomain>
Message-ID: <4EE36235.8070701@gmail.com>


Nikita Pchelin <nikita.pchelin at gmail.com> added the comment:

>> (note these aren't threads, but processes)
Fair enough, I should be more careful with terminology.

 > Ok, can you try to move the getLogger call from _Producer.__init__ 
to,> _Producer.run?,> (same for _Consumer)

Yes, that seems to work fine. One thing, however, that this would mean 
that I would have to declare logger in any method outside of __init__, 
like in shutdown()  for example.

----------

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

From report at bugs.python.org  Sat Dec 10 14:47:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Dec 2011 13:47:29 +0000
Subject: [issue13572] import _curses fails because of
	UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on
	ARM Ubuntu 3.x
Message-ID: <1323524849.05.0.773120918069.issue13572@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/143/steps/test/logs/stdio
---
test test_curses crashed -- Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/regrtest.py", line 1214, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_curses.py", line 23, in <module>
    curses = import_module('curses')
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/support.py", line 105, in import_module
    return importlib.import_module(name)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/__init__.py", line 123, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 840, in _gcd_import
    loader.load_module(name)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 466, in load_module
    return self._load_module(fullname)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 170, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 371, in _load_module
    exec(code_object, module.__dict__)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/curses/__init__.py", line 13, in <module>
    from _curses import *
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 190, in inner
    return method(self, name, *args, **kwargs)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 126, in wrapper
    module = fxn(*args, **kwargs)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 139, in wrapper
    module = fxn(self, *args, **kwargs)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/importlib/_bootstrap.py", line 574, in load_module
    return imp.load_dynamic(fullname, self._path)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb5 in position 0: invalid start byte
---

The locale encoding is UTF-8 (LANG=en_US.UTF-8), Python directory is /var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build.

Full header:
---
make buildbottest TESTOPTS= TESTPYTHONOPTS= TESTTIMEOUT=3600
 in dir /var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build (timeout 3900 secs)
 watching logfiles {}
 argv: ['make', 'buildbottest', 'TESTOPTS=', 'TESTPYTHONOPTS=', 'TESTTIMEOUT=3600']
 environment:
  HOME=/var/lib/buildbot
  LANG=en_US.UTF-8
  LOGNAME=buildbot
  MAIL=/var/mail/buildbot
  PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
  PWD=/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build
  SHELL=/bin/sh
  SPEECHD_PORT=6678
  TERM=linux
  USER=buildbot
  XDG_SESSION_COOKIE=559ce1e92f80d0de13b3936e4c1475f9-29.919136-1746652091
 closing stdin
 using PTY: False
---

In Unicode, U+00B5 is ? (micro sign).

Add Barry, the owner of the buildbot, to the nosy list. Add Brett to the nosy, even if I don't think that the problem comes from the importlib.

----------
components: Library (Lib), Unicode
messages: 149155
nosy: barry, brett.cannon, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: import _curses fails because of UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on ARM Ubuntu 3.x
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 10 14:51:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Dec 2011 13:51:34 +0000
Subject: [issue13572] import _curses fails because of
	UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on
	ARM Ubuntu 3.x
In-Reply-To: <1323524849.05.0.773120918069.issue13572@psf.upfronthosting.co.za>
Message-ID: <1323525094.27.0.177903508945.issue13572@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The compilation of the module failed for the same reason:

building '_curses' extension
gcc -pthread -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -DHAVE_NCURSESW=1 -I/usr/include/ncursesw -IInclude -I. -I./Include -I/usr/include/arm-linux-gnueabi -I/usr/local/include -I/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build -c /var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Modules/_cursesmodule.c -o build/temp.linux-armv7l-3.3-pydebug/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Modules/_cursesmodule.o
gcc -pthread -shared build/temp.linux-armv7l-3.3-pydebug/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Modules/_cursesmodule.o -L/usr/lib/arm-linux-gnueabi -L/usr/local/lib -lncursesw -o build/lib.linux-armv7l-3.3-pydebug/_curses.cpython-33dm.so
*** WARNING: importing extension "_curses" failed with <class 'UnicodeDecodeError'>: 'utf8' codec can't decode byte 0xb5 in position 0: invalid start byte

----------

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

From report at bugs.python.org  Sat Dec 10 14:53:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Dec 2011 13:53:16 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <CAH_1eM0VkAi_KxiONm3jT9qoTczNQ8wrxiw5ahJ=05MymSsf3A@mail.gmail.com>
Message-ID: <CAH_1eM3H4tjoQJ5tv32arX9j2ZARCXyPXwKbCo4ARFNW5O64rQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

And I assume that the test_telnetlib failure on the OpenIndiana
buildbot is due to a broken name resolution service, as in issue
#11812.
Here's a patch bumping the timeout to 60s, which should be enough to
resolve "localhost"...

----------
Added file: http://bugs.python.org/file23899/test_telnetlib_broken_nss.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_telnetlib.py b/Lib/test/test_telnetlib.py
--- a/Lib/test/test_telnetlib.py
+++ b/Lib/test/test_telnetlib.py
@@ -95,7 +95,7 @@
     self.evt = threading.Event()
     self.dataq = Queue.Queue()
     self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-    self.sock.settimeout(3)
+    self.sock.settimeout(60)  # Safety net. Look issue 11812
     self.port = test_support.bind_port(self.sock)
     self.thread = threading.Thread(target=server, args=(self.evt,self.sock, self.dataq))
     self.thread.start()

From report at bugs.python.org  Sat Dec 10 14:58:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Dec 2011 13:58:13 +0000
Subject: [issue13572] import _curses fails because of
	UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on
	ARM Ubuntu 3.x
In-Reply-To: <1323524849.05.0.773120918069.issue13572@psf.upfronthosting.co.za>
Message-ID: <1323525493.94.0.885109396416.issue13572@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem comes maybe from the name of a curses key, keyname(). PyInit__curses() gets the name of all keys (KEY_MIN..KEY_MAX).

----------

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

From report at bugs.python.org  Sat Dec 10 15:16:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 10 Dec 2011 14:16:46 +0000
Subject: [issue13570] Expose faster unicode<->ascii functions in the C-API
In-Reply-To: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
Message-ID: <1323526606.88.0.0464919468634.issue13570@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> I prefer to not expose such function or someone will use it without
> understanding exactly how dangerous it is.

OK. - I'm afraid that I made an error in the benchmarks, since I
accidentally used a changed version of telco.py, namely:

    # t is a Decimal
    outfil.write("%s\n" % t) # original version
    ...

    outfil.write(str(t))     # changed version runs 
    outfil.write('\n')       # faster since PEP-393
    ...

Since PEP-393 the changed version with two calls to write()
runs quite a bit faster than the original. For Python-3.2
and 2.7 the original runs faster.

Do you have an idea what could cause this?

----------

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

From report at bugs.python.org  Sat Dec 10 15:23:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Dec 2011 14:23:58 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1323527038.98.0.0278460834766.issue13502@psf.upfronthosting.co.za>


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

LGTM.

----------

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

From report at bugs.python.org  Sat Dec 10 16:43:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 15:43:12 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323531792.84.0.917113672208.issue13544@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo, rhettinger

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

From report at bugs.python.org  Sat Dec 10 16:52:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 15:52:17 +0000
Subject: [issue13525] Tutorial: Example of Source Code Encoding triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1323532337.3.0.144712810592.issue13525@psf.upfronthosting.co.za>


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

Thanks for the detailed bug report.  I thought the normalization performed by the codec lookup system would convert 'cp-1252' to 'cp1252' (its ?real? name, i.e. the name of the module implementing the codec), but it does not.  I?m +1 to removing the hyphen in the example, then.

> Python raises the following exception:
> SyntaxError: encoding problem: with BOM
I reproduced this and it?s surprising.  Maybe there is a bug with error reporting here.

> Alternatively a totally other example as for Python 2.7 would be nice too
This file has seen different changes in 2.7 and 3.2, given that the default encoding is different in 3.x.  I?ll check the history and upload a patch here to get your feedback.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec 10 16:57:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 15:57:47 +0000
Subject: [issue13537] Namedtuple instances can't be pickled in a daemonized
	process
In-Reply-To: <1323174502.67.0.202903753382.issue13537@psf.upfronthosting.co.za>
Message-ID: <1323532667.83.0.456454248931.issue13537@psf.upfronthosting.co.za>


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

Confirmed (3.2):

>>> def func():
...     t = collections.namedtuple('t', 'a')
...     instance = t(1)
...     print(instance)
...     return pickle.dumps(instance)

>>> func()
t(a=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in func
_pickle.PicklingError: Can't pickle <class '__main__.t'>: attribute lookup __main__.t failed

We may open an enhancement request to suggest that the error message include the qualname, but otherwise this is not a bug.

----------
nosy: +eric.araujo
stage:  -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Sat Dec 10 17:03:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:03:27 +0000
Subject: [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323533007.36.0.551798983157.issue13538@psf.upfronthosting.co.za>


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

A note in the docs (without note/warning directives, just a note) and maybe the docstring would be good.  It should better explain that str has two uses: converting anything to a str (using __str__ or __repr__), decode buffer to str (with encoding and errors arguments).  str(b'') is a case of the first use, not the second (and likewise %s formatting).

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec 10 17:03:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:03:53 +0000
Subject: [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323533033.2.0.420180753689.issue13538@psf.upfronthosting.co.za>


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


----------
title: Docstring of str() and/or behavior -> Improve doc for str(bytesobject)

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

From report at bugs.python.org  Sat Dec 10 17:08:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:08:15 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323533295.72.0.237154965697.issue13521@psf.upfronthosting.co.za>


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

maniram: We try to keep bug reports focused on one thing, and we don?t generally collect votes (we prefer that people vote with patches, tests and messages with content?for example, saying exactly what ?more robust? should be).  Here I think Antoine and Jes?s said +1 to agree that this should be changed even in stable versions.

Raymond: I think I could make the patch, but I?m not sure about testing the new behavior.

----------
nosy: +eric.araujo
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:16:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:16:42 +0000
Subject: [issue13539] Return value missing in calendar.TimeEncoding.__enter__
In-Reply-To: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za>
Message-ID: <1323533802.54.0.870393188755.issue13539@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good catch.  The code doesn?t break because there is a check for None later on (certainly because getlocale may return None, but here __enter__ always returns None).  How did you find this?  If you have a code snippet that reproduces the bug we?ll be able to add it to the test suite before fixing the bug.

----------
nosy: +eric.araujo
stage:  -> test needed
title: A return is missing in TimeEncoding of calendar.py -> Return value missing in calendar.TimeEncoding.__enter__
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13539>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:21:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:21:43 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323534103.81.0.245971140092.issue13540@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +bethard, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:30:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:30:15 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1323534615.79.0.826598801416.issue13550@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

On #13550 I asked Guido about the Thing/_Thing function/class indirection and use of _Verbose; the reply:

> IIRC:
>  
> The design started out this way because it predates new-style classes. When this was put in one
> couldn't subclass extension types, and there were plans/hopes to replace some of the lock types
> with platform-specific built-in versions on some platforms.
>
> Since it is now possible to write subclassable extension types the Thing/_Thing design is no
> longer needed.
> 
> I'm not sure about the _Verbose hacks, if it is deemed not useful I'm fine with letting it go.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13550>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:30:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:30:59 +0000
Subject: [issue13551] pulldom doesn't populate DOM tree
In-Reply-To: <1323304899.35.0.878509919082.issue13551@psf.upfronthosting.co.za>
Message-ID: <1323534659.74.0.785075158734.issue13551@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

So, is there a code or documentation bug in any version?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13551>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:31:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:31:43 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1323534703.63.0.153615501428.issue3786@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:32:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:32:42 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1323534762.47.0.732721069487.issue13557@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would you like to make a doc patch?

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python, eric.araujo
resolution: invalid -> 
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13557>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:33:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:33:16 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1323534796.01.0.248248504641.issue13559@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13559>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:34:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:34:00 +0000
Subject: [issue13561] os.listdir documentation should mention surrogateescape
In-Reply-To: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>
Message-ID: <1323534840.56.0.435639976084.issue13561@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, haypo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13561>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:35:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:35:22 +0000
Subject: [issue13562] Notes about module load path
In-Reply-To: <1323397324.61.0.220189805252.issue13562@psf.upfronthosting.co.za>
Message-ID: <1323534922.74.0.312577490117.issue13562@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch, I will make a few wording/markup editions if you don?t mind and post the edited version.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13562>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:40:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:40:37 +0000
Subject: [issue13564] ftplib and sendfile()
In-Reply-To: <1323413767.49.0.378147798214.issue13564@psf.upfronthosting.co.za>
Message-ID: <1323535237.2.0.568227538082.issue13564@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> deciding whether using sendfile() should probably be done silently (no explicit argument)
As an optimization taking advantage from OS support, I think this should be automatic too.  But if there are too many issues, then explicit argument sounds better.

> the input fd should be a regular file and it's not clear how to determine this beforehand
Calling some function like os.stat that only works with real files?  (not sure os.stat is the right function, just giving an idea)

> in case of disconnection OSError is raised instead of socket.error
PEP 3151!
>>> socket.error, OSError, IOError
(<class 'OSError'>, <class 'OSError'>, <class 'OSError'>)

:)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13564>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:42:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:42:11 +0000
Subject: [issue13567] HTTPError interface changes / breaks depending on what
	was passed to constructor
In-Reply-To: <1323446082.73.0.0465562779799.issue13567@psf.upfronthosting.co.za>
Message-ID: <1323535331.04.0.607957566764.issue13567@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, ezio.melotti
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13567>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:45:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:45:42 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323535542.44.0.485291910448.issue13515@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note sure about icon vs. text (?Warning:?) vs. colors.  I think an icon would be as scary as the current big color boxes.  I like Ezio?s change + Antoine?s indenting suggestion.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13515>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:14:13 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Sat, 10 Dec 2011 17:14:13 +0000
Subject: [issue13562] Notes about module load path
In-Reply-To: <1323397324.61.0.220189805252.issue13562@psf.upfronthosting.co.za>
Message-ID: <1323537253.45.0.605736136288.issue13562@psf.upfronthosting.co.za>


Nam Nguyen <bitsink at gmail.com> added the comment:

That would be great. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13562>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:19:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Dec 2011 17:19:47 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323537587.69.0.132665995199.issue13549@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Having both is fine.

I just noticed that the 3.2 docs are different[0], so I tried to merge them:

3.2 says:
"""
List comprehensions provide a concise way to create lists from sequences. Common applications are to make lists where each element is the result of some operations applied to each member of the sequence, or to create a subsequence of those elements that satisfy a certain condition.
"""
I kept this, changing a few minor things.

In 3.2 the examples are divided and each one has a short description.  I reworked them a bit to make them more clear, and added the description inline as a comment.

The section about nested listcomps is the same, so I didn't change it (but it's now a subsection of the list comprehension section).

This is hopefully the final version.

[0]: http://docs.python.org/py3k/tutorial/datastructures.html#list-comprehensions

----------
Added file: http://bugs.python.org/file23900/issue13549-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13549>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:29:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Dec 2011 17:29:12 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323538152.49.0.387979303333.issue13549@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file23901/issue13549-3-py32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13549>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:36:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Dec 2011 17:36:40 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323538600.66.0.895465684296.issue13515@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I think an icon would be as scary as the current big color boxes.
Especially if I design it.

Georg, is the patch ok if I add a bit of indentation as suggested by Antoine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13515>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:47:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Dec 2011 17:47:43 +0000
Subject: [issue13569] Loggers cannot be pickled
In-Reply-To: <1323460662.18.0.0684362650144.issue13569@psf.upfronthosting.co.za>
Message-ID: <1323539263.2.0.360074924937.issue13569@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> One thing, however, that this would mean 
> that I would have to declare logger in any method outside of __init__, 
> like in shutdown()  for example.

If you only use the logger from the child process, you can declare and store it in the run() method.

That said, this still can be a feature request: allow loggers to be pickled (and unpickled).

----------
nosy: +vinay.sajip
title: multiprocessing module: Process.start() fails with EOFError: pickle.PicklingError: Can't pickle <type 'thread.lock'>: it's not found as thread.lock -> Loggers cannot be pickled
type: behavior -> feature request
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13569>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:59:00 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Sat, 10 Dec 2011 17:59:00 +0000
Subject: [issue13569] Loggers cannot be pickled
In-Reply-To: <1323539263.2.0.360074924937.issue13569@psf.upfronthosting.co.za>
Message-ID: <4EE39CE5.3030408@gmail.com>


Nikita Pchelin <nikita.pchelin at gmail.com> added the comment:

Fair enough. Thanks for help with investigating this issue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13569>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:05:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Dec 2011 18:05:54 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1323535542.44.0.485291910448.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323539651.3287.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Note sure about icon vs. text (?Warning:?) vs. colors.  I think an
> icon would be as scary as the current big color boxes.  I like Ezio?s
> change + Antoine?s indenting suggestion.

An icon will only be scary if you chopse a scary one. A "warning" icon
can simply be an exclamation mark or something (*). It would be less
prominent than a box with a red background, while still clearly
separating the warning from the rest of the text (something which a too
small indentation does not).

Icons or drawings also make text documents less austere, which is a good
thing. There are lots of free icon sets out there, so Ezio doesn't have
to train his art skills ;)

(*) to get an idea, search "exclamation mark icon" with Google Images

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13515>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:43:13 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 10 Dec 2011 18:43:13 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323542593.36.0.559742735038.issue13515@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't really like the combination of the left bar and the background color.  What about making the left bar thicker, and leaving out the background color?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13515>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:49:55 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Dec 2011 18:49:55 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
Message-ID: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The csv.writer needs a special case for floats to print them to full precision.  See http://stackoverflow.com/a/8455313/1001643

In Py2.7, the csv.writer converts floats to strings using str().  This will store 1323494016.8556759 as '1323494016.86' and unnecessarily throw away precision.

In Py3.2, this isn't a problem because float.__str__ now returns full precision, the same a float.__repr__.

----------
assignee: rhettinger
messages: 149179
nosy: rhettinger
priority: normal
severity: normal
status: open
title: csv.writer uses str() for floats instead of repr()
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sat Dec 10 20:40:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2011 19:40:25 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <E1RZSmP-0003XB-Lg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 899a8c7b2310 by Lars Gust?bel in branch 'default':
Issue #5689: Add support for lzma compression to the tarfile module.
http://hg.python.org/cpython/rev/899a8c7b2310

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Sat Dec 10 20:48:55 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 10 Dec 2011 19:48:55 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1323546535.82.0.280972923528.issue5689@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Thanks for the review, guys! I can't close this issue yet because it depends on #6715.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Sat Dec 10 20:52:05 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 19:52:05 +0000
Subject: [issue13574] refresh example in doc for Extending and Embedding
Message-ID: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The example uses PyInstanceObject which is Python 2 only (old-style classes).

http://docs.python.org/dev/extending/newtypes.html#weak-reference-support

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 149183
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: refresh example in doc for Extending and Embedding
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13574>
_______________________________________

From report at bugs.python.org  Sat Dec 10 21:08:15 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 10 Dec 2011 20:08:15 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1323547695.9.0.186037967971.issue5689@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Great stuff! I'll close this issue along with issue 6715 once the buildbot
stuff is all sorted out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Sat Dec 10 21:25:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2011 20:25:11 +0000
Subject: [issue13563] Make use of with statement in ftplib
In-Reply-To: <1323408112.97.0.52252786609.issue13563@psf.upfronthosting.co.za>
Message-ID: <E1RZTTp-0006R9-J1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6cd736239b8a by Giampaolo Rodola' in branch 'default':
fix #13563: make use of with statement in ftplib.py where needed
http://hg.python.org/cpython/rev/6cd736239b8a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13563>
_______________________________________

From report at bugs.python.org  Sat Dec 10 21:26:13 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 10 Dec 2011 20:26:13 +0000
Subject: [issue13563] Make use of with statement in ftplib
In-Reply-To: <1323408112.97.0.52252786609.issue13563@psf.upfronthosting.co.za>
Message-ID: <1323548773.78.0.34368564701.issue13563@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

That's why I nosyed you. Thanks. ;)

----------
assignee:  -> giampaolo.rodola
components: +Library (Lib)
keywords: +easy -patch
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13563>
_______________________________________

From report at bugs.python.org  Sat Dec 10 21:47:18 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 20:47:18 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1323550038.53.0.446229063345.issue13378@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Of course it's better to have someone else to review the patch.
However in this case, I'm not sure it is a major feature.

BTW, I noticed that effbot is currently marked as *inactive* maintainer
http://docs.python.org/devguide/experts.html#stdlib

If it is not an oversight, it means that this issue might wait "an extended period" before receiving a response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Sat Dec 10 21:57:41 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 20:57:41 +0000
Subject: [issue13575] old style classes still alive
Message-ID: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

there are still some leftovers of Python 2 old-style classes.

See attached patch.

----------
components: Interpreter Core, Library (Lib)
files: oldstyle_leftovers.diff
keywords: patch
messages: 149188
nosy: flox
priority: low
severity: normal
stage: patch review
status: open
title: old style classes still alive
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23902/oldstyle_leftovers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:05:25 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 21:05:25 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <1323551125.19.0.514519143239.issue13575@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Off course the leftovers are mainly in comments and documentation.

See also issue #13574.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:07:48 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Dec 2011 21:07:48 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <1323551268.3.0.0147934823098.issue13575@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:10:11 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 10 Dec 2011 21:10:11 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323551411.32.0.351813602181.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Updated patch adding a synchronized argument to scheduler class and updating doc is in attachment.

----------
Added file: http://bugs.python.org/file23903/sched-thread-safe.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:23:21 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Sat, 10 Dec 2011 21:23:21 +0000
Subject: [issue8931] '#' has no affect with 'c' type
In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za>
Message-ID: <1323552201.86.0.850096821839.issue8931@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Attached patch makes Python throw an exception in the case above.
It also adds a test case for that case.

----------
keywords: +patch
nosy: +torsten
Added file: http://bugs.python.org/file23904/issue_8931.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8931>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:36:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 21:36:12 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323552972.51.0.16470375386.issue13248@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I know it won't be committed as-is, but this is the patch with most of the deprecated things removed.

I skipped all the modules where a veto has been pronounced explicitly.

----------
keywords: +patch
Added file: http://bugs.python.org/file23905/issue13248_obsolescence.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:03:48 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 10 Dec 2011 22:03:48 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323554628.4.0.547018520587.issue13544@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Patch with tests.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file23906/13544.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:22:41 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 10 Dec 2011 22:22:41 +0000
Subject: [issue13568] sqlite3 convert_date error with DATE type
In-Reply-To: <1323453443.17.0.752390748467.issue13568@psf.upfronthosting.co.za>
Message-ID: <1323555761.91.0.353555829703.issue13568@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

c.execute("insert into testdate values ('now')")

This works, but you actually are putting string "now" into a field with DATE type. When conversion occurs after retrieving data, there is an error. Also if you use datetime() function


c.execute("insert into testdate values (datetime())")

you'll get an error later during conversion, because python expects date string and will get datetime string. This should work for you:

>>> c.execute("insert into testdate values (date())")
>>> x = c.execute("select * from testdate")
>>> for a in x:
...  print(a)
... 
(datetime.date(2011, 12, 10),)

----------
nosy: +gruszczy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13568>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:31:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 10 Dec 2011 22:31:30 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323556290.75.0.219467830391.issue13521@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Eric, overload "__hash__()" and check that is only called once, while now would be called twice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:41:17 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 10 Dec 2011 22:41:17 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <1323556877.1.0.712190499389.issue13575@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Changes look good.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:41:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 10 Dec 2011 22:41:46 +0000
Subject: [issue13574] refresh example in doc for Extending and Embedding
In-Reply-To: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>
Message-ID: <1323556906.42.0.558344112139.issue13574@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/issue13574>
_______________________________________

From report at bugs.python.org  Sun Dec 11 00:15:13 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 10 Dec 2011 23:15:13 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323558913.36.0.203896654475.issue13505@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I don't really know that much about pickle, but Antoine mentioned that 'bytearray'
works fine going from 3.2 to 2.7.  Given that, can't we just compose 'bytes' with
'bytearray'?  Something like:

Python 3.3.0a0 (default:aab45b904141+, Dec 10 2011, 13:34:41)
[GCC 4.6.2 20111027 (Red Hat 4.6.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
...
>>> class Bytes(bytes):
...    def __reduce__(self):
...       return bytes, (bytearray(self),)
... 
>>> pickletools.dis(pickle.dumps(Bytes(b'abc'), protocol=2))
    0: \x80 PROTO      2
    2: c    GLOBAL     '__builtin__ bytes'
   21: q    BINPUT     0
   23: c    GLOBAL     '__builtin__ bytearray'
   46: q    BINPUT     1
   48: X    BINUNICODE 'abc'
   56: q    BINPUT     2
   58: X    BINUNICODE 'latin-1'
   70: q    BINPUT     3
   72: \x86 TUPLE2
   73: q    BINPUT     4
   75: R    REDUCE
   76: q    BINPUT     5
   78: \x85 TUPLE1
   79: q    BINPUT     6
   81: R    REDUCE
   82: q    BINPUT     7
   84: .    STOP
highest protocol among opcodes = 2
>>> pickle.dumps(Bytes(b'abc'), protocol=2)
b'\x80\x02c__builtin__\nbytes\nq\x00c__builtin__\nbytearray\nq\x01X\x03\x00\x00\x00abcq\x02X\x07\x00\x00\x00latin-1q\x03\x86q\x04Rq\x05\x85q\x06Rq\x07.'

[meadori at motherbrain cpython]$ python
Python 2.7.2 (default, Oct 27 2011, 01:40:22) 
[GCC 4.6.1 20111003 (Red Hat 4.6.1-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
...
>>> pickle.loads(b'\x80\x02c__builtin__\nbytes\nq\x00c__builtin__\nbytearray\nq\x01X\x03\x00\x00\x00abcq\x02X\x07\x00\x00\x00latin-1q\x03\x86q\x04Rq\x05\x85q\x06Rq\x07.')
'abc'

If this method is OK, then the patch is pretty simple.  See attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file23907/issue13505-0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Sun Dec 11 00:34:20 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Sat, 10 Dec 2011 23:34:20 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1323560060.38.0.705380761049.issue11822@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

I offer the attached patch as a starting point to fulfill this feature request.

The patch changes the output to insert the disassembly of local code objects on the referencing line.

As that made the output unreadable to me, I added indentation for the nested code (by 4 spaces, hoping that nobody will nest code 10 levels deep :-)

This results in the following output for the original example:

>>> from dis import dis
>>> dis('[x**2 for x in range(3)]')
  1           0 LOAD_CONST               0 (<code object <listcomp> at 0x7f24a67dde40, file "<dis>", line 1>) 
  1               0 BUILD_LIST               0 
                  3 LOAD_FAST                0 (.0) 
            >>    6 FOR_ITER                16 (to 25) 
                  9 STORE_FAST               1 (x) 
                 12 LOAD_FAST                1 (x) 
                 15 LOAD_CONST               0 (2) 
                 18 BINARY_POWER         
                 19 LIST_APPEND              2 
                 22 JUMP_ABSOLUTE            6 
            >>   25 RETURN_VALUE         
              3 LOAD_CONST               1 ('<listcomp>') 
              6 MAKE_FUNCTION            0 
              9 LOAD_NAME                0 (range) 
             12 LOAD_CONST               2 (3) 
             15 CALL_FUNCTION            1 
             18 GET_ITER             
             19 CALL_FUNCTION            1 
             22 RETURN_VALUE

----------
keywords: +patch
nosy: +torsten
Added file: http://bugs.python.org/file23908/issue11822.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Sun Dec 11 00:44:24 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Dec 2011 23:44:24 +0000
Subject: [issue11822] Improve disassembly to show embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1323560664.7.0.472509361744.issue11822@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________

From report at bugs.python.org  Sun Dec 11 00:52:24 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 10 Dec 2011 23:52:24 +0000
Subject: [issue13569] Loggers cannot be pickled
In-Reply-To: <1323460662.18.0.0684362650144.issue13569@psf.upfronthosting.co.za>
Message-ID: <1323561144.62.0.432430357626.issue13569@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

You shouldn't need to pickle loggers, because loggers just represent where in your application something happens (that being determined by the logger name). The logger name is just a string, and if you need to communicate that across e.g. a process boundary, just sending the name should be enough.

Ideally in a multiprocessing application, logging initialisation should happen after the fork() or CreateProcess() which creates the child process. It's best if loggers are named after the module which logs events (using __name__, which means you don't need to pass the name around - but even if you need to for some reason, you still don't need to pickle a logger or pass it around as a parameter).

You *can* use logging safely in terms of the locks it creates to serialise access to I/O resources and to protect shared data structures, but you still need to understand what's happening and allow for it in your own coding.

To summarise, I don't quite see from the information in this issue why it is desirable to pickle loggers, and the GitHub link doesn't work, so I can't look at Nikita's example, either. So if a better justification isn't available, I would like to close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13569>
_______________________________________

From report at bugs.python.org  Sun Dec 11 01:53:18 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 11 Dec 2011 00:53:18 +0000
Subject: [issue13572] import _curses fails because of
	UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on
	ARM Ubuntu 3.x
In-Reply-To: <1323524849.05.0.773120918069.issue13572@psf.upfronthosting.co.za>
Message-ID: <1323564798.47.0.353938648752.issue13572@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Fails in exactly the same way when built from my shell account using current hg head.  Does not fail on same version of OS on amd64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13572>
_______________________________________

From report at bugs.python.org  Sun Dec 11 01:54:50 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Sun, 11 Dec 2011 00:54:50 +0000
Subject: [issue13569] Loggers cannot be pickled
In-Reply-To: <1323561144.62.0.432430357626.issue13569@psf.upfronthosting.co.za>
Message-ID: <4EE3FF56.3050901@gmail.com>


Nikita Pchelin <nikita.pchelin at gmail.com> added the comment:

Here is a link for example in question:
https://github.com/jango/calculon/blob/master/calculon/calculon.py

Previously, I would pass logger instance from Calculon class to 
_Producer and _Consumer classes. In the current revision, I removed the 
logging completely since I don't feel like it was serving much purpose 
anyway.

On 11-12-10 06:52 PM, Vinay Sajip wrote:
> Vinay Sajip<vinay_sajip at yahoo.co.uk>  added the comment:
>
> You shouldn't need to pickle loggers, because loggers just represent where in your application something happens (that being determined by the logger name). The logger name is just a string, and if you need to communicate that across e.g. a process boundary, just sending the name should be enough.
>
> Ideally in a multiprocessing application, logging initialisation should happen after the fork() or CreateProcess() which creates the child process. It's best if loggers are named after the module which logs events (using __name__, which means you don't need to pass the name around - but even if you need to for some reason, you still don't need to pickle a logger or pass it around as a parameter).
>
> You *can* use logging safely in terms of the locks it creates to serialise access to I/O resources and to protect shared data structures, but you still need to understand what's happening and allow for it in your own coding.
>
> To summarise, I don't quite see from the information in this issue why it is desirable to pickle loggers, and the GitHub link doesn't work, so I can't look at Nikita's example, either. So if a better justification isn't available, I would like to close the issue.
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue13569>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13569>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:16:44 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 01:16:44 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1323566204.11.0.896431240852.issue13448@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/issue13448>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:22:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 01:22:28 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1323566548.91.0.53208998251.issue11564@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/issue11564>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:23:51 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 01:23:51 +0000
Subject: [issue9269] Cannot pickle self-referencing sets
In-Reply-To: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>
Message-ID: <1323566631.97.0.11972423987.issue9269@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/issue9269>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:27:06 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 01:27:06 +0000
Subject: [issue4727] pickle/copyreg doesn't support keyword only arguments in
	__new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <1323566826.89.0.426324406641.issue4727@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/issue4727>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:28:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 01:28:07 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1323566887.02.0.390943583374.issue4331@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/issue4331>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:28:15 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 01:28:15 +0000
Subject: [issue1398] Can't pickle partial functions
In-Reply-To: <1194449250.48.0.936565568427.issue1398@psf.upfronthosting.co.za>
Message-ID: <1323566895.75.0.232719952025.issue1398@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/issue1398>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:54:19 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 01:54:19 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1323568459.66.0.42738504523.issue13448@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am evaluating the use of "__qualname__" in my dtrace probes (issue #13405) and I see things like this:

"""
>>> def a() :
...   class b() :
...     pass
...   return b()
... 
>>> c=a()
>>> c
<__main__.a.<locals>.b object at 0xfe37f3ac>
>>> c.__qualname__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'b' object has no attribute '__qualname__'
>>> a
<function a at 0xfe3800bc>
>>> a.__qualname__
'a'
"""

I guess the class should have a __qualname__ too, haven't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:58:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Dec 2011 01:58:35 +0000
Subject: [issue13576] Handling of broken condcoms in HTMLParser
Message-ID: <1323568714.45.0.610853679425.issue13576@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch adds a few tests about the handling of broken conditional comments (condcoms).
A valid condcom looks like <!--[if ie 6]>...<![endif]-->.
An invalid one looks like <![if ie 6]>...<![endif]>.
This seems a common mistake, and it's found even on popular sites like adobe, linkedin, deviantart.

Currently, HTMLParser calls unknown_decl() passing e.g. 'if ie 6', and if strict=True an error is raised.  With strict=False no error is raised and the unknown declaration is ignored.

The HTML5 specs say:
"""
[After '<!',] If the next two characters are both U+002D HYPHEN-MINUS characters (-), consume those two characters, [...]
Otherwise, this is a parse error. Switch to the bogus comment state.[0]

[Once in the bogus comment state,] Consume every character up to and including the first U+003E GREATER-THAN SIGN character (>) or the end of the file (EOF), whichever comes first. Emit a comment token whose data is the concatenation of all the characters starting from and including the character that caused the state machine to switch into the bogus comment state, up to and including the character immediately before the last consumed character (i.e. up to the character just before the U+003E or EOF character), but with any U+0000 NULL characters replaced by U+FFFD REPLACEMENT CHARACTER characters. (If the comment was started by the end of the file (EOF), the token is empty.)[1]
"""

So, IIUC, '<![if ie 6]>...<![endif]>' should emit a '[if ie 6]' comment, parse the '...' normally, and emit a '[endif]' comment.

However I think it's fine to leave the current behavior for the following reasons:
  1) backward compatibility;
  2) handling broken condcoms in unknown_decl is easier than doing it in handle_comment, where all the other comments are sent;
  3) no one probably cares about them anyway;

[0]: http://www.w3.org/TR/html5/tokenization.html#markup-declaration-open-state
[1]: http://www.w3.org/TR/html5/tokenization.html#bogus-comment-state

----------
assignee: ezio.melotti
components: Library (Lib)
files: issue13576.diff
keywords: patch
messages: 149204
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
stage: commit review
status: open
title: Handling of broken condcoms in HTMLParser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23909/issue13576.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13576>
_______________________________________

From report at bugs.python.org  Sun Dec 11 03:18:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Dec 2011 02:18:14 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1323569894.9.0.279943326318.issue13448@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, it's only class objects that have __name__ and __qualname__, not class instances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Sun Dec 11 04:22:12 2011
From: report at bugs.python.org (Gianluigi Tiesi)
Date: Sun, 11 Dec 2011 03:22:12 +0000
Subject: [issue13568] sqlite3 convert_date error with DATE type
In-Reply-To: <1323453443.17.0.752390748467.issue13568@psf.upfronthosting.co.za>
Message-ID: <1323573732.27.0.345660580541.issue13568@psf.upfronthosting.co.za>


Gianluigi Tiesi <sherpya at gmail.com> added the comment:

I've made a simplified testcase, my problem is importing from a sql dump with dates in the format '10-OCT-11', so if I understand 'DATE' in sqlite is fake and really a string? I have no way to control this behavior if my dump is text?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13568>
_______________________________________

From report at bugs.python.org  Sun Dec 11 04:41:05 2011
From: report at bugs.python.org (Gianluigi Tiesi)
Date: Sun, 11 Dec 2011 03:41:05 +0000
Subject: [issue13568] sqlite3 convert_date error with DATE type
In-Reply-To: <1323453443.17.0.752390748467.issue13568@psf.upfronthosting.co.za>
Message-ID: <1323574865.34.0.640708835345.issue13568@psf.upfronthosting.co.za>


Gianluigi Tiesi <sherpya at gmail.com> added the comment:

So I suppose I have to blame sqlite3 and not fill a bug here

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13568>
_______________________________________

From report at bugs.python.org  Sun Dec 11 05:08:58 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Dec 2011 04:08:58 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323576538.13.0.227426800591.issue13544@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Filip, with the exception of some minor whitespace problems (remember to run 
'make patchcheck') and a missed testcase in 'TestWraps.test_default_update', 
this looks good to me.  I was just about to attach a similar patch.  Here is
an updated patch with those minor fixes.

Nick, does this look OK to you?

----------
nosy: +meador.inge
Added file: http://bugs.python.org/file23910/issue13544-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Sun Dec 11 05:27:05 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Dec 2011 04:27:05 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
Message-ID: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

I was recently experimenting with the new PEP 3155 '__qualname__ implementation and noticed that '__qualname__' is not present on builtin methods and functions:

[meadori at motherbrain cpython]$ ./python 
Python 3.3.0a0 (default:aab45b904141+, Dec 10 2011, 14:53:54) 
[GCC 4.6.2 20111027 (Red Hat 4.6.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> max.__qualname__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'builtin_function_or_method' object has no attribute '__qualname__'
>>> str.strip.__qualname__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'method_descriptor' object has no attribute '__qualname__'

I will work up a patch.

----------
components: Interpreter Core
messages: 149209
nosy: meador.inge, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: __qualname__ is not present on builtin methods and functions
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Sun Dec 11 06:05:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Dec 2011 05:05:54 +0000
Subject: [issue13578] Add subprocess.iter_output() convenience function
Message-ID: <1323579954.88.0.437166836576.issue13578@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

subprocess.check_output() is nice, but doesn't help if you want to process the piped data line-by-line.

Currently, that means you have to do the full Popen dance if you want access to each line of output as it becomes available.

This RFE is for a subprocess.iter_output() module level helper that:
1. Starts the subprocess
2. Yield the individual lines of output as they are produced by the subprocess
3. Cleans up (including checking for errors) at the end

This biggest challenge I have noticed so far in exploring this is how to handle timeouts on Windows - on Unix, select.select() can do the job, but that won't handle pipes in the Windows case.

----------
components: Library (Lib)
messages: 149210
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add subprocess.iter_output() convenience function
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13578>
_______________________________________

From report at bugs.python.org  Sun Dec 11 06:09:38 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 11 Dec 2011 05:09:38 +0000
Subject: [issue13578] Add subprocess.iter_output() convenience function
In-Reply-To: <1323579954.88.0.437166836576.issue13578@psf.upfronthosting.co.za>
Message-ID: <1323580178.39.0.536135992841.issue13578@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13578>
_______________________________________

From report at bugs.python.org  Sun Dec 11 06:38:36 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 05:38:36 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323581916.04.0.448885739763.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Alan, I would open a new issue tracking this one and posting a patch there, if I were you.

Previous DTRACE attempts failed because trying to make everybody happy. I don't want to repeat the mistake.

I am open to modify this code to satisfy systemtap *AFTER* this feature is committed. Same with DTRACE particularities in FreeBSD, MacOS X, etc. You can be sure about my support.

Feel free to clone my mercurial repository and track my code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Dec 11 06:57:46 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 11 Dec 2011 05:57:46 +0000
Subject: [issue6698] IDLE no longer opens only an edit window when configured
	to do so
In-Reply-To: <1250200991.43.0.141209205867.issue6698@psf.upfronthosting.co.za>
Message-ID: <1323583066.72.0.905759438724.issue6698@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a patch to correct the existing bug as-is. 

Should the behavior of IDLE be changed as Tal suggests?

----------
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file23911/issue6698.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6698>
_______________________________________

From report at bugs.python.org  Sun Dec 11 07:03:13 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 06:03:13 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323583393.76.0.0461171903834.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Pending work yet: (documented to avoid forgeting it)

- Performance hit because trying to determine the source line in each function call. To be solved with ?tolerable? memory overhead. Would be acceptable to sacrifice x2/x4 time the pyc filesize (in memory) in order to avoid any runtime performance hit?. That is, a million bytecodes (not a bad program size) could need 2/4 MB. I think it is a good investment if DTRACE becomes performance-transparent.

- Build procedure is flaky. I am asking DTrace developers.

- DTRACE/GCC offset/bitmasks doesn't coincide. Instead of wiring offsets manually, they should be detected at compile time, automatically.

- Add new probes. Suggestions?. What do you want to instrumentalize?. I am thinking about the GIL, module import

- Try the code with "clang" instead of GCC.

- Address pending review comments done by Martin v. L?wis.

- Use PEP 3155.

- Trace C function calls/returns, not only Python ones. The problem here is to know the name of the function, because we can call it in a million different ways. Memorizing the last attribute lookuped is not enough. It seems necessary to memorize some extra metadata at C import.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Dec 11 08:10:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Dec 2011 07:10:50 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
Message-ID: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As the subject line says:

>>> fmt = "{0!a}"
>>> fmt.format(10)
'10'
>>> import string
>>> string.Formatter().format(fmt, 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/string.py", line 180, in format
    return self.vformat(format_string, args, kwargs)
  File "/usr/lib/python3.2/string.py", line 184, in vformat
    result = self._vformat(format_string, args, kwargs, used_args, 2)
  File "/usr/lib/python3.2/string.py", line 210, in _vformat
    obj = self.convert_field(obj, conversion)
  File "/usr/lib/python3.2/string.py", line 245, in convert_field
    raise ValueError("Unknown conversion specifier {0!s}".format(conversion))
ValueError: Unknown conversion specifier a

----------
messages: 149214
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: string.Formatter doesn't understand the !a conversion specifier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sun Dec 11 08:39:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Dec 2011 07:39:11 +0000
Subject: [issue13578] Add subprocess.iter_output() convenience function
In-Reply-To: <1323579954.88.0.437166836576.issue13578@psf.upfronthosting.co.za>
Message-ID: <1323589151.92.0.662989719903.issue13578@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

You can see a version of this here:

https://bitbucket.org/ncoghlan/shell_command/src/2b1988b072aa/shell_command.py#cl-157

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13578>
_______________________________________

From report at bugs.python.org  Sun Dec 11 08:46:42 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Dec 2011 07:46:42 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1323589602.71.0.900749242093.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The PyPI package to prototype the API details is now available:

http://pypi.python.org/pypi/shell_command
http://shell-command.readthedocs.org
https://bitbucket.org/ncoghlan/shell_command/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:47:57 2011
From: report at bugs.python.org (kxroberto)
Date: Sun, 11 Dec 2011 09:47:57 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
Message-ID: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>


New submission from kxroberto <kxroberto at users.sourceforge.net>:

With transition from Python2.5 to Python2.6 on current Debian stable I noticed that the python2.6 executable has now 2x size of python2.5's.
Half of lib-dynload/*  obviously have been embedded into the executable by default. While most of the selections may be somewhat reasonable, I want to protest against static inclusion of _ssl.so, which now draws libssl*.so and libcryto*.so at each Python startup. This module is rarely needed, and the draw is almost as fat as the Python binary itself and those libs are not genarally loaded in the system. Those 2 dependencies solely are against detailed versions even!! See below.
Besides load time and resource wastage, there are now e.g. likely problems with frozen python scripts due to the detailed version deps. (binding with unversioned libssl.so may be ok for future separate _ssl.so module?)


$ ldd /usr/bin/python2.5
        linux-gate.so.1 =>  (0xb78dc000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb78c1000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb78bd000)
        libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb78b8000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7892000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb774c000)
        /lib/ld-linux.so.2 (0xb78dd000)

$ ldd /usr/bin/python2.6
        linux-gate.so.1 =>  (0xb76e7000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb76cc000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb76c8000)
        libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb76c3000)
        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7679000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb751d000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7509000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb74e3000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb739c000)
        /lib/ld-linux.so.2 (0xb76e8000)



Note: "missing files" consumed from lib-dynload/ since Python2.5:

_functools.so 6780
_hashlib.so 11392
math.so 12492
array.so 32432
_socket.so 54228
strop.so 21616
spwd.so 7132
collections.so 21116
unicodedata.so 474792
itertools.so 29684
rgbimg.so 12416
select.so 12816
time.so 16412
grp.so 6868
_locale.so 15760
binascii.so 17344
_weakref.so 4816
cStringIO.so 17076
cPickle.so 68968
syslog.so 5824
_ssl.so 15452
_bisect.so 7568
operator.so 25392
fcntl.so 13536
_struct.so 24832
zlib.so 21708
_random.so 10368


(python2.7 not tested, as it is not available via apt-get so far.)

----------
components: Build, Installation
messages: 149217
nosy: kxroberto
priority: normal
severity: normal
status: open
title: Pre-linkage of CPython >=2.6 binary on Linux too fat (libssl, libcrypto)
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:59:30 2011
From: report at bugs.python.org (maniram maniram)
Date: Sun, 11 Dec 2011 09:59:30 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323597570.6.0.774319886775.issue13580@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

+1

----------
nosy: +maniram.maniram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:08:06 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 11 Dec 2011 10:08:06 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323598086.11.0.051634179336.issue13544@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I didn't know about `make patchcheck`, next time I will use it, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:17:46 2011
From: report at bugs.python.org (maniram maniram)
Date: Sun, 11 Dec 2011 10:17:46 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323598666.74.0.720978844027.issue13544@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Remove the "needs patch" keyword since this bug has a patch.

----------
nosy: +maniram.maniram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:24:35 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Dec 2011 10:24:35 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <1323599075.25.0.39086463157.issue13573@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1 for fixing this.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:42:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Dec 2011 10:42:50 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323600170.82.0.945222018753.issue13544@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Explicitly spelling out __qualname__ like that makes the tests a bit too sensitive to otherwise irrelevant details of the test layout.

I suggest using comparisons like "self.assertEqual(wrapper.__qualname__, f.__qualname__)" and "self.assertNotEqual(wrapper.__qualname__, f.__qualname__)" to make sure they're the same or different as appropriate, without caring about their precise value (this is similar to what the tests already do for "dict_attr")

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Sun Dec 11 12:03:04 2011
From: report at bugs.python.org (kxroberto)
Date: Sun, 11 Dec 2011 11:03:04 +0000
Subject: [issue13479] pickle too picky on re-defined classes
In-Reply-To: <1322211763.06.0.781568755806.issue13479@psf.upfronthosting.co.za>
Message-ID: <1323601384.84.0.642239400816.issue13479@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

Well, "==" whould allow the wanted feature by exception through meta classes for concerned classes:

>>> class X:
... 	a=1
... 
>>> Y=X
>>> class X:
... 	a=1
... 
>>> Y==X
False
>>> class XCompare(type):
... 	def __eq__(self, other):
... 		print "tolerant class __eq__"
... 		return self.__name__ == other.__name__
... 
>>> class X:
... 	__metaclass__ = XCompare
... 	a=1
... 
>>> Y=X
>>> class X:
... 	a=1
... 
>>> Y==X
tolerant class __eq__
True
>>> 


Better than nothing. Its a improvement generally, independently.
But thinking about my acutal use cases and all: It still doesn't satisfy. I don't want to introduce this extra magic on all those classes just for that feature - because when needed, the majority of classes are concerned (see below). One can have only one meta class ... its too tricky and off-road to guess for most programmers ... 

"when in doubt, raise an error": That is IMHO too rigid here, and generally when a feature is then hindered too much. Aren't warnings the right tool for such case? If really rarely there is problem, should it surface easily already during dev & test time?
Compared to the everday life danger of Pythons dynamic attribute access, version incompatibilities, etc. its about a rather harmless issue here.

Now I'd vote for a warnings.warn upon "==" (or old "is") failing , and then an error only when the .__name__ is not matching too. A warning at dev & test time should be enough, when just "==" (or "is") fails. 


I mainly like the tolerance during development: e.g. fast reload style edit-run cycles (reload sometimes improved with special reload fix code), because I noticed that 95% of code changes/bug fixes do not require a full expensive app-restart. This pays off particularly with bigger GUI app development/fixing and similar, where lot of status is accumulated expensively during run time.
But I wished that feature already for a deployed app too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13479>
_______________________________________

From report at bugs.python.org  Sun Dec 11 12:48:35 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 11 Dec 2011 11:48:35 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323604115.36.0.18090014786.issue13544@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Fixed tests.

----------
Added file: http://bugs.python.org/file23912/13544_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:30:15 2011
From: report at bugs.python.org (sbt)
Date: Sun, 11 Dec 2011 13:30:15 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323610215.15.0.0223955627897.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I already have a patch for the descriptor types which lazily calculates the __qualname__.  However test.test_sys also needs fixing because it  tests that these types have expected sizes.

I have not got round to builtin_function_or_method though.

----------
keywords: +patch
nosy: +sbt
Added file: http://bugs.python.org/file23913/descr_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:58:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Dec 2011 13:58:30 +0000
Subject: [issue13574] refresh example in doc for Extending and Embedding
In-Reply-To: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>
Message-ID: <1323611910.81.0.237267780877.issue13574@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13574>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:33:52 2011
From: report at bugs.python.org (sbt)
Date: Sun, 11 Dec 2011 14:33:52 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323614032.71.0.193717592858.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Updated patch which fixes test.test_sys.SizeofTest.  (It also adds __qualname__ to member descriptors and getset descriptors.)

----------
Added file: http://bugs.python.org/file23914/descr_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:21:11 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 16:21:11 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323620471.01.0.909779081488.issue13580@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I see this effect in the stock ubuntu 10.04 python 2.6.

I can't see it in my selfcompiled binaries for Solaris 10 and 2.7 ubuntu.

The reason seems to be that my compilated code uses the python shared libs, while the stock Ubuntu 10.04 python 2.6 is statically linked.

In any case, the shared lib version doesn't link against ssl:

"""
jcea at ubuntu:~$ ldd /usr/local/lib/libpython2.7.so.1.0
	linux-vdso.so.1 =>  (0x00007fff715ff000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5ec3079000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f5ec2e75000)
	libutil.so.1 => /lib/libutil.so.1 (0x00007f5ec2c71000)
	libm.so.6 => /lib/libm.so.6 (0x00007f5ec29ee000)
	libc.so.6 => /lib/libc.so.6 (0x00007f5ec266b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5ec3698000)
"""

Of course, as soon as we use sockets, we will bring SSL in:

"""
Python 2.7.2 (default, Jul 14 2011, 00:30:51) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getpid()
5701
>>> import socket
[...]
jcea at ubuntu:~$ cat /proc/5701/maps|grep -i ssl
7f2f467cd000-7f2f46818000 r-xp 00000000 fc:0a 131554                     /lib/libssl.so.0.9.8
7f2f46818000-7f2f46a17000 ---p 0004b000 fc:0a 131554                     /lib/libssl.so.0.9.8
7f2f46a17000-7f2f46a19000 r--p 0004a000 fc:0a 131554                     /lib/libssl.so.0.9.8
7f2f46a19000-7f2f46a1e000 rw-p 0004c000 fc:0a 131554                     /lib/libssl.so.0.9.8
7f2f46a47000-7f2f46a4f000 r-xp 00000000 fc:0a 403582                     /usr/local/lib/python2.7/lib-dynload/_ssl.so
7f2f46a4f000-7f2f46c4e000 ---p 00008000 fc:0a 403582                     /usr/local/lib/python2.7/lib-dynload/_ssl.so
7f2f46c4e000-7f2f46c4f000 r--p 00007000 fc:0a 403582                     /usr/local/lib/python2.7/lib-dynload/_ssl.so
7f2f46c4f000-7f2f46c50000 rw-p 00008000 fc:0a 403582                     /usr/local/lib/python2.7/lib-dynload/_ssl.so
"""

Importing "socket" will bring SSL in with any python at least since 2.3 (the older version I can try now).

In any case Python 2.6 is closed. Any change will need to address 2.7 and up. I would say that 3.1 is off too, and possibly 3.2 too.

PS: Can you try to compile python using the shared lib?.

----------
nosy: +jcea
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:26:02 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 11 Dec 2011 16:26:02 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1323620762.23.0.455093652792.issue13579@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:26:32 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 16:26:32 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323620792.6.0.378075493371.issue13577@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/issue13577>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:32:34 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 11 Dec 2011 16:32:34 +0000
Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit
	Window
In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>
Message-ID: <1323621154.58.0.918857910687.issue8900@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is a patch to fix the bug.

When selecting "Open" from the File Menu, "ishanderrunning" is empty. Unbind/Bind requests are handled synchronously.

When pressing "Ctrl+O", "ishandlerrunning" is no longer empty, and the actual bind/unbind events get appended to "doafterhandle". 

The original code was running these bind/unbind events in REVERSE order by using "pop", so unbind requests were being made (and causing the error) before the proper bind request.

----------
keywords: +patch
nosy: +serwy
versions: +Python 3.2, Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file23915/issue8900.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8900>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:46:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Dec 2011 16:46:55 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323622015.69.0.231162462674.issue13580@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So isn't this saying that this is a problem with the distribution packaging and not with CPython itself?

----------
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:48:01 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 11 Dec 2011 16:48:01 +0000
Subject: [issue13569] Loggers cannot be pickled
In-Reply-To: <1323460662.18.0.0684362650144.issue13569@psf.upfronthosting.co.za>
Message-ID: <1323622081.93.0.00650757127348.issue13569@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

So, if I understand your last comment correctly, it's OK to close this issue, so I'm going to. If I misunderstood, then please feel free to reopen.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13569>
_______________________________________

From report at bugs.python.org  Sun Dec 11 18:20:05 2011
From: report at bugs.python.org (Kasun Herath)
Date: Sun, 11 Dec 2011 17:20:05 +0000
Subject: [issue13559] Use sendfile where possible in httplib
In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za>
Message-ID: <1323624005.09.0.515039798433.issue13559@psf.upfronthosting.co.za>


Changes by Kasun Herath <kasunh01 at gmail.com>:


----------
nosy: +kasun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13559>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:07:23 2011
From: report at bugs.python.org (kxroberto)
Date: Sun, 11 Dec 2011 18:07:23 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323626843.68.0.0930638293538.issue13580@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

"Of course, as soon as we use sockets, we will bring SSL in"

Indeed, as it is now. 
Suggestions:


* urllib.URLOpener.open_https  shall always exist, but fail on runtime.  non-existance with strange "AttributeError" is inelegant..bogus.
Note: concept of late import ftplib, .. is otherwise ok in urllib. same style shall be used for ssl on demand. see python-Bugs-1046077)

* httplib.HTTPSConnection.connect shall late-import ssl

* httplib.HTTPSConnection,HTTPS,FakeSocket shall always exist but error on runtime if ssl is not available; same reason as with open_https

(* httplib.test already late-imports ssl)

* imaplib.IMAP4_SSL.ssl,open shall late-import ssl

* smtplib.starttls should late-import ssl

* smtplib.SMTP_SSL._get_socket  should late-import ssl

* smtplib.SSLFakeFile shall always exist (same reason as with open_https)

* poplib.POP3_SSL.__init__ shall late-import ssl

* deprecated socket.ssl() shall late-import _ssl/ssl (and possibly      RAND_add, RAND_egd, RAND_status too if they need to exist globally for compabtibilty; constants to be entered fix into socket or _socket; sslerror perhaps a builtin in _socket, which _ssl then uses )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:17:54 2011
From: report at bugs.python.org (sbt)
Date: Sun, 11 Dec 2011 18:17:54 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323627474.18.0.266166234145.issue13505@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> I don't really know that much about pickle, but Antoine mentioned that 'bytearray'
> works fine going from 3.2 to 2.7.  Given that, can't we just compose 'bytes' with
> 'bytearray'?

Yes, although it would only work for 2.6 and 2.7.

codecs.encode() seems to be available back to 2.4 and codecs.latin_1_encode() back to at least 2.0.  They also produce more compact pickles, particularly codecs.latin_1_encode().

>>> class Bytes(bytes):
...     def __reduce__(self):
...         return latin_1_encode, (latin_1_decode(self),)
...
[70922 refs]
>>> pickletools.dis(pickle.dumps(Bytes(b'abc'), 2))
    0: \x80 PROTO      2
    2: c    GLOBAL     '_codecs latin_1_encode'
   26: q    BINPUT     0
   28: X    BINUNICODE 'abc'
   36: q    BINPUT     1
   38: K    BININT1    3
   40: \x86 TUPLE2
   41: q    BINPUT     2
   43: \x85 TUPLE1
   44: q    BINPUT     3
   46: R    REDUCE
   47: q    BINPUT     4
   49: .    STOP
highest protocol among opcodes = 2

Only worry is that codecs.latin_1_encode.__module__ is '_codecs', and _codecs is undocumented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:19:46 2011
From: report at bugs.python.org (kxroberto)
Date: Sun, 11 Dec 2011 18:19:46 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323627586.66.0.144349437254.issue13580@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

"Can you try to compile python using the shared lib"

yes I can try lot of things, but I'd need to do this on many machines. Yet I didn't create this issue for some local purpose ;-)  
99% of Pythons are installed by apt-get, .msi etc.
And now this turns out as bigger issue with the early import of ssl in those mentioned locations.

(A little surprising for me is that the Python2.6 of current Debian stable shall already be outdated. Its the new thing here ;-)  
Hope for Python 2.7 not beeing outdated so soon. Py3 has already 4 version - who can use Py3 in real word? Is the Python dev team too fast for reality? ;-) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:26:29 2011
From: report at bugs.python.org (Christopher the Magnificent)
Date: Sun, 11 Dec 2011 18:26:29 +0000
Subject: [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
Message-ID: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent <ultimate.mac.fanatic at gmail.com>:

observe help(type) and type.__doc__ in Python 3.1:


>>> help(type)
Help on class type in module builtins:

class type(object)
 |  type(object) -> the object's type
 |  type(name, bases, dict) -> a new type
 |  
 |  Methods defined here:
 |  
 |  __call__(...)
 |      x.__call__(...) <==> x(...)
 |  
 |  __delattr__(...)
 |      x.__delattr__('name') <==> del x.name
 |  
 |  __getattribute__(...)
 |      x.__getattribute__('name') <==> x.name
 |  
 |  __init__(...)
 |      x.__init__(...) initializes x; see x.__class__.__doc__ for signature
 |  
 |  __instancecheck__(...)
 |      __instancecheck__() -> check if an object is an instance
 |  
 |  __repr__(...)
 |      x.__repr__() <==> repr(x)
 |  
 |  __setattr__(...)
 |      x.__setattr__('name', value) <==> x.name = value
 |  
 |  __subclasscheck__(...)
 |      __subclasschck__ -> check if an class is a subclass
 |  
 |  __subclasses__(...)
 |      __subclasses__() -> list of immediate subclasses
 |  
 |  mro(...)
 |      mro() -> list
 |      return a type's method resolution order
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  __abstractmethods__
 |  
 |  __base__
 |  
 |  __bases__
 |  
 |  __basicsize__
 |  
 |  __dict__
 |  
 |  __dictoffset__
 |  
 |  __flags__
 |  
 |  __itemsize__
 |  
 |  __mro__
 |  
 |  __weakrefoffset__
 |  
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |  
 |  __new__ = <built-in method __new__ of type object at 0x145600>
 |      T.__new__(S, ...) -> a new object with type S, a subtype of T
 |  
 |  __prepare__ = <built-in method __prepare__ of type object at 0x145600>
 |      __prepare__() -> dict
 |      used to create the namespace for the class statement

>>> type.__doc__
"type(object) -> the object's type\ntype(name, bases, dict) -> a new type"
>>> 





observe help(type) and type.__doc__ in Python 3.2:



>>> help(type)
Help on class type in module builtins:

type = <class 'type'>
>>> type.__doc__
"type(object) -> the object's type\ntype(name, bases, dict) -> a new type"
>>> 



It appears that the __doc__ attribute of <class 'type'> is unchanged from Python 3.1 to 3.2, but it is not being displayed by the help function in Python 3.2.

The help function is very important to using Python!  This should be fixed.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 149234
nosy: christopherthemagnificent, docs at python
priority: normal
severity: normal
status: open
title: help() appears to be broken; doesn't display __doc__ for class type when called as help(type)
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13581>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:32:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 18:32:23 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323628343.04.0.321770909559.issue13577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch should add some tests for the added functionality (I'm not sure where, but perhaps test_descr is a good location).

Also, just a nitpick, you can use _PyObject_GetAttrId and the _Py_IDENTIFIER macro instead of interning the "__qualname__" string yourself.

Note that extension (non-builtin) types will need to have their __qualname__ fixed before their methods' __qualname__ is usable:

>>> collections.deque.__qualname__
'deque'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:39:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 18:39:51 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323628791.48.0.868207672571.issue13580@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>From a fresh-compiled Python 2.7:

$ ldd ./python
	linux-vdso.so.1 =>  (0x00007fff85cde000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f772f725000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f772f521000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f772f31e000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f772f09c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f772ed2b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f772f941000)

(same with 3.3)

This is therefore a problem with the Debian package, not with the vanilla Python build (when using default options).

Also, the reason ssl is imported when socket is imported in Python 2 is for compatibility reasons. It doesn't happen in Python 3:

$ grep ssl Lib/socket.py 
$ ldd build/lib.linux-x86_64-3.3-pydebug/_socket.cpython-33dm.so 
	linux-vdso.so.1 =>  (0x00007fffa2f21000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f227ff8f000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f227fc1e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f22803e1000)

Therefore, closing as not a Python bug.

> Is the Python dev team too fast for reality? ;-)

Actually, releasing a new version every 18 months (not counting bugfix releases) makes us fairly conservative (perhaps too much) in the modern software ecosystem ;)

----------
nosy: +pitrou
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:52:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 18:52:45 +0000
Subject: [issue13564] ftplib and sendfile()
In-Reply-To: <1323413767.49.0.378147798214.issue13564@psf.upfronthosting.co.za>
Message-ID: <1323629565.31.0.145887845871.issue13564@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

os.fstat wouldn't work since it succeeds with non-"regular" files, e.g. standard I/O:

>>> os.fstat(0)
posix.stat_result(st_mode=8592, st_ino=5, st_dev=11, st_nlink=1, st_uid=500, st_gid=5, st_size=0, st_atime=1323629303, st_mtime=1323629303, st_ctime=1323628616)

I think the best solution is to call sendfile() and catch OSError, then fallback on the generic loop. However, you must also guard against fileno() failing:

>>> io.BytesIO().fileno()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: fileno

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13564>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:04:40 2011
From: report at bugs.python.org (sbt)
Date: Sun, 11 Dec 2011 19:04:40 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323630280.75.0.282414108054.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Note that extension (non-builtin) types will need to have their 
> __qualname__ fixed before their methods' __qualname__ is usable:
>
> >>> collections.deque.__qualname__
> 'deque'

I'm confused.  Isn't that the expected behaviour?  Since the deque class is not nested inside another class or function, __qualname__ should be the same as __name__, shouldn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:10:16 2011
From: report at bugs.python.org (akira)
Date: Sun, 11 Dec 2011 19:10:16 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1323630616.33.0.39803346987.issue13496@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

Related bug in Java: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Do not consider any change as trivial: http://www.solipsys.co.uk/new/BinarySearchReconsidered.html (the author ran "binary search" coding challenge about 10 years ago http://www.solipsys.co.uk/b_search/ )

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:11:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 19:11:17 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323630280.75.0.282414108054.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323630666.3366.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Note that extension (non-builtin) types will need to have their 
> > __qualname__ fixed before their methods' __qualname__ is usable:
> >
> > >>> collections.deque.__qualname__
> > 'deque'
> 
> I'm confused.  Isn't that the expected behaviour?  Since the deque
> class is not nested inside another class or function, __qualname__
> should be the same as __name__, shouldn't it?

Uh, yes, my bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:21:59 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 11 Dec 2011 19:21:59 +0000
Subject: [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <1323631319.54.0.448651922735.issue13581@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It fails for the same reason as issue1785:

~/python/cpython3.2$ ./python -c "import inspect; inspect.classify_class_attrs(type)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/amauryfa/python/cpython3.2/Lib/inspect.py", line 321, in classify_class_attrs
    obj_via_getattr = getattr(cls, name)
AttributeError: __abstractmethods__

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13581>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:24:39 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 11 Dec 2011 19:24:39 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1323631479.57.0.496370282723.issue1785@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The 'type' object now has the same issue: __abstractmethods__ appears in dir(type) but type.__abstractmethods__ fails with an AttributeError.
See issue13581

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:27:12 2011
From: report at bugs.python.org (kxroberto)
Date: Sun, 11 Dec 2011 19:27:12 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323631632.12.0.414167362859.issue13580@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

"It doesn't happen in Python 3"

Yet the cheap/unnecessary pre-imports of ssl in those other mentioned socket using libs (urllib (cgi!),httplib,smtplib,pop,imap...) exist there. socket is rarely used directly, so not much difference to Py2 in effect overall.
And Python2.7 lives - which is important for the majority of users perhaps.

Thus I'd request to not close this issue so swift. This is IHMO really a point to make python startup significantly faster, with a rather simple means.

Also the linkage of _ssl solely against a detailed version of libssl/libcrypto is still questionable.


"This is therefore a problem with the Debian package"

I'm not into the Python build files. Just to ask/double-check: is that observed _semi_ static link selection (which is good otherwise - somebody must have done surprisingly lots of care) really from Debian or is there maybe a sort of 2nd default option bundle somewhere in Pythons configure? (If really not so I would go for Debian BTS.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:38:11 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 11 Dec 2011 19:38:11 +0000
Subject: [issue13582] IDLE and pythonw.exe stderr problem
Message-ID: <1323632290.53.0.810720020667.issue13582@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Running IDLE on Windows typically uses pythonw.exe. Unfortunately any error messages written to stderr will cause IDLE to terminate abruptly without an error message. This is due to __stderr__ == None.

Attached is a patch against 3.3a0 for idle.pyw to redirect stderr messages to a dialog box. This allows IDLE to keep running so that the user can at least save their work before closing IDLE.

----------
components: IDLE
files: idle_pyw.patch
keywords: patch
messages: 149244
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE and pythonw.exe stderr problem
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23916/idle_pyw.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13582>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:53:36 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 11 Dec 2011 19:53:36 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323633216.99.0.426549692032.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have written a patch and a test, but since it's changing C code, I am far from being sure if it's achieve the expected behavior in the right way. There are also tests and running whole test suite didn't bring any errors.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file23917/13521.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:53:59 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 11 Dec 2011 19:53:59 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323633239.73.0.4944435867.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Also: I'll be happy to work further on this patch, if I get some comments and advice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:59:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 19:59:13 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323633553.41.0.501448963617.issue13521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If _PyDict_SetItemUsingHash is module-private, it should be declared "static". Also, better if it follows the usual naming of static functions inside that C file (i.e. "dict_some_lowercase_name").

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sun Dec 11 21:02:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 20:02:39 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323631632.12.0.414167362859.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323633748.3366.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> "It doesn't happen in Python 3"
> 
> Yet the cheap/unnecessary pre-imports of ssl in those other mentioned
> socket using libs (urllib (cgi!),httplib,smtplib,pop,imap...) exist
> there. socket is rarely used directly, so not much difference to Py2
> in effect overall.

Well, by this measure, we probably have unnecessary imports all over the
place, since the general guideline is to import modules at the top-level
rather than inside functions (the reason is partly technical, to avoid
potential deadlocks with the import lock).

> Thus I'd request to not close this issue so swift. This is IHMO really
> a point to make python startup significantly faster, with a rather
> simple means.

If you are using a network library such as urllib or others you
mentioned, then startup time will surely be small compared to the time
spent sending and retrieving data over the network, no?

> Also the linkage of _ssl solely against a detailed version of
> libssl/libcrypto is still questionable.

I don't know the reasons (if any). Perhaps you can open a separate issue
about that?

> "This is therefore a problem with the Debian package"
> 
> I'm not into the Python build files. Just to ask/double-check: is that
> observed _semi_ static link selection (which is good otherwise -
> somebody must have done surprisingly lots of care) really from Debian
> or is there maybe a sort of 2nd default option bundle somewhere in
> Pythons configure? (If really not so I would go for Debian BTS.)

Well, seeing as Mageia's Python 2.7 doesn't have the problem, I really
think it must be Debian-specific:

$ ldd /usr/bin/python
	linux-vdso.so.1 =>  (0x00007fff4dd13000)
	libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0
(0x00007f45809ff000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f45807e3000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f4580472000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f458026e000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f458006b000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f457fde9000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4580dc0000)
$ ldd /usr/lib64/libpython2.7.so.1.0
	linux-vdso.so.1 =>  (0x00007fffb53ff000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc0d6455000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc0d6251000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007fc0d604d000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc0d5dcb000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc0d5a5a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc0d6a51000)

Also, I've just compiled a fresh Python 2.6 and I get similar results:

$ ldd ./python
	linux-vdso.so.1 =>  (0x00007fffa9795000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5f76439000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f5f76235000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f5f76032000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f5f75db0000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5f75a3f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5f76655000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Sun Dec 11 21:03:27 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 11 Dec 2011 20:03:27 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323633807.76.0.478069082823.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Done.

----------
Added file: http://bugs.python.org/file23918/13521_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sun Dec 11 21:18:30 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 11 Dec 2011 20:18:30 +0000
Subject: [issue13479] pickle too picky on re-defined classes
In-Reply-To: <1322211763.06.0.781568755806.issue13479@psf.upfronthosting.co.za>
Message-ID: <1323634710.69.0.964890308417.issue13479@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

What you're seeing here is just one of may things that go subtly wrong when you reload a class.  I don't think we should fix this one aspect while leaving so many other bugs due to the same root cause.

It would be better to focus your energy on a way to improve reloading, e.g. make it so that the identity of global functions and classes doesn't change when their module is reloaded.  (You'll find it a tough problem, but note that it's been solved for at least one specific instance: modules *do* retain their identity, so maybe you can use that as a model.)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13479>
_______________________________________

From report at bugs.python.org  Sun Dec 11 22:45:49 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Sun, 11 Dec 2011 21:45:49 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
Message-ID: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>


New submission from Lucas Sinclair <blastocyst at mac.com>:

When using the sqlite3.Row object as a row factory, one can access the resulting rows by index (such as row[1]) or by name (such as row['b']). However, the slice functionality is lost, as doing row[0:2] raises the error:

"slices not implemented, yet"

Here is a patch that fixes this, I implemented it and I added the corresponding unit test.

----------
files: sqlrowslice.patch
keywords: patch
messages: 149251
nosy: xapple
priority: normal
severity: normal
status: open
title: sqlite3.Row doesn't support slice indexes
type: feature request
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23919/sqlrowslice.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13583>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:09:12 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 22:09:12 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323641352.99.0.50739691847.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Performance report for current 3.3 tip, using "pybench".

******** BASELINE: (original version without DTRACE patch)

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.3.0a0 (default:70ba352f9586, Dec 11 2011, 22:46:09) [GCC 4.6.2]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

Calibrating tests. Please wait... done.

Running 10 round(s) of the suite at warp factor 10:

* Round 1 done in 4.457 seconds.
* Round 2 done in 4.466 seconds.
* Round 3 done in 4.438 seconds.
* Round 4 done in 4.503 seconds.
* Round 5 done in 4.519 seconds.
* Round 6 done in 4.514 seconds.
* Round 7 done in 4.460 seconds.
* Round 8 done in 4.455 seconds.
* Round 9 done in 4.477 seconds.
* Round 10 done in 4.547 seconds.

-------------------------------------------------------------------------------
Benchmark: 2011-12-11 22:50:16
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    SunOS-5.10-i86pc-i386-32bit-ELF
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /home/python/cpython/Tools/pybench/../../python
       Version:        3.3.0a0
       Compiler:       GCC 4.6.2
       Bits:           32bit
       Build:          Dec 11 2011 22:46:09 (#default:70ba352f9586)
       Unicode:        UCS4


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:     79ms     82ms    0.16us    0.291ms
           BuiltinMethodLookup:     58ms     59ms    0.06us    0.342ms
                 CompareFloats:     58ms     59ms    0.05us    0.390ms
         CompareFloatsIntegers:    114ms    118ms    0.13us    0.304ms
               CompareIntegers:     89ms     91ms    0.05us    0.589ms
        CompareInternedStrings:     72ms     75ms    0.05us    1.519ms
                  CompareLongs:     47ms     49ms    0.05us    0.340ms
                CompareStrings:     58ms     59ms    0.06us    1.013ms
    ComplexPythonFunctionCalls:     68ms     70ms    0.35us    0.501ms
                 ConcatStrings:     71ms     73ms    0.15us    0.560ms
               CreateInstances:    109ms    113ms    1.01us    0.456ms
            CreateNewInstances:     82ms     84ms    1.00us    0.364ms
       CreateStringsWithConcat:    107ms    111ms    0.11us    0.991ms
                  DictCreation:     55ms     57ms    0.14us    0.391ms
             DictWithFloatKeys:     82ms     84ms    0.09us    0.739ms
           DictWithIntegerKeys:     65ms     66ms    0.06us    0.992ms
            DictWithStringKeys:     58ms     59ms    0.05us    0.991ms
                      ForLoops:     63ms     65ms    2.59us    0.044ms
                    IfThenElse:     74ms     76ms    0.06us    0.739ms
                   ListSlicing:     46ms     47ms    3.39us    0.053ms
                NestedForLoops:     85ms     88ms    0.06us    0.003ms
      NestedListComprehensions:     86ms     88ms    7.33us    0.096ms
          NormalClassAttribute:    151ms    155ms    0.13us    0.529ms
       NormalInstanceAttribute:     86ms     87ms    0.07us    0.552ms
           PythonFunctionCalls:     65ms     66ms    0.20us    0.292ms
             PythonMethodCalls:     97ms    100ms    0.44us    0.184ms
                     Recursion:    114ms    116ms    2.33us    0.494ms
                  SecondImport:     70ms     72ms    0.72us    0.199ms
           SecondPackageImport:     70ms     73ms    0.73us    0.192ms
         SecondSubmoduleImport:    123ms    126ms    1.26us    0.192ms
       SimpleComplexArithmetic:     66ms     68ms    0.08us    0.391ms
        SimpleDictManipulation:    108ms    111ms    0.09us    0.493ms
         SimpleFloatArithmetic:     66ms     68ms    0.05us    0.591ms
      SimpleIntFloatArithmetic:     82ms     84ms    0.06us    0.589ms
       SimpleIntegerArithmetic:     82ms     85ms    0.06us    0.603ms
      SimpleListComprehensions:     71ms     74ms    6.18us    0.096ms
        SimpleListManipulation:     63ms     64ms    0.05us    0.646ms
          SimpleLongArithmetic:     60ms     62ms    0.09us    0.291ms
                    SmallLists:     86ms     89ms    0.13us    0.408ms
                   SmallTuples:     85ms     88ms    0.16us    0.455ms
         SpecialClassAttribute:    226ms    234ms    0.20us    0.547ms
      SpecialInstanceAttribute:     86ms     89ms    0.07us    0.533ms
                StringMappings:    277ms    286ms    1.13us    0.422ms
              StringPredicates:     96ms    100ms    0.14us    1.991ms
                 StringSlicing:     95ms     98ms    0.18us    0.836ms
                     TryExcept:     53ms     54ms    0.02us    0.741ms
                    TryFinally:     60ms     62ms    0.39us    0.390ms
                TryRaiseExcept:     35ms     38ms    0.60us    0.408ms
                  TupleSlicing:     75ms     78ms    0.30us    0.046ms
                   WithFinally:     86ms     89ms    0.55us    0.394ms
               WithRaiseExcept:     92ms     96ms    1.19us    0.512ms
-------------------------------------------------------------------------------
Totals:                           4353ms   4484ms


****** VERSION CALCULATING LINENUMBER IN EVERY FUNCTION CALL:

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.3.0a0 (dtrace-issue13405:552edf5be75c, Dec 11 2011, 22:57:28) [GCC 4.6.2]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

Calibrating tests. Please wait... done.

Running 10 round(s) of the suite at warp factor 10:

* Round 1 done in 4.880 seconds.
* Round 2 done in 4.876 seconds.
* Round 3 done in 4.899 seconds.
* Round 4 done in 4.887 seconds.
* Round 5 done in 4.872 seconds.
* Round 6 done in 4.913 seconds.
* Round 7 done in 4.888 seconds.
* Round 8 done in 4.865 seconds.
* Round 9 done in 4.888 seconds.
* Round 10 done in 4.864 seconds.

-------------------------------------------------------------------------------
Benchmark: 2011-12-11 22:58:51
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    SunOS-5.10-i86pc-i386-32bit-ELF
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /home/python/cpython-jcea/Tools/pybench/../../python
       Version:        3.3.0a0
       Compiler:       GCC 4.6.2
       Bits:           32bit
       Build:          Dec 11 2011 22:57:28 (#dtrace-issue13405:552edf5be75c)
       Unicode:        UCS4


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:    129ms    131ms    0.26us    0.295ms
           BuiltinMethodLookup:     57ms     58ms    0.06us    0.346ms
                 CompareFloats:     61ms     62ms    0.05us    0.413ms
         CompareFloatsIntegers:    117ms    118ms    0.13us    0.295ms
               CompareIntegers:     90ms     90ms    0.05us    0.596ms
        CompareInternedStrings:     74ms     74ms    0.05us    1.520ms
                  CompareLongs:     53ms     53ms    0.05us    0.345ms
                CompareStrings:     57ms     58ms    0.06us    1.015ms
    ComplexPythonFunctionCalls:     84ms     85ms    0.43us    0.503ms
                 ConcatStrings:    105ms    106ms    0.21us    0.556ms
               CreateInstances:    117ms    118ms    1.05us    0.459ms
            CreateNewInstances:     87ms     88ms    1.05us    0.366ms
       CreateStringsWithConcat:    112ms    113ms    0.11us    0.995ms
                  DictCreation:     56ms     57ms    0.14us    0.395ms
             DictWithFloatKeys:     85ms     85ms    0.09us    0.746ms
           DictWithIntegerKeys:     68ms     68ms    0.06us    0.996ms
            DictWithStringKeys:     62ms     62ms    0.05us    0.997ms
                      ForLoops:     66ms     66ms    2.66us    0.045ms
                    IfThenElse:     80ms     80ms    0.06us    0.746ms
                   ListSlicing:     46ms     46ms    3.30us    0.058ms
                NestedForLoops:     88ms     89ms    0.06us    0.003ms
      NestedListComprehensions:     87ms     88ms    7.34us    0.103ms
          NormalClassAttribute:    152ms    154ms    0.13us    0.528ms
       NormalInstanceAttribute:     88ms     88ms    0.07us    0.530ms
           PythonFunctionCalls:     92ms     93ms    0.28us    0.295ms
             PythonMethodCalls:    113ms    114ms    0.51us    0.177ms
                     Recursion:    133ms    133ms    2.67us    0.496ms
                  SecondImport:     75ms     81ms    0.81us    0.194ms
           SecondPackageImport:     79ms     83ms    0.83us    0.195ms
         SecondSubmoduleImport:    136ms    139ms    1.39us    0.195ms
       SimpleComplexArithmetic:     69ms     69ms    0.08us    0.398ms
        SimpleDictManipulation:    156ms    158ms    0.13us    0.517ms
         SimpleFloatArithmetic:     68ms     68ms    0.05us    0.596ms
      SimpleIntFloatArithmetic:     83ms     83ms    0.06us    0.595ms
       SimpleIntegerArithmetic:     82ms     83ms    0.06us    0.594ms
      SimpleListComprehensions:     72ms     75ms    6.24us    0.097ms
        SimpleListManipulation:     96ms     97ms    0.08us    0.648ms
          SimpleLongArithmetic:     61ms     62ms    0.09us    0.295ms
                    SmallLists:    105ms    107ms    0.16us    0.395ms
                   SmallTuples:     90ms     92ms    0.17us    0.445ms
         SpecialClassAttribute:    223ms    226ms    0.19us    0.532ms
      SpecialInstanceAttribute:     87ms     88ms    0.07us    0.536ms
                StringMappings:    293ms    294ms    1.17us    0.426ms
              StringPredicates:    144ms    145ms    0.21us    1.833ms
                 StringSlicing:     94ms     95ms    0.17us    0.832ms
                     TryExcept:     59ms     59ms    0.03us    0.746ms
                    TryFinally:     89ms     90ms    0.56us    0.396ms
                TryRaiseExcept:     40ms     41ms    0.64us    0.395ms
                  TupleSlicing:     76ms     77ms    0.29us    0.042ms
                   WithFinally:     89ms     91ms    0.57us    0.397ms
               WithRaiseExcept:    101ms    103ms    1.29us    0.496ms
-------------------------------------------------------------------------------
Totals:                           4824ms   4883ms


****** CURRENT DTRACE PATCH, sacrifying memory for speed:

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.3.0a0 (dtrace-issue13405:43d1a819a63d, Dec 11 2011, 22:40:40) [GCC 4.6.2]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

Calibrating tests. Please wait... done.

Running 10 round(s) of the suite at warp factor 10:

* Round 1 done in 4.581 seconds.
* Round 2 done in 4.527 seconds.
* Round 3 done in 4.591 seconds.
* Round 4 done in 4.563 seconds.
* Round 5 done in 4.516 seconds.
* Round 6 done in 4.528 seconds.
* Round 7 done in 4.555 seconds.
* Round 8 done in 4.535 seconds.
* Round 9 done in 4.524 seconds.
* Round 10 done in 4.528 seconds.

-------------------------------------------------------------------------------
Benchmark: 2011-12-11 22:53:33
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    SunOS-5.10-i86pc-i386-32bit-ELF
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /home/python/cpython-jcea/Tools/pybench/../../python
       Version:        3.3.0a0
       Compiler:       GCC 4.6.2
       Bits:           32bit
       Build:          Dec 11 2011 22:40:40 (#dtrace-issue13405:43d1a819a63d)
       Unicode:        UCS4


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:     78ms     79ms    0.16us    0.304ms
           BuiltinMethodLookup:     57ms     57ms    0.05us    0.356ms
                 CompareFloats:     60ms     61ms    0.05us    0.408ms
         CompareFloatsIntegers:    115ms    116ms    0.13us    0.304ms
               CompareIntegers:     90ms     91ms    0.05us    0.614ms
        CompareInternedStrings:     75ms     75ms    0.05us    1.552ms
                  CompareLongs:     53ms     54ms    0.05us    0.356ms
                CompareStrings:     57ms     59ms    0.06us    1.040ms
    ComplexPythonFunctionCalls:     74ms     76ms    0.38us    0.513ms
                 ConcatStrings:     70ms     73ms    0.15us    0.564ms
               CreateInstances:    113ms    116ms    1.04us    0.464ms
            CreateNewInstances:     85ms     87ms    1.03us    0.372ms
       CreateStringsWithConcat:    110ms    113ms    0.11us    1.030ms
                  DictCreation:     59ms     60ms    0.15us    0.406ms
             DictWithFloatKeys:     85ms     87ms    0.10us    0.770ms
           DictWithIntegerKeys:     70ms     70ms    0.06us    1.029ms
            DictWithStringKeys:     62ms     63ms    0.05us    1.029ms
                      ForLoops:     67ms     67ms    2.69us    0.046ms
                    IfThenElse:     79ms     80ms    0.06us    0.770ms
                   ListSlicing:     46ms     46ms    3.30us    0.057ms
                NestedForLoops:     88ms     89ms    0.06us    0.003ms
      NestedListComprehensions:     88ms     90ms    7.46us    0.100ms
          NormalClassAttribute:    155ms    157ms    0.13us    0.537ms
       NormalInstanceAttribute:     88ms     89ms    0.07us    0.540ms
           PythonFunctionCalls:     71ms     72ms    0.22us    0.305ms
             PythonMethodCalls:     98ms    100ms    0.44us    0.180ms
                     Recursion:    123ms    125ms    2.50us    0.512ms
                  SecondImport:     72ms     73ms    0.73us    0.210ms
           SecondPackageImport:     72ms     74ms    0.74us    0.210ms
         SecondSubmoduleImport:    126ms    129ms    1.29us    0.210ms
       SimpleComplexArithmetic:     68ms     69ms    0.08us    0.408ms
        SimpleDictManipulation:    117ms    118ms    0.10us    0.516ms
         SimpleFloatArithmetic:     66ms     67ms    0.05us    0.615ms
      SimpleIntFloatArithmetic:     82ms     82ms    0.06us    0.615ms
       SimpleIntegerArithmetic:     82ms     84ms    0.06us    0.614ms
      SimpleListComprehensions:     73ms     75ms    6.24us    0.104ms
        SimpleListManipulation:     64ms     65ms    0.06us    0.666ms
          SimpleLongArithmetic:     61ms     62ms    0.09us    0.304ms
                    SmallLists:     87ms     89ms    0.13us    0.406ms
                   SmallTuples:     84ms     86ms    0.16us    0.459ms
         SpecialClassAttribute:    228ms    234ms    0.19us    0.541ms
      SpecialInstanceAttribute:     88ms     90ms    0.08us    0.542ms
                StringMappings:    277ms    280ms    1.11us    0.434ms
              StringPredicates:     94ms     95ms    0.14us    1.868ms
                 StringSlicing:     94ms     96ms    0.17us    0.849ms
                     TryExcept:     58ms     59ms    0.03us    0.771ms
                    TryFinally:     64ms     66ms    0.41us    0.408ms
                TryRaiseExcept:     38ms     38ms    0.60us    0.408ms
                  TupleSlicing:     75ms     76ms    0.29us    0.043ms
                   WithFinally:     88ms     90ms    0.56us    0.408ms
               WithRaiseExcept:     97ms     99ms    1.24us    0.512ms
-------------------------------------------------------------------------------
Totals:                           4470ms   4545ms


The previous version that calculates linenumbers in each function call is about 9% slower that stock python. Sacrifying a bit of memory (O(2*n), with n is the size of bytecodes imported), the speed difference with stock python is 1.4%.

I think that paying 1.4% of performance hit is a good investment to enjoy DTrace probes in Python, being able to run an instrumentalized Python interpreter 100% of the time. In fact this instrumentalization can be used to locate hotspots in python interpreter and maybe improve overall performance.

Of course, platform with no dtrace or with dtrace support disabled when compiling python will no have any kind of performance hit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:11:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 22:11:05 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323641465.1.0.453765977515.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23920/f73be85b9a7e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:12:56 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 22:12:56 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323641576.33.0.604307699522.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23921/43d1a819a63d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:13:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 22:13:35 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323641615.72.0.504891558362.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23758/a9f4ae43fd85.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:14:20 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 22:14:20 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323641660.75.0.906117486873.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23827/2a7dedf6a65e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:22:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Dec 2011 22:22:28 +0000
Subject: [issue13570] Expose faster unicode<->ascii functions in the C-API
In-Reply-To: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
Message-ID: <1323642148.06.0.930224534014.issue13570@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's reasonable that string % formatting might have become slower...

I wonder what the issue is at this point. Unless you can state a clear issue that you want to see resolved, I propose to close this report as invalid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13570>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:42:18 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 11 Dec 2011 22:42:18 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323643338.2.0.629746492656.issue13516@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Some people might want other compression methods, e.g. bz2, zip, lzma ...

Have you considered subclassing the existing handler classes as in the following example?

http://code.activestate.com/recipes/502265-timedcompressedrotatingfilehandler/

Possibly I could change the implementation in 3.3 to make this easier to do ... I will give it some thought.

----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:43:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 22:43:21 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323643401.0.0.292518452248.issue13521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok to me. I'll let Raymond make the final call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:53:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 11 Dec 2011 22:53:50 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323644030.74.0.861099800613.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Same calculations for 64 bit binaries:

***** STOCK PYTHON:

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.3.0a0 (default:70ba352f9586, Dec 11 2011, 23:38:26) [GCC 4.6.2]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

Calibrating tests. Please wait... done.

Running 10 round(s) of the suite at warp factor 10:

* Round 1 done in 3.392 seconds.
* Round 2 done in 3.423 seconds.
* Round 3 done in 3.397 seconds.
* Round 4 done in 3.425 seconds.
* Round 5 done in 3.395 seconds.
* Round 6 done in 3.465 seconds.
* Round 7 done in 3.476 seconds.
* Round 8 done in 3.388 seconds.
* Round 9 done in 3.385 seconds.
* Round 10 done in 3.388 seconds.

-------------------------------------------------------------------------------
Benchmark: 2011-12-11 23:39:33
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    SunOS-5.10-i86pc-i386-64bit-ELF
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /home/python/cpython/python
       Version:        3.3.0a0
       Compiler:       GCC 4.6.2
       Bits:           64bit
       Build:          Dec 11 2011 23:38:26 (#default:70ba352f9586)
       Unicode:        UCS4


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:     58ms     61ms    0.12us    0.199ms
           BuiltinMethodLookup:     38ms     39ms    0.04us    0.233ms
                 CompareFloats:     44ms     51ms    0.04us    0.267ms
         CompareFloatsIntegers:    100ms    102ms    0.11us    0.199ms
               CompareIntegers:     68ms     78ms    0.04us    0.401ms
        CompareInternedStrings:     53ms     53ms    0.04us    1.015ms
                  CompareLongs:     38ms     45ms    0.04us    0.233ms
                CompareStrings:     45ms     46ms    0.05us    0.680ms
    ComplexPythonFunctionCalls:     57ms     58ms    0.29us    0.335ms
                 ConcatStrings:     52ms     53ms    0.11us    0.379ms
               CreateInstances:     88ms     89ms    0.80us    0.331ms
            CreateNewInstances:     66ms     68ms    0.80us    0.269ms
       CreateStringsWithConcat:     87ms     89ms    0.09us    0.672ms
                  DictCreation:     46ms     47ms    0.12us    0.279ms
             DictWithFloatKeys:     57ms     58ms    0.06us    0.503ms
           DictWithIntegerKeys:     47ms     48ms    0.04us    0.672ms
            DictWithStringKeys:     40ms     41ms    0.03us    0.672ms
                      ForLoops:     45ms     45ms    1.82us    0.031ms
                    IfThenElse:     54ms     55ms    0.04us    0.503ms
                   ListSlicing:     50ms     51ms    3.64us    0.042ms
                NestedForLoops:     65ms     67ms    0.04us    0.002ms
      NestedListComprehensions:     64ms     65ms    5.44us    0.066ms
          NormalClassAttribute:    129ms    130ms    0.11us    0.363ms
       NormalInstanceAttribute:     62ms     62ms    0.05us    0.365ms
           PythonFunctionCalls:     49ms     50ms    0.15us    0.203ms
             PythonMethodCalls:     69ms     69ms    0.31us    0.133ms
                     Recursion:     86ms     86ms    1.72us    0.334ms
                  SecondImport:     57ms     59ms    0.59us    0.131ms
           SecondPackageImport:     59ms     60ms    0.60us    0.131ms
         SecondSubmoduleImport:    103ms    104ms    1.04us    0.131ms
       SimpleComplexArithmetic:     45ms     45ms    0.05us    0.267ms
        SimpleDictManipulation:     84ms     84ms    0.07us    0.334ms
         SimpleFloatArithmetic:     46ms     47ms    0.04us    0.402ms
      SimpleIntFloatArithmetic:     57ms     58ms    0.04us    0.401ms
       SimpleIntegerArithmetic:     57ms     57ms    0.04us    0.401ms
      SimpleListComprehensions:     54ms     55ms    4.56us    0.066ms
        SimpleListManipulation:     42ms     43ms    0.04us    0.506ms
          SimpleLongArithmetic:     37ms     38ms    0.06us    0.199ms
                    SmallLists:     61ms     63ms    0.09us    0.266ms
                   SmallTuples:     63ms     65ms    0.12us    0.300ms
         SpecialClassAttribute:    184ms    187ms    0.16us    0.368ms
      SpecialInstanceAttribute:     62ms     63ms    0.05us    0.370ms
                StringMappings:    206ms    211ms    0.84us    0.293ms
              StringPredicates:     65ms     67ms    0.10us    1.328ms
                 StringSlicing:     74ms     75ms    0.13us    0.559ms
                     TryExcept:     36ms     36ms    0.02us    0.503ms
                    TryFinally:     45ms     45ms    0.28us    0.267ms
                TryRaiseExcept:     27ms     27ms    0.42us    0.267ms
                  TupleSlicing:     72ms     73ms    0.28us    0.030ms
                   WithFinally:     68ms     71ms    0.44us    0.267ms
               WithRaiseExcept:     73ms     76ms    0.94us    0.334ms
-------------------------------------------------------------------------------
Totals:                           3333ms   3413ms


********** DTRACE CALCULATING LINENUMBER IN EVERY FUNCTION CALL:

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.3.0a0 (dtrace-issue13405:552edf5be75c, Dec 11 2011, 23:43:27) [GCC 4.6.2]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

Calibrating tests. Please wait... done.

Running 10 round(s) of the suite at warp factor 10:

* Round 1 done in 3.898 seconds.
* Round 2 done in 3.849 seconds.
* Round 3 done in 3.857 seconds.
* Round 4 done in 3.887 seconds.
* Round 5 done in 3.833 seconds.
* Round 6 done in 3.837 seconds.
* Round 7 done in 3.842 seconds.
* Round 8 done in 3.853 seconds.
* Round 9 done in 3.870 seconds.
* Round 10 done in 3.840 seconds.

-------------------------------------------------------------------------------
Benchmark: 2011-12-11 23:44:53
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    SunOS-5.10-i86pc-i386-64bit-ELF
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /home/python/cpython-jcea/python
       Version:        3.3.0a0
       Compiler:       GCC 4.6.2
       Bits:           64bit
       Build:          Dec 11 2011 23:43:27 (#dtrace-issue13405:552edf5be75c)
       Unicode:        UCS4


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:    107ms    109ms    0.21us    0.205ms
           BuiltinMethodLookup:     39ms     40ms    0.04us    0.239ms
                 CompareFloats:     44ms     45ms    0.04us    0.274ms
         CompareFloatsIntegers:     83ms     84ms    0.09us    0.204ms
               CompareIntegers:     70ms     70ms    0.04us    0.413ms
        CompareInternedStrings:     56ms     57ms    0.04us    1.053ms
                  CompareLongs:     40ms     41ms    0.04us    0.239ms
                CompareStrings:     49ms     51ms    0.05us    0.700ms
    ComplexPythonFunctionCalls:     74ms     77ms    0.39us    0.344ms
                 ConcatStrings:     54ms     54ms    0.11us    0.388ms
               CreateInstances:     97ms     98ms    0.88us    0.324ms
            CreateNewInstances:     73ms     74ms    0.88us    0.275ms
       CreateStringsWithConcat:     89ms     90ms    0.09us    0.692ms
                  DictCreation:     47ms     47ms    0.12us    0.274ms
             DictWithFloatKeys:     59ms     60ms    0.07us    0.519ms
           DictWithIntegerKeys:     48ms     49ms    0.04us    0.693ms
            DictWithStringKeys:     44ms     45ms    0.04us    0.693ms
                      ForLoops:     44ms     45ms    1.78us    0.031ms
                    IfThenElse:     59ms     59ms    0.04us    0.519ms
                   ListSlicing:     50ms     50ms    3.61us    0.040ms
                NestedForLoops:     68ms     69ms    0.05us    0.002ms
      NestedListComprehensions:     69ms     70ms    5.87us    0.068ms
          NormalClassAttribute:    130ms    134ms    0.11us    0.371ms
       NormalInstanceAttribute:     64ms     65ms    0.05us    0.373ms
           PythonFunctionCalls:     80ms     81ms    0.25us    0.201ms
             PythonMethodCalls:    102ms    103ms    0.46us    0.136ms
                     Recursion:    112ms    114ms    2.29us    0.343ms
                  SecondImport:     54ms     56ms    0.56us    0.135ms
           SecondPackageImport:     54ms     56ms    0.56us    0.135ms
         SecondSubmoduleImport:     99ms    101ms    1.01us    0.135ms
       SimpleComplexArithmetic:     48ms     49ms    0.06us    0.274ms
        SimpleDictManipulation:    137ms    139ms    0.12us    0.344ms
         SimpleFloatArithmetic:     45ms     45ms    0.03us    0.413ms
      SimpleIntFloatArithmetic:     57ms     59ms    0.04us    0.413ms
       SimpleIntegerArithmetic:     60ms     61ms    0.05us    0.413ms
      SimpleListComprehensions:     57ms     58ms    4.82us    0.067ms
        SimpleListManipulation:     76ms     77ms    0.07us    0.449ms
          SimpleLongArithmetic:     40ms     41ms    0.06us    0.204ms
                    SmallLists:     81ms     82ms    0.12us    0.274ms
                   SmallTuples:     71ms     72ms    0.13us    0.309ms
         SpecialClassAttribute:    188ms    191ms    0.16us    0.377ms
      SpecialInstanceAttribute:     63ms     64ms    0.05us    0.378ms
                StringMappings:    210ms    211ms    0.84us    0.296ms
              StringPredicates:    114ms    115ms    0.16us    1.408ms
                 StringSlicing:     77ms     78ms    0.14us    0.578ms
                     TryExcept:     48ms     48ms    0.02us    0.518ms
                    TryFinally:     93ms     99ms    0.62us    0.274ms
                TryRaiseExcept:     30ms     30ms    0.47us    0.274ms
                  TupleSlicing:     72ms     75ms    0.28us    0.030ms
                   WithFinally:     81ms     82ms    0.51us    0.274ms
               WithRaiseExcept:     82ms     84ms    1.05us    0.343ms
-------------------------------------------------------------------------------
Totals:                           3793ms   3857ms


********* SPENDING SOME MEMORY FOR PERFORMANCE:

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.3.0a0 (dtrace-issue13405:43d1a819a63d, Dec 11 2011, 23:47:52) [GCC 4.6.2]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

Calibrating tests. Please wait... done.

Running 10 round(s) of the suite at warp factor 10:

* Round 1 done in 3.529 seconds.
* Round 2 done in 3.579 seconds.
* Round 3 done in 3.526 seconds.
* Round 4 done in 3.517 seconds.
* Round 5 done in 3.538 seconds.
* Round 6 done in 3.547 seconds.
* Round 7 done in 3.526 seconds.
* Round 8 done in 3.518 seconds.
* Round 9 done in 3.512 seconds.
* Round 10 done in 3.550 seconds.

-------------------------------------------------------------------------------
Benchmark: 2011-12-11 23:49:03
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    SunOS-5.10-i86pc-i386-64bit-ELF
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /home/python/cpython-jcea/python
       Version:        3.3.0a0
       Compiler:       GCC 4.6.2
       Bits:           64bit
       Build:          Dec 11 2011 23:47:52 (#dtrace-issue13405:43d1a819a63d)
       Unicode:        UCS4


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:     57ms     61ms    0.12us    0.203ms
           BuiltinMethodLookup:     40ms     41ms    0.04us    0.237ms
                 CompareFloats:     45ms     46ms    0.04us    0.272ms
         CompareFloatsIntegers:     85ms     85ms    0.09us    0.203ms
               CompareIntegers:     69ms     69ms    0.04us    0.410ms
        CompareInternedStrings:     65ms     65ms    0.04us    1.035ms
                  CompareLongs:     40ms     40ms    0.04us    0.237ms
                CompareStrings:     47ms     50ms    0.05us    0.694ms
    ComplexPythonFunctionCalls:     61ms     62ms    0.31us    0.341ms
                 ConcatStrings:     56ms     57ms    0.11us    0.385ms
               CreateInstances:     97ms     99ms    0.88us    0.329ms
            CreateNewInstances:     72ms     73ms    0.87us    0.275ms
       CreateStringsWithConcat:     87ms     88ms    0.09us    0.686ms
                  DictCreation:     46ms     47ms    0.12us    0.272ms
             DictWithFloatKeys:     59ms     60ms    0.07us    0.513ms
           DictWithIntegerKeys:     49ms     50ms    0.04us    0.686ms
            DictWithStringKeys:     43ms     43ms    0.04us    0.686ms
                      ForLoops:     43ms     44ms    1.77us    0.031ms
                    IfThenElse:     60ms     61ms    0.05us    0.513ms
                   ListSlicing:     50ms     51ms    3.65us    0.040ms
                NestedForLoops:     64ms     65ms    0.04us    0.002ms
      NestedListComprehensions:     66ms     67ms    5.57us    0.067ms
          NormalClassAttribute:    132ms    133ms    0.11us    0.370ms
       NormalInstanceAttribute:     64ms     65ms    0.05us    0.373ms
           PythonFunctionCalls:     62ms     62ms    0.19us    0.203ms
             PythonMethodCalls:     80ms     82ms    0.37us    0.135ms
                     Recursion:    105ms    106ms    2.12us    0.341ms
                  SecondImport:     53ms     54ms    0.54us    0.134ms
           SecondPackageImport:     53ms     54ms    0.54us    0.134ms
         SecondSubmoduleImport:     94ms     95ms    0.95us    0.134ms
       SimpleComplexArithmetic:     48ms     48ms    0.05us    0.272ms
        SimpleDictManipulation:     92ms     93ms    0.08us    0.337ms
         SimpleFloatArithmetic:     46ms     46ms    0.04us    0.411ms
      SimpleIntFloatArithmetic:     58ms     58ms    0.04us    0.409ms
       SimpleIntegerArithmetic:     57ms     58ms    0.04us    0.409ms
      SimpleListComprehensions:     55ms     57ms    4.79us    0.067ms
        SimpleListManipulation:     45ms     46ms    0.04us    0.422ms
          SimpleLongArithmetic:     38ms     39ms    0.06us    0.203ms
                    SmallLists:     62ms     64ms    0.09us    0.272ms
                   SmallTuples:     66ms     67ms    0.12us    0.306ms
         SpecialClassAttribute:    187ms    191ms    0.16us    0.374ms
      SpecialInstanceAttribute:     64ms     65ms    0.05us    0.378ms
                StringMappings:    198ms    199ms    0.79us    0.295ms
              StringPredicates:     68ms     69ms    0.10us    1.380ms
                 StringSlicing:     75ms     76ms    0.14us    0.570ms
                     TryExcept:     46ms     46ms    0.02us    0.513ms
                    TryFinally:     54ms     54ms    0.34us    0.272ms
                TryRaiseExcept:     27ms     27ms    0.43us    0.272ms
                  TupleSlicing:     74ms     75ms    0.29us    0.031ms
                   WithFinally:     82ms     84ms    0.53us    0.272ms
               WithRaiseExcept:     91ms     93ms    1.17us    0.341ms
-------------------------------------------------------------------------------
Totals:                           3477ms   3534ms


Here the performance penalty is 13% for the version that calculates linenumbers in each function call, and 3.5% for the memory spending extra memory for performance. The extra performance hit is because, possibly, the extra C function call and C stack massaging. Something to think about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:01:37 2011
From: report at bugs.python.org (kxroberto)
Date: Sun, 11 Dec 2011 23:01:37 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323644497.21.0.126779333327.issue13580@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

>> "It doesn't happen in Python 3"
>>
>> Yet the cheap/unnecessary pre-imports of ssl in those other mentioned
>> socket using libs (urllib (cgi!),httplib,smtplib,pop,imap...) exist
>> there. socket is rarely used directly, so not much difference to Py2
>> in effect overall.
> Well, by this measure, we probably have unnecessary imports all over the
> place, since the general guideline is to import modules at the top-level
> rather than inside functions (the reason is partly technical, to avoid
> potential deadlocks with the import lock).

see e.g. issue #1046077. 
As said, in this case here its even about libs almost as big as the python binary itself (on many platforms).
When there are only few link points, and a huge effect (->usage probabilities), late imports shall be used. Python is dynamic.
The list, as posted, is short here. Grep "ssl" in Python lib.
Its not reasonable to draw the big libcrypto and libssl almost always.

>> Thus I'd request to not close this issue so swift. This is IHMO really
>> a point to make python startup significantly faster, with a rather
>> simple means.
> If you are using a network library such as urllib or others you
> mentioned, then startup time will surely be small compared to the time
> spent sending and retrieving data over the network, no?

no. This is to cheap here. I'd vote for some discipline regarding such levels of resource usage. 
(I often wonder why software today isn't much faster than years ago - though the nominal speed of hardware increases tremendously. package sizes grow, without appropriate growth of functionality. This is one example how the rescources are wasted too careless.)

For example each cgi script (which has to respond fast and does only a small job), which does  "import cgi" and a few lines; or a script which just uses e.g., urllib string format functions ... : the whole thing is drawn.

>
>> Also the linkage of _ssl solely against a detailed version of
>> libssl/libcrypto is still questionable.
> I don't know the reasons (if any). Perhaps you can open a separate issue
> about that?

Yet the issue of this library is here now. Why procrastinate?

>
>> "This is therefore a problem with the Debian package"
>>
>> I'm not into the Python build files. Just to ask/double-check: is that
>> observed _semi_ static link selection (which is good otherwise -
>> somebody must have done surprisingly lots of care) really from Debian
>> or is there maybe a sort of 2nd default option bundle somewhere in
>> Pythons configure? (If really not so I would go for Debian BTS.)
> Well, seeing as Mageia's Python 2.7 doesn't have the problem, I really
> think it must be Debian-specific:

as emphasized in my sentence such reasoning alone would be sloppy. Thats why I asked.
Does sb actually know, if this optimized semistatic module list is really not in Pythons configure somewhere?
(The Debians would have gone rather deep into issues when they really created that fine tuning on their own. almost can't believe. If so I'd even recommend to adopt that (except _ssl.so) generally into Pythons standard configuration - at least for Linux)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:06:16 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Sun, 11 Dec 2011 23:06:16 +0000
Subject: [issue13584] argparse doesn't respect double quotes
Message-ID: <1323644776.15.0.954128215296.issue13584@psf.upfronthosting.co.za>


New submission from Phillip Feldman <phillip.m.feldman at gmail.com>:

I tried switching from `optparse` to `argparse`, but ended up reverting back because `argparse` does not respect double quotes.  For example, `optparse` correctly parses the following, while `argparse` does not:

   python myprog.py --ng --INP="Demo IO"

(`argparse` splits "Demo" and "IO" into separate tokens).

----------
components: Library (Lib)
messages: 149258
nosy: Phillip.M.Feldman
priority: normal
severity: normal
status: open
title: argparse doesn't respect double quotes
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13584>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:31:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 23:31:53 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323644497.21.0.126779333327.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323646301.3366.34.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> (I often wonder why software today isn't much faster than years ago -
> though the nominal speed of hardware increases tremendously. package
> sizes grow, without appropriate growth of functionality. This is one
> example how the rescources are wasted too careless.)

I don't know of any evidence that software slowness has to do with code
size. When code isn't called, it doesn't pollute the instruction caches
and hence shouldn't affect execution speed.

I understand the concern about py2exe and similar distribution systems
(although distribution size should be much less important nowadays than
10 years ago). But, really, it's a separate issue.

> For example each cgi script (which has to respond fast and does only a
> small job), which does  "import cgi" and a few lines; or a script
> which just uses e.g., urllib string format functions ... : the whole
> thing is drawn.

Well, CGI scripts are a wasteful way to do programmatic page serving. If
you care about performance, you should have switched to something like
FastCGI or mod_wsgi.

> >> Also the linkage of _ssl solely against a detailed version of
> >> libssl/libcrypto is still questionable.
> > I don't know the reasons (if any). Perhaps you can open a separate issue
> > about that?
> 
> Yet the issue of this library is here now. Why procrastinate?

This sentence sounds like you want to dictate us what and how we should
work on. That won't fly, sorry. The reason we want to avoid tackling
multiple issues in a single tracker entry is simply so that the entries
stay readable and searchable.

(and, really, most projects' bug trackers work that way, for the same
reasons)

> (The Debians would have gone rather deep into issues when they really
> created that fine tuning on their own. almost can't believe.

There's nothing magical about libssl that would make us link it
statically to the executable; it's far too optional a dependency for
that. Perhaps Debian has its own bootstrapping requirements that mandate
it, or perhaps they simply made a mistake and nobody complained before?
Why don't you open an issue on their bug tracker, or at least try to
contact them? You would get a definite answer about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:36:35 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Dec 2011 23:36:35 +0000
Subject: [issue13570] Expose faster unicode<->ascii functions in the C-API
In-Reply-To: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
Message-ID: <1323646595.03.0.284581432393.issue13570@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Sorry, the title of the issue isn't correct any more. The revised
issue is that in 3.3

a) outfil.write("%s\n" % t)

is about 11% slower than in Python2.7 and 8% slower than in Python3.2.


On the other hand in 3.3 the hack

b) outfil.write(str(t)); outfil.write('\n') 

runs about as fast as a) in 3.2.


This doesn't necessarily show up in microbenchmarks with timeit, so
I thought I'd leave this open for others to see (and comment).

But if I understand correctly, the slowdown in string formatting is
expected, so we can indeed close this.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13570>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:44:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2011 23:44:25 +0000
Subject: [issue13570] Expose faster unicode<->ascii functions in the C-API
In-Reply-To: <1323465152.13.0.29944008784.issue13570@psf.upfronthosting.co.za>
Message-ID: <1323647065.45.0.25749457415.issue13570@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But if I understand correctly, the slowdown in string formatting is
> expected, so we can indeed close this.

Well, expected doesn't mean it shouldn't be improved, so finding a way to speed it up would be nice ;)
(probably difficult, though)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13570>
_______________________________________

From report at bugs.python.org  Mon Dec 12 01:03:59 2011
From: report at bugs.python.org (sbt)
Date: Mon, 12 Dec 2011 00:03:59 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323648239.27.0.278098323298.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

New version of the patch with tests and using _Py_IDENTIFIER.

----------
Added file: http://bugs.python.org/file23922/descr_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:06:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Dec 2011 01:06:47 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1323652007.52.0.541145527465.issue11886@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, it's still not ok:



======================================================================
FAIL: test_tzset (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_time.py", line 264, in test_tzset
    self.assertEqual(time.timezone, -36000)
AssertionError: 18000 != -36000

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11886>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:09:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Dec 2011 01:09:04 +0000
Subject: [issue13561] os.listdir documentation should mention surrogateescape
In-Reply-To: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>
Message-ID: <1323652144.01.0.585468917644.issue13561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you please write a doc patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13561>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:11:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Dec 2011 01:11:34 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323652294.57.0.559169114059.issue13248@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

.. versionchanged:: 3.2
-      The *strict* parameter is deprecated.  HTTP 0.9-style "Simple Responses"
+      The *strict* parameter is removed.  HTTP 0.9-style "Simple Responses"
       are not supported anymore.

Such change looks wrong: the parameter exists in Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:15:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Dec 2011 01:15:51 +0000
Subject: [issue13572] import _curses fails because of
	UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on
	ARM Ubuntu 3.x
In-Reply-To: <1323524849.05.0.773120918069.issue13572@psf.upfronthosting.co.za>
Message-ID: <1323652551.07.0.247821340516.issue13572@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Barry: can you try to get a trace using gdb? Start python in gdb, set a breapoint on PyErr_SetObject, continue, run the Python command "import _curses", get the gdb traceback (or continue if the error is not the UTF-8 error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13572>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:28:30 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Dec 2011 01:28:30 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323600170.82.0.945222018753.issue13544@psf.upfronthosting.co.za>
Message-ID: <CAK1QoorgdM+LAzNJG-4TrRfkN_u+Qe9pBJ4WeVOz1Aoijp5p0g@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Sun, Dec 11, 2011 at 4:42 AM, Nick Coghlan <report at bugs.python.org> wrote:

> Explicitly spelling out __qualname__ like that makes the tests a bit too sensitive to otherwise irrelevant details of the test layout.
>
> I suggest using comparisons like "self.assertEqual(wrapper.__qualname__, f.__qualname__)" and "self.assertNotEqual(wrapper.__qualname__,
> f.__qualname__)" to make sure they're the same or different as appropriate, without caring about their precise value (this is similar to what the tests
> already do for "dict_attr")

Good point.  I will commit Filip's latest patch that has these fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:30:50 2011
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2011 01:30:50 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1323653450.44.0.823373523003.issue8538@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:49:50 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 01:49:50 +0000
Subject: [issue13585] Add contextlib.CleanupManager
Message-ID: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

I'd like to propose addding the CleanupManager class described in http://article.gmane.org/gmane.comp.python.ideas/12447 to the contextlib module. The idea is to add a general-purpose context manager to manage (python or non-python) resources that don't come with their own context manager.

Example code:

with CleanupManager() als mngr:
    tmpdir = tempfile.mkdtemp()
    mngr.register(shutil.rmtree(tmpdir))
    # do stuff with tmpdir

# shutil.rmtree() get's called automatically when the block is over

Note that mkdtemp() could of course also be changed to become its own context manager. The idea is to provide a general facility for this kind of problem, so it doesn't have to be reinvented whenever a module provides a ressource without its own context manager. Other possible uses are of course ressources that are completely external to Python,
e.g. anything allocated with a subprocess (think of subprocess.check_call('mount'))/


I'll be happy to make a proper patch with documentation and testcases from Jan's code. As a matter of fact, I'll probably start working out it right now, so please let me know quickly if this doesn't have a chance of getting accepted.

----------
components: Library (Lib)
messages: 149268
nosy: Nikratio
priority: normal
severity: normal
status: open
title: Add contextlib.CleanupManager
type: feature request
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:28:02 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 02:28:02 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323656882.06.0.857870526171.issue13585@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Here's the first part of the patch with the implementation. I'll add tests and documentation as soon as someone confirms that the idea & API is okay.

----------
keywords: +patch
Added file: http://bugs.python.org/file23923/CleanupManager_patch_v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:37:07 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 02:37:07 +0000
Subject: [issue12704] Language References does not specify exception raised by
	final yield()
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1323657427.81.0.647312088736.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Hmm. Does the total lack responses mean agreement, disagreement or lack of interest? I'm attaching a patch against Python 3.3 in the hope of moving this forward.

----------
keywords: +patch
Added file: http://bugs.python.org/file23924/patch_v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12704>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:37:43 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 02:37:43 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1323657463.87.0.207186303163.issue12704@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
title: Language References does not specify exception raised by final yield() -> Language Reference: Clarify behaviour of yield when generator is not resumed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12704>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:41:24 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2011 02:41:24 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323657684.72.0.423067063412.issue13585@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would like to see this posted as a recipe before being put in the standard library.  It needs a chance to mature and to demonstrate that people will want to use it.

FWIW, the example is problematic in a couple of ways.  The registration of shutil.rmtree(tmpdir) will run *before* mngr register is called.  

Also, it doesn't take advantage of any of the with-statement features.  It doesn't show any advantage over a standard try/finally which is arguably cleaner:

    tmpdir = tempfile.mkdtemp()
    try:
        # do stuff with tmpdir
    finally:
        shutil.rmtree()

Also, I suspect that the CleanupManager would be an error-prone construct because the registration occurs somewhere after the with-statement is set-up, possibly resulting in errors if there is an early, pre-registration failure.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:56:26 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 02:56:26 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323658586.53.0.835802166702.issue13585@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Not sure what you mean with "posted as a recipe" -- are you thinking of a specific website/mailing list?

Example: which one do you mean? The one in the issue or the one in the patch?

With statement: what advantages do you have in mind?

Try/finally: I think the patch and the discussion in python-ideas talk about the advantage over try/finally. IMO the two most important points are: (1) avoids deep and pointless indendation for multiple ressources, (2) keeps logically connected lines (allocation+cleanup) closely together in the source instead of splitting them far apart like try/finally.

error-prone: not sure if I understand you correctly. If there is an error prior to registration, the callback will not be called (that's a feature). To what kind of errors could that lead?


Sorry for basically asking you to re-explain every sentence, but I honestly don't understand most of your message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 04:17:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2011 03:17:42 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323659862.04.0.108345523123.issue13585@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

'''
Example code:

with CleanupManager() als mngr:
    tmpdir = tempfile.mkdtemp()
    mngr.register(shutil.rmtree(tmpdir)) <-- this makes the call right away
    # do stuff with tmpdir
'''

The part of my note that should be clear is that the idea and code need to prove itself before being added to the standard library.  So far, there has been zero demand for this and I've not seen code like it being used in the wild.  AFAICT, it is not demonstrably better than a straight-forward try/finally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 05:21:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Dec 2011 04:21:21 +0000
Subject: [issue13584] argparse doesn't respect double quotes
In-Reply-To: <1323644776.15.0.954128215296.issue13584@psf.upfronthosting.co.za>
Message-ID: <1323663681.6.0.750992462701.issue13584@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13584>
_______________________________________

From report at bugs.python.org  Mon Dec 12 05:54:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2011 04:54:40 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <E1RZxuQ-0004FU-RU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 963e98f5ad31 by Meador Inge in branch 'default':
Issue #13544: Add __qualname__ to functools.WRAPPER_ASSIGNMENTS.
http://hg.python.org/cpython/rev/963e98f5ad31

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Mon Dec 12 05:57:33 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Dec 2011 04:57:33 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323665853.06.0.678396738781.issue13544@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the patch Filip.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:42:12 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Mon, 12 Dec 2011 05:42:12 +0000
Subject: [issue13586] Replace selected not working/consistent with find
Message-ID: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>


New submission from Marco Scataglini <atlantide at gmx.com>:

Entering the Replace dialog (by ctrl+h or from Edit/Replace... menu) with a selection does not auto-magically have the selected text in the find field.

This is not consistent with the other find functions (ctrl+f: Find...; alt+F3: Find in Files...; ctrl+F3: Find Selection) where the highlighted text automatically entered in the find field.

----------
components: IDLE
messages: 149276
nosy: marco
priority: normal
severity: normal
status: open
title: Replace selected not working/consistent with find
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:31:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2011 06:31:23 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <E1RZzQ1-0003V6-Ir@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bf7329190ca6 by Raymond Hettinger in branch '2.7':
Issue #13573: The csv.writer now uses the repr() for floats rather than str().
http://hg.python.org/cpython/rev/bf7329190ca6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:58:23 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 12 Dec 2011 08:58:23 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323680303.57.0.913479321934.issue13544@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Pleasure :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:14:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 09:14:45 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1323681285.12.0.30370076485.issue6570@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Terry, does the latest patch look good to you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:48:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 09:48:03 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323683283.19.0.605505674141.issue13405@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Very high-level comments on your patch:

- why an empty "dtrace" module?

- I'm worried that you're adding lots of delicate code inside critical core functions. Perhaps most of it can be factored out in separate functions living in another (dtrace-specific) C file? I don't think we really want to maintain some asm("nop") in the GC module, and I'm not even talking about the madness in ceval.c.

- instead of generating code data (line numbers etc.) up front, why not generate and cache it lazily? that way, it would only be generated when the probes are really used (IIUC)

For higher-level benchmarks, I suggest you take a look at http://hg.python.org/benchmarks/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:52:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 09:52:18 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323683538.88.0.549182419023.issue8684@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not convinced by the decorator approach. Why not simply add "with self.lock" at the beginning of each protected method? It would actually save a function call indirection.

----------
stage:  -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:57:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 12 Dec 2011 09:57:49 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1323581916.04.0.448885739763.issue13405@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3K2HvO6qM+gps95Am4==cs4HK=rdfAo01tPybXhZ7yNg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Alan, I would open a new issue tracking this one and posting a patch there, if I were you.
>
> Previous DTRACE attempts failed because trying to make everybody happy. I don't want to repeat the mistake.
>

Sorry, but I'm -1.
I don't feel comfortable with adding a such amount of intrusive code,
which will have to be maintained as the interpreter evolves, to add
probes just for Solaris derivatives, which is, with all due respect,
really a niche platform. So If we merge this, this should at least
support SystemTap upfront.

> In fact this instrumentalization can be used to locate hotspots in python interpreter and maybe improve overall performance.

You can already go a really long way with just strace and oprofile, I
don't really but the performance optimization argument.

Also, I must admit I'm quite skeptical about the real benefit of
explicit probes for user-land, especially for CPython which isn't used
for performance-critical systems...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:09:24 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 12 Dec 2011 10:09:24 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323684564.62.0.0171311317676.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Are you suggesting to enable thread-synchronization by default and get rid of explicit "synchronized" argument?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:09:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 10:09:45 +0000
Subject: [issue7867] Proposed FAQ entry on pass-by-? semantics and the meaning
	of 'variable' in python
In-Reply-To: <1265490255.73.0.743157337936.issue7867@psf.upfronthosting.co.za>
Message-ID: <1323684585.33.0.557750830759.issue7867@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +rprosser
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7867>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:15:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 10:15:48 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1323684564.62.0.0171311317676.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323684935.21067.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Are you suggesting to enable thread-synchronization by default and get
> rid of explicit "synchronized" argument?

That would be even better indeed, if you find out that there's no
significant performance degradation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:47:03 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 Dec 2011 10:47:03 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <CAH_1eM3K2HvO6qM+gps95Am4==cs4HK=rdfAo01tPybXhZ7yNg@mail.gmail.com>
Message-ID: <CAPkN8xJfTX7=H2pWYN5Eyja79b=iqsEWAjTnArDKcQDsPXdd2g@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

2011/12/12 Charles-Fran?ois Natali <report at bugs.python.org>

>
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
>
> > Alan, I would open a new issue tracking this one and posting a patch
> there, if I were you.
> >
> > Previous DTRACE attempts failed because trying to make everybody happy.
> I don't want to repeat the mistake.
> >
>
> Sorry, but I'm -1.
> I don't feel comfortable with adding a such amount of intrusive code,
> which will have to be maintained as the interpreter evolves, to add
> probes just for Solaris derivatives, which is, with all due respect,
> really a niche platform. So If we merge this, this should at least
> support SystemTap upfront.
>

Is SystemTap an alternative to DTrace? I see that SystemTap is only for
Linux, while DTrace is available also on MacOS and FreeBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:05:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 11:05:58 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323687958.63.0.231909332744.issue13577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, a couple of further (minor) issues:
- I don't think AssertionError is the right exception type. TypeError should be used when a type mismatches (e.g. "not an unicode object");
- you don't need to check for d_type being NULL, since other methods don't;
- if type_qualname == NULL, the original error should be retained.

Otherwise, looks good, thank you.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:13:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 12 Dec 2011 11:13:32 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323688412.68.0.823194579751.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This is what I get by using bench.py script attached to issue13451:

CURRENT VERSION (NO LOCK)

test_cancel                    : time=0.67457 : calls=1 : stdev=0.00000
test_empty                     : time=0.00025 : calls=1 : stdev=0.00000
test_enter                     : time=0.00302 : calls=1 : stdev=0.00000
test_queue                     : time=6.31787 : calls=1 : stdev=0.00000
test_run                       : time=0.00741 : calls=1 : stdev=0.00000


LOCK WITH DECORATOR (no synchronization)

test_cancel                    : time=0.70455 : calls=1 : stdev=0.00000
test_empty                     : time=0.00050 : calls=1 : stdev=0.00000
test_enter                     : time=0.00405 : calls=1 : stdev=0.00000
test_queue                     : time=6.23341 : calls=1 : stdev=0.00000
test_run                       : time=0.00776 : calls=1 : stdev=0.00000


LOCK WITHOUT DECORATOR (always synchronized)

test_cancel                    : time=0.69625 : calls=1 : stdev=0.00000
test_empty                     : time=0.00053 : calls=1 : stdev=0.00000
test_enter                     : time=0.00397 : calls=1 : stdev=0.00000
test_queue                     : time=6.36999 : calls=1 : stdev=0.00000
test_run                       : time=0.00783 : calls=1 : stdev=0.00000


Versions #2 and #3 have the same cost, so it's better to get rid of the explicit argument and always use the lock (version #3).
Differences between #1 and #3 suggest that introducing the lock obviously have a cost though.
It's not too high IMO, but I couldn't say whether it's acceptable or not.
Maybe it makes sense to provide it as a separate class (SynchronizedScheduler).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:17:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 11:17:16 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1323688412.68.0.823194579751.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323688624.21067.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Versions #2 and #3 have the same cost, so it's better to get rid of
> the explicit argument and always use the lock (version #3).
> Differences between #1 and #3 suggest that introducing the lock
> obviously have a cost though.
> It's not too high IMO, but I couldn't say whether it's acceptable or
> not.

It looks quite negligible to me. Nobody should be affected in practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:18:56 2011
From: report at bugs.python.org (kxroberto)
Date: Mon, 12 Dec 2011 11:18:56 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323688736.04.0.379367816874.issue13580@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

>> (I often wonder why software today isn't much faster than years ago -
>> though the nominal speed of hardware increases tremendously. package
>> sizes grow, without appropriate growth of functionality. This is one
>> example how the rescources are wasted too careless.)
> I don't know of any evidence that software slowness has to do with code
> size. When code isn't called, it doesn't pollute the instruction caches
> and hence shouldn't affect execution speed.

With slowness under the subject here I mean long startup time  (and slowness by overall memory impact on small systems like laptops, non-cutting edge hardware, even embedded systems.). Thats what is mainly unpleasant and what seems to not improve appropriately overall. 
Developers carelessly link bigger and bigger libraries which eats the hardware gains ...
There are however some good efforts: For example when Google came out with Chrome (and many after fast responding apps), fast startup time was the striking issue. And the old browsers meanwhile were challenged by that, and improved as well.

Please keep Python fast as well. I'm using it since 1.5.2, and that careless fatty degeneration is one of the main things I don't like. 
Python is a universal language. Most Python progs are small scripts.

Overall I wonder why you post here on the main topic "resource usage", when you don't care about issues of magnitude 2x memory usage. Why not close this topic for Python at all with your arguments?

>
> I understand the concern about py2exe and similar distribution systems
> (although distribution size should be much less important nowadays than
> 10 years ago). But, really, it's a separate issue.

that is not really a separate issue (because module decoupling is a pre-requisite therefor, a sort of show stopper).

And as mentioned its by far not the only issue.

>
>> For example each cgi script (which has to respond fast and does only a
>> small job), which does  "import cgi" and a few lines; or a script
>> which just uses e.g., urllib string format functions ... : the whole
>> thing is drawn.
> Well, CGI scripts are a wasteful way to do programmatic page serving. If
> you care about performance, you should have switched to something like
> FastCGI or mod_wsgi.

And how about other "scripts" ;-) 

I'm sure you find everywhere something how you can make all app programmers busy and not take care of the few cheap fixes mentioned in the system to make Python faster und usable easily for everybody.
I created this issue to improve Python and make experience significantly faster.
You seem to me being too interested in closing issues fast.

>If you care about performance

You have this sort of black-white arguments which are green and somehow really I think, you are perhaps misplaced in this category "resource usage".

>
>>>> Also the linkage of _ssl solely against a detailed version of
>>>> libssl/libcrypto is still questionable.
>>> I don't know the reasons (if any). Perhaps you can open a separate issue
>>> about that?
>> Yet the issue of this library is here now. Why procrastinate?
> This sentence sounds like you want to dictate us what and how we should
> work on. That won't fly, sorry. The reason we want to avoid tackling
> multiple issues in a single tracker entry is simply so that the entries
> stay readable and searchable.
>
> (and, really, most projects' bug trackers work that way, for the same
> reasons)

You are free to divide the issue if you really think its worth multiple.
But why close it swift-handed before that is sorted out / set up? I indeed wonder about that careless style here meanwhile. Its not as it was years ago.

To me this "issues" seem to belong rather so close together, that the possible fix should perhaps be made in one go.

>> (The Debians would have gone rather deep into issues when they really
>> created that fine tuning on their own. almost can't believe.
> There's nothing magical about libssl that would make us link it
> statically to the executable; it's far too optional a dependency for
> that. Perhaps Debian has its own bootstrapping requirements that mandate
> it, or perhaps they simply made a mistake and nobody complained before?
> Why don't you open an issue on their bug tracker, or at least try to
> contact them? You would get a definite answer about it.

So are you definitely saying/knowing, there is really no such mentioned optimized module selection  (~50% of so modules since Python2.5 on Debian) somewhere in the Python build files?
(I ask first here to not create unnecessary lots of issues)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:41:06 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 12 Dec 2011 11:41:06 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323690066.56.0.218350938124.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

New patch in attachment. I'll commit it later today.

----------
nosy: +rhettinger
Added file: http://bugs.python.org/file23925/sched-thread-safe.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:49:56 2011
From: report at bugs.python.org (sbt)
Date: Mon, 12 Dec 2011 11:49:56 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323690596.51.0.612122149444.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Patch which add __qualname__ to builtin_function_or_method.  Note that I had to make a builtin staticmethod have __self__ be the type instead of None.

----------
Added file: http://bugs.python.org/file23926/method_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:50:25 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 12 Dec 2011 11:50:25 +0000
Subject: [issue13451] sched.py: speedup cancel() method
In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za>
Message-ID: <1323690625.8.0.547488317763.issue13451@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Thread locks introduced in issue8684 should make this change more robust.
If this patch is reasonable, I'd like to commit it before the one in issue8684 for simplicity.
Raymond?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13451>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:56:23 2011
From: report at bugs.python.org (sbt)
Date: Mon, 12 Dec 2011 11:56:23 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323690983.09.0.164497179342.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Ok, a couple of further (minor) issues:
> - I don't think AssertionError is the right exception type. TypeError 
> should be used when a type mismatches (e.g. "not an unicode object");
> - you don't need to check for d_type being NULL, since other methods don't;
> - if type_qualname == NULL, the original error should be retained.

Fixed.  (I suspect, though, that caching the value of __qualname__ is an unnecessary optimisation.)

----------
Added file: http://bugs.python.org/file23927/descr_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:58:53 2011
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2011 11:58:53 +0000
Subject: [issue9856] Change object.__format__(s) where s is non-empty to a
	TypeError
In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>
Message-ID: <1323691133.35.0.65946714345.issue9856@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9856>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:14:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 12:14:31 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323688736.04.0.379367816874.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323692057.21067.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Overall I wonder why you post here on the main topic "resource usage",
> when you don't care about issues of magnitude 2x memory usage.

Because you are talking about a fixed overhead of a mere 2MB (IIUC),
which is moreover shared between all processes using libssl/libcrypto
(and chances are these libraries are already loaded by something else on
your system - crypto is useful after all - so Python would actually not
add anything substantial in that regard). It is IMHO not interesting at
all, but still, you are welcome to post an issue about it if you are
concerned.

On the other hand, we do care about "resource usage" issues when they
are about dynamic memory consumption, e.g. reducing the size of objects.
Or, of course, memory leaks.

[...]
> You have this sort of black-white arguments which are green and
> somehow really I think, you are perhaps misplaced in this category
> "resource usage".
[...]
> I indeed wonder about that careless style here meanwhile. Its not as
> it was years ago.

Nobody here is interested in exchanging personal attacks, I'm afraid.

> You are free to divide the issue if you really think its worth multiple.
> But why close it swift-handed before that is sorted out / set up?

It *is* sorted out. You complained about libssl being linked into the
executable and it turned out to be Debian-specific. Just because you
think there is some kind of "big picture" problem involved doesn't make
it ok to turn this issue into a catch-all for all related issues.

> So are you definitely saying/knowing, there is really no such
> mentioned optimized module selection  (~50% of so modules since
> Python2.5 on Debian) somewhere in the Python build files?
> (I ask first here to not create unnecessary lots of issues)

Let's say that I don't know about such a selection, and neither probably
do other core developers on this issue, otherwise they would already
have chimed in. There is certainly no such documented or tested thing,
anyway, so even if there were I wonder why the Debian people would
decide to use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:40:54 2011
From: report at bugs.python.org (Bithin A)
Date: Mon, 12 Dec 2011 12:40:54 +0000
Subject: [issue13587] Correcting the typos error in Doc/howto/urllib2.rst
Message-ID: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za>


New submission from Bithin A <bithin2007 at gmail.com>:

In the documentation 'HOWTO Fetch Internet Resources Using urllib2' there is a correction under the heading 'Basic Authentication'

In the line 'The header looks like : ``Www-authenticate: SCHEME realm="REALM"``. ' the word 'Www-authenticate' should be written as 'WWW-Authenticate' . 

Link : docs.python.org/howto/urllib2.html

----------
assignee: docs at python
components: Documentation
messages: 149295
nosy: Bithin.A, docs at python
priority: normal
severity: normal
status: open
title: Correcting the typos error in Doc/howto/urllib2.rst
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13587>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:47:27 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 12 Dec 2011 12:47:27 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323694047.28.0.183647855827.issue13248@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
dependencies: +Change object.__format__(s) where s is non-empty to a TypeError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:47:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2011 12:47:41 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <E1Ra5IC-0004Li-6M@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 24238e89f938 by Antoine Pitrou in branch 'default':
Issue #13577: various kinds of descriptors now have a __qualname__ attribute.
http://hg.python.org/cpython/rev/24238e89f938

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:01:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 13:01:27 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323694887.16.0.605325109688.issue13248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think most of these shouldn't be removed, as it would make porting from 2.x significantly more tedious.

Things that I think can be removed:
- max_buffer_size (io is new and that argument was never used by anybody)
- get_prefix / set_prefix (the internal lib2to3 API is not documented AFAICT)
- the argparse things (argparse is new)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:13:37 2011
From: report at bugs.python.org (psam)
Date: Mon, 12 Dec 2011 13:13:37 +0000
Subject: [issue13539] Return value missing in calendar.TimeEncoding.__enter__
In-Reply-To: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za>
Message-ID: <1323695617.1.0.779523586239.issue13539@psf.upfronthosting.co.za>


psam <pk.samson at gmail.com> added the comment:

The problem was detected in a Django project, as the template engine was not able to support the original encoding.
I don't have a real test code snippet, but you may try something like:

isinstance(calendar.LocaleTextCalendar(locale='').formatmonth(2011,12),unicode)

Note: for Windows, locale='' or locale='fra_FRA' are ok, not locale='fr_FR' or no specified locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13539>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:14:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Dec 2011 13:14:04 +0000
Subject: [issue13539] Return value missing in calendar.TimeEncoding.__enter__
In-Reply-To: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za>
Message-ID: <1323695644.29.0.179518239949.issue13539@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/issue13539>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:27:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 13:27:09 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323696429.84.0.881145296297.issue13577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

About method_qualname.patch:

- apparently you forgot to add BuiltinFunctionPropertiesTest in test_main()?

- a static method keeps a reference to the type: I think it's ok, although I'm not sure about the consequences (Guido, would you have an idea?)

- about "XXX Note that it is not possible to use __qualname__ to distinguish a builtin bound instance method from its unbound equivalent", I don't think it's a problem. People can e.g. check for __self__:

>>> list.append.__self__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'method_descriptor' object has no attribute '__self__'
>>> list().append.__self__
[]

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:39:16 2011
From: report at bugs.python.org (Philipp Lies)
Date: Mon, 12 Dec 2011 13:39:16 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323697156.5.0.195851202025.issue13555@psf.upfronthosting.co.za>


Philipp Lies <phil at bethgelab.org> added the comment:

a) it's 122GB free RAM (out of 128GB total RAM)

b) when I convert the numpy array to a list it works. So seems to be a problem with cPickle and numpy at/from a certain array size

c) $ /usr/bin/time -v python test_np.py 
Traceback (most recent call last):
  File "test_np.py", line 12, in <module>
    A2 = cPickle.load(f2)
MemoryError
Command exited with non-zero status 1
	Command being timed: "python test_np.py"
	User time (seconds): 73.72
	System time (seconds): 4.56
	Percent of CPU this job got: 87%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 1:29.52
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 7402448
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 726827
	Voluntary context switches: 41043
	Involuntary context switches: 7793
	Swaps: 0
	File system inputs: 3368
	File system outputs: 2180744
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 1

hth

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:56:34 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 12 Dec 2011 13:56:34 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323698194.58.0.852257232733.issue13248@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file23905/issue13248_obsolescence.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:57:18 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 12 Dec 2011 13:57:18 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323698238.26.0.183360316913.issue13248@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
dependencies:  -Change object.__format__(s) where s is non-empty to a TypeError
Added file: http://bugs.python.org/file23928/issue13248_argparse_io_lib2to3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:04:03 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 12 Dec 2011 14:04:03 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323698643.83.0.0315615436595.issue13248@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I removed object.__format__ from the patch because it is not planned for removal in 3.3, but in 3.4 (see issue #9856).

I've fixed the documentation *versionchanged* and split the patch in two.
The first is less controversial.
The second might be delayed a little to ease the migration from 2.x to 3.x.

----------
Added file: http://bugs.python.org/file23929/issue13248_obsolescence_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:19:51 2011
From: report at bugs.python.org (sbt)
Date: Mon, 12 Dec 2011 14:19:51 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323699591.38.0.0312371233399.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> - apparently you forgot to add BuiltinFunctionPropertiesTest in 
> test_main()?

Yes.  Fixed.

> - a static method keeps a reference to the type: I think it's ok, although 
> I'm not sure about the consequences (Guido, would you have an idea?)

Interestingly, in the stdlib METH_STATIC is only used by (str|bytes|bytearray).maketrans and _multiprocessing.win32.*.

----------
Added file: http://bugs.python.org/file23930/method_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:39:23 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 14:39:23 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323659862.04.0.108345523123.issue13585@psf.upfronthosting.co.za>
Message-ID: <4EE61217.2040702@rath.org>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

On 12/11/2011 10:17 PM, Raymond Hettinger wrote:
> 
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
> 
> '''
> Example code:
> 
> with CleanupManager() als mngr:
>     tmpdir = tempfile.mkdtemp()
>     mngr.register(shutil.rmtree(tmpdir)) <-- this makes the call right away
>     # do stuff with tmpdir
> '''

Oh, of course. That is fixed in the patch. I couldn't find a way to edit
the message in the tracker.

> The part of my note that should be clear is that the idea and code need to prove itself before being added to the standard library.  So far, there has been zero demand for this and I've not seen code like it being used in the wild.  AFAICT, it is not demonstrably better than a straight-forward try/finally.

I think it has the same advantages over try...finally as any use of
'with' has. CleanupManager would allow to use 'with' instead of
'try..finally' in many cases where this is currently not possible, so
unless the introduction of 'with' itself was a mistake, I think this is
just taking a step along the path that has already been chosen.

Best,

   -Nikolaus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:49:15 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 12 Dec 2011 14:49:15 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323701355.66.0.268779624069.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

According to Stan Cox, this patch "almost" work with SystemTap. Moreover, there are work porting DTrace to Linux.

DTrace helping to improve performance is secondary. The real important thing is the "observability". It is difficult to understand the advantages without experimenting directly, but possibilities are endless.

Just an example:

Yesterday I was kind of worried about the memory cost in the last version. I know that the extra memory used is around 2*n, where "n" is the bytecode size. But what is that in a real world cost?.

I wrote the following dtrace script:

"""
unsigned long int tam;
unsigned int num;

pid$target::PyCode_New:entry
{
    self->flag=1;
}

pid$target::PyCode_New:return
{
    self->flag=0;
}

pid$target::PyMem_Malloc:entry
/self->flag/
{
    self->tam=arg0;
    tam+=arg0;
    num+=1;
    printf(\"%d %d\", num, tam);
}

pid$target::PyMem_Malloc:return
/self->flag/
{
    pos[arg1]=self->tam;
    self->tam=0;
}

pid$target::PyMem_Free:entry
/pos[arg0]/
{
    num-=1;
    tam-=pos[arg0];
    pos[arg0]=0;
}
"""

This code bookkeeps details about the extra allocations/deallocations at import/reload() time.

Note that this code DOESN'T use the new Python probes. You could use them, for instance, to know which module/function is doing the lion share of imports.

You launch this code with "dtrace -s SCRIPT.d -c COMMAND".

Some real world examples:

- Interactive interpreter invocation: 517 blocks, 95128 bytes.

- BitTorrent tracker with persistence (DURUS+BerkeleyDB) backend: 2122 blocks, 439332 bytes.

- Fully functional LMTP+POP3 server written in Python, with persistence (DURUS+BerkeleyDB) backend: 2182 blocks, 422288 bytes.

- RSS to Twitter gateway, with OAuth: 2680 blocks, 556636 bytes. Surprising the import weight that brings "feedparser" and "bitly" libraries.

So the memory hit seems pretty reasonable. And I can verify it without ANY change in Python.

In this case I am launching python "inside" dtrace because I want to see the complete picture, from the very beginning. But usually you "plug" a long running python process for a while, without stopping it at all, and when you are done, you shutdown the tracing script... without ANY disturbance of the running python program, that keeps working. For instance, your server code is being slow for some reason *NOW*. You use DTrace to study what the program is doing just NOW. You don't have to stop the program, add "debug" code to it an launch again and WAIT until the problem happens again, determine that your "debug" code is not helping, changing it, repeat...

This is observability. Difficult to explain. Life sucks when you are used to it and you don't have it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:53:07 2011
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 12 Dec 2011 14:53:07 +0000
Subject: [issue13571] Backup files support in IDLE
In-Reply-To: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>
Message-ID: <1323701587.75.0.654662035715.issue13571@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I rarely have IDLE crash on Linux. If you're experiencing these issues on Windows, see #13582.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13571>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:53:24 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Dec 2011 14:53:24 +0000
Subject: [issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat
	(libssl, libcrypto)
In-Reply-To: <1323596877.08.0.826417896896.issue13580@psf.upfronthosting.co.za>
Message-ID: <1323701604.58.0.201416615838.issue13580@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I just checked the file python2.6_2.6.6-8.diff.gz from the Debian python2.6 package: http://packages.debian.org/squeeze/python2.6

This diff file contains a """patch to build _hashlib and _ssl extensions statically""" that modifies Modules/Setup.dist
So it was definitely Debian choice to link to libssl.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13580>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:53:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 14:53:55 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1323701355.66.0.268779624069.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323701621.21067.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> - Interactive interpreter invocation: 517 blocks, 95128 bytes.

Note that http://bugs.python.org/issue13390 also proposes to count
allocations in the interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:57:35 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 Dec 2011 14:57:35 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1323701855.33.0.245889908399.issue13390@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

How different is the performance cost of this solution compared to inserting DTrace probe for the same purpose?

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:11:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Dec 2011 15:11:38 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1323702698.8.0.18635192143.issue13390@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> How different is the performance cost of this solution compared
> to inserting DTrace probe for the same purpose?

DTrace is only available on some platforms (Solaris and maybe FreeBSD?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:13:12 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 12 Dec 2011 15:13:12 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323702792.33.0.734335144949.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

> - why an empty "dtrace" module?

This is preliminary. I am thinking about dynamic probes, something like "logging" module but using dtrace. Still experimenting, not sure is actually possible.

Martin V L?wis suggested to use "sys.flags".

Undecided yet.

> - I'm worried that you're adding lots of delicate code inside
> critical core functions. Perhaps most of it can be factored out in
> separate functions living in another (dtrace-specific) C file? I
> don't think we really want to maintain some asm("nop") in the GC
> module, and I'm not even talking about the madness in ceval.c.

ceval.c madness is greatly reduced in the last version. I was not happy with it either. I am open to suggestions...

The point of DTrace probes is its very low overhead. If I change macros to external function calls, your performance will be suffer.

That said, I am open to suggestions, more understandable code, etc.

> - instead of generating code data (line numbers etc.) up front, why
> not generate and cache it lazily? that way, it would only be
> generated when the probes are really used (IIUC)

This case is special. This data is used by the kernel, when a DTrace script does a "jstack()". At this moment you can not CALL anything. You don't even have loops or "if".

Example: your program seems hangup, aparently. You can write a single line DTrace script to dump the jstack and see what your program is doing, even if it stuck in, let say, a function call. At this moment you can't call ANYTHING. So I precalculate the line offsets at import time, and use the table here. There is little else I can do, in kernel context.

> For higher-level benchmarks, I suggest you take a look at
> http://hg.python.org/benchmarks/

Good suggestions. I will check it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:15:42 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 12 Dec 2011 15:15:42 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1323702942.37.0.727757912343.issue13390@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/issue13390>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:19:47 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 Dec 2011 15:19:47 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1323702698.8.0.18635192143.issue13390@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xK7sQxtfXxC5OoVNYdZBF0hUtBtRy22A=XsOmmoTDDChA@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Dec 12, 2011 at 6:11 PM, STINNER Victor <report at bugs.python.org>wrote:

>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> > How different is the performance cost of this solution compared
> > to inserting DTrace probe for the same purpose?
>
> DTrace is only available on some platforms (Solaris and maybe FreeBSD?).
>

Solaris <http://en.wikipedia.org/wiki/Solaris_(operating_system)>, Mac
OS X<http://en.wikipedia.org/wiki/Mac_OS_X>
, FreeBSD <http://en.wikipedia.org/wiki/FreeBSD>,
NetBSD<http://en.wikipedia.org/wiki/NetBSD>
, Oracle Linux <http://en.wikipedia.org/wiki/Oracle_Linux> according to
http://en.wikipedia.org/wiki/DTrace#Supported_platforms, but that doesn't
relate to the question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:23:26 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 12 Dec 2011 15:23:26 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323703406.08.0.652604171579.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

>> - Interactive interpreter invocation: 517 blocks, 95128 bytes.
>
> Note that http://bugs.python.org/issue13390 also proposes to count
> allocations in the interpreter.

The thing is, I get this data WITHOUT touching python interpreter, using a DTrace script, and when I am done and I kill the script, any malloc/free overhead will disappear. And the program keeps running...

Notice too, that the data I am showing is the extra memory I am using for the dtrace stack helper, not all python memory (if you check the dtrace script, I only contabilize "PyMem_Malloc()" when called from "PyCode_New()").

DTrace allows me to be quirurgic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:26:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 15:26:45 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1323703406.08.0.652604171579.issue13405@psf.upfronthosting.co.za>
Message-ID: <1323703591.21067.25.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Notice too, that the data I am showing is the extra memory I am using
> for the dtrace stack helper, not all python memory (if you check the
> dtrace script, I only contabilize "PyMem_Malloc()" when called from
> "PyCode_New()").
> 
> DTrace allows me to be quirurgic.

I am not disputing the flexibility of dtrace. However, it is also
platform-specific, and needs you to learn a dedicated programming
language and API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:30:37 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Dec 2011 15:30:37 +0000
Subject: [issue13572] import _curses fails because of
	UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on
	ARM Ubuntu 3.x
In-Reply-To: <1323524849.05.0.773120918069.issue13572@psf.upfronthosting.co.za>
Message-ID: <1323703837.57.0.926492510409.issue13572@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This fails for me on OS X Snow Leopard using LLVM 3.0.

And I agree with your initial guess, Victor: I don't see how importlib could possibly be the issue here since it's using load_dynamic() and not loading some Python source itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13572>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:32:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Dec 2011 15:32:34 +0000
Subject: [issue13588] Change name of internal closure functions in importlib
Message-ID: <1323703954.36.0.434643027987.issue13588@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The internal closure functions (eg. wrapper functions used by decorators) should not use generic names like inner() or wrapper(), but descriptive names so that they make sense when read in a traceback. IOW, you shouldn't have to look up the source code to figure out what decorator's wrapper is found in the traceback.

----------
components: Library (Lib)
keywords: easy
messages: 149315
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Change name of internal closure functions in importlib
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13588>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:35:18 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Dec 2011 15:35:18 +0000
Subject: [issue13582] IDLE and pythonw.exe stderr problem
In-Reply-To: <1323632290.53.0.810720020667.issue13582@psf.upfronthosting.co.za>
Message-ID: <1323704118.12.0.481332913629.issue13582@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"terminate abruptly"? I thought that print(file=None) silently returned, without printing but without an error.
A delayed popup to display (otherwise discarded) output is a nice feature, though.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13582>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:46:17 2011
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 12 Dec 2011 15:46:17 +0000
Subject: [issue13582] IDLE and pythonw.exe stderr problem
In-Reply-To: <1323632290.53.0.810720020667.issue13582@psf.upfronthosting.co.za>
Message-ID: <1323704777.87.0.897501982554.issue13582@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

You can try triggering bug #8900 quite simply. From a shell or an editor, press Ctrl+N and then Ctrl+O. Open a file and watch IDLE terminate abruptly.

Also, see #12274.

If you want to play with this problem further, try adding a "raise Exception" to a constructor for one of the extensions. Running IDLE using python.exe will display a traceback in the console, but IDLE keeps running. However, IDLE won't even bring up a window when using pythonw.exe; it just fails to launch from the user's perspective.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13582>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:53:47 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 Dec 2011 15:53:47 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1323703591.21067.25.camel@localhost.localdomain>
Message-ID: <CAPkN8xLYCgvOh5GbZvtoHHnWwaau2zPveVO1PC3JsioW35AGJg@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Dec 12, 2011 at 6:26 PM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> I am not disputing the flexibility of dtrace. However, it is also
> platform-specific, and needs you to learn a dedicated programming
> language and API.

If it is flexible, then I won't see any problems to create a pythonic
interface for it.  If you want to inspect Python in real-time from itself -
that's I believe is another story.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:01:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 12 Dec 2011 16:01:33 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323705693.6.0.980750523604.issue13555@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

@Antoine
Couldn't this be linked to #11564 (pickle not 64-bit ready)? AFAICT this wasn't fixed in 2.7. Basically, an integer overflow, and malloc() would bail out when asked a ridiculous size.

@Philipp
I'd be curious to see the last lines of
$ ltrace -e malloc python test_np.py

you'll probably see a call to malloc() return NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:02:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Dec 2011 16:02:18 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323705738.19.0.326431720638.issue13248@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Given the discussions we?ve had this month and a few months earlier about people porting directly to 3.2 or 3.3, I think the second patch needs to wait for 3.4 or 3.5.  (I have no opinion on the first patch, not being a customer of lib2to3 or pyio.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:02:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 12 Dec 2011 16:02:22 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323705742.53.0.177059951538.issue13555@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

@Antoine
Couldn't this be linked to #11564 (pickle not 64-bit ready)? Basically, an integer overflow, and malloc() would bail out when asked a ridiculous size. AFAICT this wasn't fixed in 2.7. 

@Philipp
I'd be curious to see the last lines of
$ ltrace -e malloc python test_np.py

you'll probably see a call to malloc() return NULL.
Also, depending on Antoine's answer, trying with default (3.3) could be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:03:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 12 Dec 2011 16:03:24 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323705804.71.0.979905203537.issue13555@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
Removed message: http://bugs.python.org/msg149321

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:04:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 16:04:14 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1323705854.81.0.757548064315.issue13248@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think it would be better to decide in what version each thing will be removed and then mark them with the deprecated-removed directive in the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:06:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Dec 2011 16:06:34 +0000
Subject: [issue13539] Return value missing in calendar.TimeEncoding.__enter__
In-Reply-To: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za>
Message-ID: <1323705994.91.0.515533235785.issue13539@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know this module well, so I?m adding Georg, who last changed that method, and other people from #10092 to the nosy list.

----------
nosy: +JJeffries, Retro, christian.heimes, georg.brandl, ixokai, r.david.murray, tim.golden, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13539>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:09:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Dec 2011 16:09:19 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323706159.83.0.683585261917.issue13521@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the idea Jes?s, even though I didn?t get the change to use it :)

Filip: Is there a reasons for using a nonlocal count rather than e.g. self.count?  Otherwise the test looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:11:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Dec 2011 16:11:54 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1323706314.16.0.572302695297.issue5689@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Lars, as part of a small doc patch I want to change this in tarfile.rst:

   The :mod:`tarfile` module makes it possible to read and write tar
   archives, including those using gzip or bz2 compression.
  -(:file:`.zip` files can be read and written using the :mod:`zipfile` module.)
  +Use the :mod:`zipfile` module to read or write :file:`.zip` files, or the
  +higher-level functions in :ref:`shutil <archiving-operations>`.

Any objection?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:20:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 16:20:22 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323706822.67.0.204022049041.issue13555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Couldn't this be linked to #11564 (pickle not 64-bit ready)?

Well, I don't know anything about numpy, but:

>>> 196 * 240000
47040000
>>> 196 * 240000 * 8   # assuming 8 bytes per float
376320000
>>> 2**31
2147483648

So it seems unlikely to be the explanation. After all the report says ">1GB" for the file size, which is still comfortably in the capabilities of a 32-bit module.

Philipp, perhaps you could try to run Python under gdb and try to diagnose where the MemoryError occurs?

Also, posting the disassembly (using pickletools.dis()) of a very small equivalent pickle (e.g. of randn(2,3)) could help us know what is involved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:25:04 2011
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2011 16:25:04 +0000
Subject: [issue13588] Change name of internal closure functions in importlib
In-Reply-To: <1323703954.36.0.434643027987.issue13588@psf.upfronthosting.co.za>
Message-ID: <1323707104.34.0.462777364335.issue13588@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13588>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:35:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 16:35:36 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1323707736.46.0.700024541347.issue13555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, what's more interesting is that it works here (Python 2.7.1 and numpy 1.6.1 under Mageia with 8GB RAM). Looking at a pickle disassembly, the only remarkable thing is the presence of a long binary string (the raw serialization of all IEEE floats), which shouldn't give any problem to cPickle (and indeed doesn't). What is your numpy version, Philipp?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:44:56 2011
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2011 16:44:56 +0000
Subject: [issue11175] allow argparse FileType to accept encoding and errors
	arguments
In-Reply-To: <1297352833.64.0.0994986830559.issue11175@psf.upfronthosting.co.za>
Message-ID: <1323708296.71.0.923317663569.issue11175@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11175>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:47:58 2011
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2011 16:47:58 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323708478.42.0.0858891440186.issue11468@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:48:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 16:48:17 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1323706159.83.0.683585261917.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323708482.21067.34.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Filip: Is there a reasons for using a nonlocal count rather than e.g.
> self.count?  Otherwise the test looks good.

Eric, please, could we stop such pointless nitpicking about one's
stylistic preferences? "nonlocal" is as good as any other solution here,
and reviewing is not supposed to be a pedantry contest. There are tons
of serious issues to be solved where your energy would be better spent,
IM(NSH)O.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:53:35 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 12 Dec 2011 16:53:35 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323708815.75.0.968865484981.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I haven't given it much thought, when I was making the choice of using nonlocal rather than self.count. I was rather excited to see, if the change will work as I wanted it to. If you believe it would be better to use an attribute, I'll be happy to change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:55:40 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 12 Dec 2011 16:55:40 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323708940.66.0.358002390249.issue13521@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Well, if this is going to be applied to 2.7, "nonlocal" is invalid syntax there. I guess that being able to use the same test in 2.7 and 3.2/3.3 would be nice. Style, but justified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:56:30 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 12 Dec 2011 16:56:30 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1323708990.12.0.854320824626.issue5689@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Please, go ahead!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:05:09 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 12 Dec 2011 17:05:09 +0000
Subject: [issue13588] Change name of internal closure functions in importlib
In-Reply-To: <1323703954.36.0.434643027987.issue13588@psf.upfronthosting.co.za>
Message-ID: <1323709509.63.0.286325293193.issue13588@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13588>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:09:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 17:09:35 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323709775.16.0.304919738353.issue13521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, if this is going to be applied to 2.7, "nonlocal" is invalid
> syntax there.

Ah, good point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:17:52 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 12 Dec 2011 17:17:52 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323710272.83.0.503262286644.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I'll send a patch, when I get home from work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:19:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2011 17:19:05 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323710345.0.0.953947737935.issue11468@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll be updating this example shortly, but it is intentional that it include only assertEqual, assertTrue, and assertRaises.  Those three are the minimum necessary to get up and running (which is the whole point of the BASIC example).

----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:20:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2011 17:20:10 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323710410.76.0.407926478536.issue13521@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Let's just start with a working 2.7 patch and go from there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:31:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 17:31:52 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323711112.62.0.570986274645.issue13544@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I suppose the status can be switched to "closed"?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:33:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 17:33:42 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <1323711222.31.0.200624231273.issue13575@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:39:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Dec 2011 17:39:16 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323711556.62.0.135294543592.issue13505@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Only worry is that codecs.latin_1_encode.__module__ is '_codecs', and
> _codecs is undocumented.

It seems we have to choose between two evils here. Given that the codecs.latin_1_encode produces more compact pickles, I'd say go for it.

Note that for the empty bytes object (b""), the encoding can be massively simplified by simply calling bytes() with no argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:46:49 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Dec 2011 17:46:49 +0000
Subject: [issue13544] Add __qualname__ to functools.WRAPPER_ASSIGNMENTS
In-Reply-To: <1323213627.82.0.936879415754.issue13544@psf.upfronthosting.co.za>
Message-ID: <1323712009.5.0.509457911304.issue13544@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Yup, oversight on my part.  Thanks.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13544>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:49:55 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 17:49:55 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323712195.18.0.465839028579.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23734/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:52:53 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 17:52:53 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323712373.66.0.811437653801.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Sounds perfectly reasonable. Here goes the first patch with pure test coverage.

----------
Added file: http://bugs.python.org/file23931/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:55:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2011 17:55:57 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <E1RaA6R-0000gc-Bd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 021e5bb297d1 by Florent Xicluna in branch 'default':
Issue #13575: there is only one class type.
http://hg.python.org/cpython/rev/021e5bb297d1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:56:28 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 12 Dec 2011 17:56:28 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <1323712588.29.0.360698540657.issue13575@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:21:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 18:21:52 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323714112.23.0.677198443944.issue11468@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch includes only assertEqual, assertTrue, and assertRaises and, except a s/functions/methods/ in the first line, looks good to me.

----------
stage: needs patch -> commit review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:31:27 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:31:27 +0000
Subject: [issue13589] Aifc float serialization fix
Message-ID: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

1. Fixed _write_float to handle infinity, NaN and negative numbers correctly.
2. Renamed _write_long to _write_ulong because it actually writes unsigned value.
3. Added _read_ushort as counterpart of _write_ushort. This is never used anywhere except test that ushorts are written correctly. But it seems right to me to have both read and write function in the same module.

----------
components: Library (Lib)
files: aifc_numbers_fix.patch
keywords: patch
messages: 149343
nosy: Oleg.Plakhotnyuk, ezio.melotti, r.david.murray
priority: normal
severity: normal
status: open
title: Aifc float serialization fix
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23932/aifc_numbers_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:33:34 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:33:34 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323714814.77.0.51782405199.issue13589@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Patch must be applied after http://bugs.python.org/file23931/test_aifc.patch from issue 13394.
Not sure if review tool can handle this correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:34:20 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:34:20 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323714860.21.0.762194829884.issue13589@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Second patch goes to issue 13589

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:35:46 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:35:46 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323714946.55.0.22777804092.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Second patch goes to issue 13589

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:37:39 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:37:39 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323715059.82.0.776052421515.issue13589@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:38:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2011 18:38:33 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323715113.53.0.650526282827.issue11468@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Ezio, please leave this one for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:46:14 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 18:46:14 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323715574.36.0.28980449157.issue13585@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file23933/CleanupManager_patch_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:50:20 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:50:20 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323715820.14.0.696415277416.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23931/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:50:51 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:50:51 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323715851.15.0.287887490125.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Added file: http://bugs.python.org/file23934/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:55:11 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 12 Dec 2011 18:55:11 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323716111.93.0.704275908944.issue13585@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/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:56:08 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:56:08 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323716168.29.0.366201476292.issue13589@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23932/aifc_numbers_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:57:20 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:57:20 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323716240.52.0.460566191607.issue13589@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Forget about "patch must be applied before" thing.
I've made independent patch. :-)

----------
Added file: http://bugs.python.org/file23935/aifc_numbers_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Mon Dec 12 20:00:06 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 12 Dec 2011 19:00:06 +0000
Subject: [issue11647] function decorated with a context manager can only be
	invoked once
In-Reply-To: <1300845878.3.0.475491224846.issue11647@psf.upfronthosting.co.za>
Message-ID: <1323716406.72.0.872017442906.issue11647@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/issue11647>
_______________________________________

From report at bugs.python.org  Mon Dec 12 20:34:29 2011
From: report at bugs.python.org (Raul Morales)
Date: Mon, 12 Dec 2011 19:34:29 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323718469.9.0.532428206099.issue13516@psf.upfronthosting.co.za>


Raul Morales <raul.mh at gmail.com> added the comment:

I use a similar code in my scripts, but I thought it could be useful to have this feature built into python.

If you prefer subclassing for compression, what about a compressing subclass built into logging package?

If you think it is a good feature, I will be able to work on it next week, and to add support for other formats.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Mon Dec 12 20:43:49 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 12 Dec 2011 19:43:49 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323719029.11.0.00381628803207.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have tried to port patch to python2.7, but apparently I must be doing something wrong, because while most tests pass, several fail (including tests for unittest itself).

I would like to continue working on this test, but incoming week is pretty intensive for me. Is it ok if I returned to working on this during the weekend?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Mon Dec 12 20:55:26 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 12 Dec 2011 19:55:26 +0000
Subject: [issue9856] Change object.__format__(s) where s is non-empty to a
	TypeError
In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>
Message-ID: <1323719726.17.0.799685372024.issue9856@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch is ready for python 3.4

:-)

----------
keywords: +patch
nosy: +flox
Added file: http://bugs.python.org/file23936/issue9856_python-3.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9856>
_______________________________________

From report at bugs.python.org  Mon Dec 12 21:31:24 2011
From: report at bugs.python.org (Sven Marnach)
Date: Mon, 12 Dec 2011 20:31:24 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323721884.83.0.437479078088.issue13585@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

There is actually a second thread on python-ideas on a very similar topic, see

    http://mail.python.org/pipermail/python-ideas/2011-December/013021.html

The two main advantages of the proposed CleanupManager over try/finally blocks are

1. You can add a clean-up function conditionally.  In a try/finally block, you would need a flag, which would scatter the single idea more across the code.  Example:

    with CleanupManager() als mngr:
        if f is None:
            f = open("some_file")
            mngr.register(f.close)
        # do something with f (possibly many lines of code)

seems much clearer to me than

    f_needs_closing = False
    if f is None:
        f = open("some_file")
        f_needs_closing = True
    try:
        # do something with f (possibly many lines of code)
    finally:
        if f_needs_closing:
            f.close()

The first version is also much more in the spirit of context managers.  You state at the beginning "we open the file, and guarantee that it will be closed", and we know right from the start that we don't have to bother with it again.

2. CleanupManager could replace several nested try/finally blocks, which again might lead to more readable code.

On the other hand, people who never saw ContextManager before will have to look it up, which will impair readability for those people.

Adding this as a cookbook recipe first seems like a good idea.

----------
nosy: +smarnach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 21:43:19 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 20:43:19 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323721884.83.0.437479078088.issue13585@psf.upfronthosting.co.za>
Message-ID: <4EE66761.6040201@rath.org>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

On 12/12/2011 03:31 PM, Sven Marnach wrote:
> Adding this as a cookbook recipe first seems like a good idea.

This is the second time that this is mentioned, so I would be very
grateful if someone could elucidate what "adding as a cookbook recipe"
means :-). Is there an official Python cookbook somewhere?

Best,

   -Nikolaus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 21:54:15 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 12 Dec 2011 20:54:15 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323723255.71.0.205110638839.issue13585@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Check out: http://code.activestate.com/recipes/

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:16:36 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 12 Dec 2011 21:16:36 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323724596.85.0.6445461751.issue13516@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I have worked out a possible approach. I will post about it soon, and add a link to it from this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:22:58 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Mon, 12 Dec 2011 21:22:58 +0000
Subject: [issue13590] Prebuilt python-2.7.2 binaries for macosx can not
	compile c extensions
Message-ID: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>


New submission from K Richard Pixley <rich at noir.com>:

Install the Python-2.7.2 mac installer for Lion on Lion.

Then attempt "easy_install -U psutil".  I get:

za-dc-dev/bin/easy_install -U psutil
install_dir /Users/rich/projects/za-packages/za-dependency-checker/za-dc-dev/lib/python2.7/site-packages/
Searching for psutil
Reading http://pypi.python.org/simple/psutil/
Reading http://code.google.com/p/psutil/
Best match: psutil 0.4.0
Downloading http://psutil.googlecode.com/files/psutil-0.4.0.tar.gz
Processing psutil-0.4.0.tar.gz
Running psutil-0.4.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7euim1/psutil-0.4.0/egg-dist-tmp-QRoCe6
unable to execute gcc-4.2: No such file or directory
error: Setup script exited with error: command 'gcc-4.2' failed with exit status 1
make: *** [za-dc-dev/lib/python2.7/site-packages/psutil-1.1.2-py2.7.egg] Error 1


There is no binary named "gcc-4.2" on my system.  I'm running the latest Xcode, (4.2.1).  And gcc in my PATH is a 4.2 binary:

rich at fuji-land.noir.com> type gcc
gcc is hashed (/usr/bin/gcc)
rich at fuji-land.noir.com> gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 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.


I see no reference to "gcc-4.2" in psutils source nor in distutils.  From this I guess that the python configuration is looking for the same compiler that was used to produce the package, (presumably on osx-10.6).

Other developers tell me that they have a "gcc-4.2" on osx-10.6.  And indeed, downloading and building python-2.7.2 from source results in a python that can download and compile psutil.

----------
assignee: ronaldoussoren
components: Extension Modules, Macintosh
messages: 149356
nosy: ronaldoussoren, teamnoir
priority: normal
severity: normal
status: open
title: Prebuilt python-2.7.2 binaries for macosx can not compile c extensions
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:24:53 2011
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Mon, 12 Dec 2011 21:24:53 +0000
Subject: [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1323725093.1.0.803967760911.issue13557@psf.upfronthosting.co.za>


Stephan R.A. Deibel <sdeibel at wingware.com> added the comment:

Here's a patch to the docs that notes the issue and refers the reader to the relevant execution model docs page.  I have also attempted to clarify the "interaction with dynamic features" section of the execution model page.

----------
keywords: +patch
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23937/exec-eval-clarification.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13557>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:43:24 2011
From: report at bugs.python.org (Ryan Twitchell)
Date: Mon, 12 Dec 2011 21:43:24 +0000
Subject: [issue13591] import_module potentially imports a module twice
Message-ID: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>


New submission from Ryan Twitchell <metatheorem at gmail.com>:

Use of importlib's import_module function with modules belonging to a library
can cause some modules to be imported twice, if such a module is referenced
from sibling modules, and from __init__ in the package.  I suspect this is a
bug, or at best a nuance of packages that is quite subtle.

Easier to show with an example.  Below, the module my_lib.bar will be imported
twice.  Given the following file structure:

./scratch.py
./my_lib/__init__.py
./my_lib/foo.py
./my_lib/bar.py

And the following file contents:

./scratch.py:

	import importlib
	importlib.import_module('my_lib.bar')
	importlib.import_module('my_lib.foo')


./my_lib/__init__.py:

	import my_lib.bar

	# Or alternately
	#from . import bar


./my_lib/foo.py:

	from . import bar

	print('In foo, id(bar.baz): %s' % id(bar.baz))


./my_lib/bar.py:

	def baz():
		pass

	print('In bar, id(bar.baz): %s' % id(baz))


Running scratch.py results in my_lib.bar being imported twice:
$ echo $PYTHONPATH
.
$ python --version
Python 3.2.2
$ python ./scratch.py
In bar, id(bar.baz): 21328632
In bar, id(bar.baz): 21352240
In foo, id(bar.baz): 21352240


Replacing the calls to import_module with use of the import statement, or
__import__, or simply rearranging the order of the two calls all result in the
module my_lib.bar to be imported only once.  As does eliminating the import
statement in my_lib.__init__.

This may be a misunderstanding on my part regarding the intended use of
packages, but this behavior was quite unexpected, and rather difficult to track
down in real code.

----------
components: Library (Lib)
messages: 149358
nosy: Ryan.Twitchell
priority: normal
severity: normal
status: open
title: import_module potentially imports a module twice
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:44:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 21:44:50 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323726290.55.0.3344825585.issue13591@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:45:13 2011
From: report at bugs.python.org (sbt)
Date: Mon, 12 Dec 2011 21:45:13 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323726313.79.0.507527587076.issue13505@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I now realise latin_1_encode won't work because it returns a pair (bytes_obj, length).

I have done a patch using _codecs.encode instead -- the pickles turn out to be exactly the same size anyway.

>>> pickletools.dis(pickle.dumps(b"abc", 2))
    0: \x80 PROTO      2
    2: c    GLOBAL     '_codecs encode'
   18: q    BINPUT     0
   20: X    BINUNICODE 'abc'
   28: q    BINPUT     1
   30: X    BINUNICODE 'latin1'
   41: q    BINPUT     2
   43: \x86 TUPLE2
   44: q    BINPUT     3
   46: R    REDUCE
   47: q    BINPUT     4
   49: .    STOP

----------
Added file: http://bugs.python.org/file23938/issue13505-codecs-encode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:31:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2011 22:31:30 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1323729090.24.0.307895019915.issue7163@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Re-verified on 3.2.2, win 7.
#13532 shows a worse problem with sys.stdout.write on the above.

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:34:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2011 22:34:18 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1323729258.19.0.286424646454.issue13532@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

We should like the IDLE shell to give the same results as the standard shell. See #7163

On 3.2.2 on Win7, the problem is worse: sys.stdout.write(100) crashes IDLE -- as in it just fades away after a short (1/2 sec?) delay.
 sys.stdout.write(sys)
gives me the error reported.

The difference comes from this in the Command Window:
>>> sys.stdout
<_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp437'>

versus this in IDLE:
>>> import sys
>>> sys.stdout
<idlelib.rpc.RPCProxy object at 0x00000000031D0208>

----------
nosy: +terry.reedy
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:41:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2011 22:41:13 +0000
Subject: [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323729673.92.0.825161553844.issue13538@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think Eric's suggestion is the proper approach.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13538>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:42:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 22:42:07 +0000
Subject: [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323729727.69.0.774814514737.issue13538@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/issue13538>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:58:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2011 22:58:24 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323730704.25.0.174835535382.issue13540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The doc specified the Action API as the interface inherited from argparse.Action plus the addition of a custom __call__ method with 4 params (5 with self) as described. That seems mostly adequate to me, unless there is something missing in the parameter descriptions.

I agree that it should be stated if one should pass the class rather than an instance thereof. (But classes are objects, so that is not a 'contradiction'.) If the example is in error, it should be fixed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Tue Dec 13 00:10:30 2011
From: report at bugs.python.org (Raul Morales)
Date: Mon, 12 Dec 2011 23:10:30 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323731430.86.0.923215610988.issue13516@psf.upfronthosting.co.za>


Raul Morales <raul.mh at gmail.com> added the comment:

Interesting, then I will wait your post. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Tue Dec 13 00:20:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2011 23:20:06 +0000
Subject: [issue13548] Invalid 'line' tracer event on pass within else clause
In-Reply-To: <1323275290.33.0.837630531134.issue13548@psf.upfronthosting.co.za>
Message-ID: <1323732006.24.0.867011016938.issue13548@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(Snippet examples can be made 2/3 agnostic with 
from __future__ import print_function)

3.2.2 on win7, IDLE, gives me
F:\Python\mypy\tem.py 7 call
F:\Python\mypy\tem.py 8 line
F:\Python\mypy\tem.py 10 line
F:\Python\mypy\tem.py 11 line
F:\Python\mypy\tem.py 13 line
F:\Python\mypy\tem.py 13 return
...
Commenting out else:pass or changing pass to r=2 changes the output to
F:\Python\mypy\tem.py 7 call
F:\Python\mypy\tem.py 8 line
F:\Python\mypy\tem.py 10 line
F:\Python\mypy\tem.py 11 line
F:\Python\mypy\tem.py 11 return

Looking as the dis outputs of the three versions, I find the difference of behavior somewhat puzzling.

----------
nosy: +terry.reedy
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13548>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:23:26 2011
From: report at bugs.python.org (Julian Berman)
Date: Tue, 13 Dec 2011 00:23:26 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323735806.33.0.255782076719.issue13585@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

For reference, the implementation that I posted in the other thread is:

    @contextlib.contextmanager
    def maybe(got, contextfactory, *args, checkif=bool, **kwargs):
        if checkif(got):
            yield got
        else:
            with contextfactory(*args, **kwargs) as got:
                yield got

which produces code like:

def fn(input_file=None):
    with maybe(input_file, open, "/default/input/file/location/"):
        for line in input_file:
            print line

For the example given here in the OP, since rmtree isn't a contextmanager it'd require wrapping it in one first.

I could probably understand if there was desire for these to be a recipe instead. The advantage (if any) of the above over this class is that it keeps context managers sorta looking like context managers. Here if you wanted to write my example it'd require writing code like

with ContextManager() as mgr:
    foo = ctxtmgr()
    mgr.register(foo.__close__)

which doesn't look too great :/

The class though does have wider scope though, since it doesn't necessarily only need a context manager, it can do cleanup for anything, which I guess is nice.

----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:37:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Dec 2011 00:37:31 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323736651.54.0.672036010374.issue13521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I would like to continue working on this test, but incoming week is
> pretty intensive for me. Is it ok if I returned to working on this
> during the weekend?

Of course. There's no rush.
(I'm really not sure it should go in 2.7 and 3.2; this looks more like a feature than a bug, since atomicity has never been documented)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:51:43 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Dec 2011 00:51:43 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1323627474.18.0.266166234145.issue13505@psf.upfronthosting.co.za>
Message-ID: <CAK1QooonSYERq_wZrw7q5vYyiw6=VAE-hnRYx8Xum0HRYCHJJw@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Sun, Dec 11, 2011 at 12:17 PM, sbt <report at bugs.python.org> wrote:

>> I don't really know that much about pickle, but Antoine mentioned that 'bytearray'
>> works fine going from 3.2 to 2.7. ?Given that, can't we just compose 'bytes' with
>> 'bytearray'?
>
> Yes, although it would only work for 2.6 and 2.7.

Which is fine.  'bytes' and byte literals were not introduced until
2.6 [1,2].  So *any* solution we come
up with is for >= 2.6.

> They also produce more compact pickles, particularly codecs.latin_1_encode().

Now that is a better argument.

[1] http://www.python.org/dev/peps/pep-0358/
[2] http://www.python.org/dev/peps/pep-3112/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:57:24 2011
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 13 Dec 2011 00:57:24 +0000
Subject: [issue7163] IDLE suppresses sys.stdout.write() return value
In-Reply-To: <1255819083.11.0.568760312973.issue7163@psf.upfronthosting.co.za>
Message-ID: <1323737844.08.0.712986717367.issue7163@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

If you add "return len(s)" to PseudoFile::write in PyShell.py, then it will work. However, this approach may not be "the right thing to do."

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7163>
_______________________________________

From report at bugs.python.org  Tue Dec 13 02:27:10 2011
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 13 Dec 2011 01:27:10 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1323739630.04.0.172231209259.issue13532@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The crash can be prevented by using #13582.

The RPCProxy object would need to be subclassed so that it raises TypeError for the "write" method when it is not given a string.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Tue Dec 13 02:53:46 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Dec 2011 01:53:46 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323741226.64.0.923609523109.issue13591@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Tue Dec 13 02:54:48 2011
From: report at bugs.python.org (sbt)
Date: Tue, 13 Dec 2011 01:54:48 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323741288.59.0.177639965259.issue13505@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Which is fine.  'bytes' and byte literals were not introduced until
> 2.6 [1,2].  So *any* solution we come
> up with is for >= 2.6.

In 2.6 and 2.7, bytes is just an alias for str.  In all 2.x versions with codecs.encode, the result will be str.  (Although I haven't actually tested earlier than 2.6.)

Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> pickle.loads('\x80\x02c_codecs\nencode\nq\x00X\x03\x00\x00\x00abcq\x01X\x06\x00\x00\x00latin1q\x02\x86q\x03Rq\x04.')
'abc'
>>> type(_)
<type 'str'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:11:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Dec 2011 02:11:44 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323742304.86.0.52511491969.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given the existence of tempfile.TemporaryDirectory in recent Python versions, I suggest finding a new cleanup function example that doesn't duplicate native stdlib functionality :)

I do see value in the feature itself though - I believe the precedent of both the atexit module [1] and unittest.TestCase.addCleanup() [2] shows how it can be useful to have a standard way to accumulate a sequence of "undo" operations for invocation at a later time.

In particular, it's a much better fit than nested with statements are for *optional* resources - you can make the with statement unconditional (setting up the cleanup manager), optionally add the cleanup methods, and avoid needing to have two copies of your actual invocation code (one inside a with statement and one without) or having a delayed check in a finally block.

It codifies the fairly common "if this resource was acquired, make sure it is released" idiom in a way that with statements and try/finally just don't handle neatly. By using an incremental API, it also avoids the traps associated with the ultimately misguided "contextlib.nested()" design.

However, I suggest using an API that strictly follows the "register only" model employed by both of the existing mechanisms. In addition, any solution provided as part of contextlib should interoperate nicely with existing context managers - it should be trivial to rewrite a nested with statement to be based on CleanupManager instead.

Accordingly, I would give the manager the following public methods:

  register_exit() (only accepts callbacks with the __exit__ signature)
  register() (equivalent to TestCase.addCleanup)
  enter_context() (accepts actual context managers)
  close() (equivalent to TestCase.doCleanups)

register_exit() would be the base callback registration method. It would accept only callbacks with the same signature as __exit__ methods.

    def register_exit(self, exit):
        self._callbacks.append(exit)
        return exit # Allow use as a decorator

register() would wrap arbitrary callbacks to support the __exit__ method signature:

    def register(self, _cb, *args, **kwds):
        def _wrapper(exc_type, exc, tb):
            return _cb(*args, **kwds)
        return self.register_exit(_wrapper)

enter_context() would work as follows:

    def enter_context(self, cm):
        result = cm.__enter__()
        self.register_exit(cm.__exit__)
        return result

close() would look like:

    def close(self):
        self.__exit__(None, None, None)

And finally, __exit__() itself would be:

    def __exit__(self, *exc_details):
        def _invoke_next_callback(exc_details):
            # Callbacks are removed from the list in FIFO order
            # but are actually *invoked* in LIFO order
            cb = self._callbacks.pop(0)
            if not self._callbacks:
                # Innermost callback is invoked directly
                return cb(exc_type, exc, tb)
            # Use try-finally to ensure this callback still gets
            # invoked even if an inner one fails
            try:
                inner_result = _invoke_next_callback()
            except:
                cb_result = cb(*sys.exc_info())
                # Check if this cb suppressed the inner exception
                if not cb_result:
                    raise
            else:
                # Check if inner cb suppressed the original exception
                if inner_result:
                    exc_details = (None, None, None)
                cb_result = cb(*exc_details)
            return cb_result
        _invoke_next_callback(exc_details)

An example using a cleanup manager to handle multiple files, one of which is optional:

    with contextlib.CleanupManager() as cm:
        source = cm.enter_context(open(source_fname))
        if dest_fname is not None:
            dest = cm.enter_context(open(dest_fname))
            _write_to_dest = dest.write
        else:
            def _write_to_dest(line): pass
        for line in source:
            _write_to_dest(line)
            yield line


[1] http://docs.python.org/library/atexit
[2] http://docs.python.org/library/unittest#unittest.TestCase.addCleanup

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:12:20 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Dec 2011 02:12:20 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1323742340.5.0.934428121885.issue1785@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:22:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Dec 2011 02:22:00 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323742920.47.0.944026371829.issue13585@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think you guys need to post your code somewhere (perhaps on PyPi or the ASPN Cookbook).  It needs to mature beyond the stage of "I just whipped-up this code and think it would be great if everybody used it".

I've seen nothing like this being used in production code (code published on the net or at one of my clients).  Context managers have been around for a while, so if this were a real need, we would expect to see people already using something like this (for example, namedtuples got introduced to the standard library upon seeing many, many reinventions of the concept and we were able to consolidate the best features from each).

Design of the a feature in the standard library should be driven by examples of real world code that would be improved with the new feature.  The design should also be informed by the experience of teaching people how to use it and seeing what they do (lots of technically correct ideas get shot down because it turns out that incorrect usage is common (a bug factory like the % formatting operator) or that people have a hard time learning and remembering the feature.

The core problem is that it is easier to add things to the standard library than to take them out if they prove to be a bad idea.  Accordingly, we need to be *really sure* that this is a good idea, that it will *improve* real world code, that people learn, understand, and remember it easily, and that is doesn't impair readability.

The example code from Nikolaus has a bug in it -- that is worrisome and may suggest that we are better-off without this being in the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:22:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Dec 2011 02:22:23 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323742943.39.0.762290268047.issue13585@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
resolution:  -> later

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:25:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Dec 2011 02:25:16 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323743116.31.0.598877324905.issue13591@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

At first glance, I thought this might be just the circular import problem (#992389) appearing in a different guise. However, if that was the case, switching to an import statement or __import__ shouldn't have made any difference.

What do you see if you put an "import my_lib.bar" *between* the two importlib calls?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:26:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Dec 2011 02:26:58 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1323743218.38.0.210705788092.issue13521@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks, I'll look at it over the next few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:02:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Dec 2011 03:02:37 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323745357.76.0.797252464012.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

TestCase.setUp() and TestCase.tearDown() were amongst the precursors to__enter__() and __exit__(). addCleanUp() fills exactly the same role here - and I've seen *plenty* of positive feedback directed towards Michael for that addition to the unittest API.

For individual one-off cases, a flag variable and an if statement inside a finally block is an adequate, but not ideal, solution, because it suffers from all the readability and auditability problems of *any* try/finally based solution. It's particularly annoying when an object *does* support the context management protocol, but I can't use a with statement simply because I don't *always* need (and/or own) that resource (this kind of thing happens in a few places in runpy, since the behaviour changes depending on whether or not runpy created temporary objects for itself or was given objects as arguments)

Custom context managers are typically a bad idea in these circumstances, because they make readability *worse* (relying on people to understand what the context manager does). A standard library based solution, on the other hand, offers the best of both worlds:
- code becomes easier to write correctly and to audit for correctness (for all the reasons with statements were added in the first place)
- the idiom will eventually become familiar to all Python users

If other "cleanup function" registration APIs didn't already exist, I'd agree with you that this needed further exposure. However, I simply don't agree that's the case - atexit and addCleanup provide your field testing, the rest of the design is just a matter of integrating those concepts with the context management protocol.

Indeed, one of the objections I received after we deprecated contextlib.nested() was that you couldn't easily pass a programmatically generated list of resources to nested with statements. Given contextlib.CleanupManager it becomes trivial:

    with contextlib.CleanupManager as cm:
        files = [cm.enter_context(open(fname)) for fname in names]
        # All files will be closed when we leave the context

I can take this up on python-dev if you want, but I hope to persuade you that the desire *is* there, it's just that the workarounds for the lack of this functionality involve avoiding the context management protocol entirely:

    try:
        files = [open(fname) for fname in names]
        # Are all files closed when we're done?
        # I dunno, scroll down past the algorithm code to check!


        # Avoiding this would be good for all the reasons the
        # with statement was added in the first place

    finally:
        for f in files:
            f.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:43:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Dec 2011 03:43:34 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323747814.12.0.555511227565.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given the history of API design errors in contextlib (cf. contextlib.nested in general, making contextlib._GeneratorContextManager a subclass of contextlib.ContextDecorator), I've realised Raymond is right in wanting to see this idea more thoroughly vetted before it gets added to the standard library.

Accordingly, I plan to create a 'unittest2' style backport library for contextlib (imaginatively named 'contextlib2') and prototype the concept further there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 05:24:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Dec 2011 04:24:38 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323750278.35.0.832443786813.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In the meantime, I put my version up as a cookbook recipe: http://code.activestate.com/recipes/577981-cleanupmanager-for-with-statements/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:14:21 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 05:14:21 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323753261.67.0.751203093723.issue13589@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23935/aifc_numbers_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:15:07 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 05:15:07 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323753307.3.0.405908059236.issue13589@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Added file: http://bugs.python.org/file23939/aifc_numbers_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:19:46 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 05:19:46 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323753586.63.0.488804198254.issue13589@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23939/aifc_numbers_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:20:02 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 05:20:02 +0000
Subject: [issue13589] Aifc float serialization fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323753602.69.0.93023841215.issue13589@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Added file: http://bugs.python.org/file23940/aifc_numbers_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:21:32 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 05:21:32 +0000
Subject: [issue13589] Aifc low level serialization primitives fix
In-Reply-To: <1323714686.93.0.781541085274.issue13589@psf.upfronthosting.co.za>
Message-ID: <1323753692.17.0.075798264991.issue13589@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


----------
title: Aifc float serialization fix -> Aifc low level serialization primitives fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13589>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:22:07 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 05:22:07 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323753727.13.0.641535529478.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


----------
title: Patch to increase aifc lib test coverage with couple of minor fixes -> Patch to increase aifc lib test coverage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:57:56 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Dec 2011 05:57:56 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323755876.56.0.465644984145.issue13577@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

For the most part this looks OK, but I am not sure about this hunk:

diff --git a/Objects/typeobject.c b/Objects/typeobject.c
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -3724,7 +3724,7 @@ add_methods(PyTypeObject *type, PyMethod
             descr = PyDescr_NewClassMethod(type, meth);
         }
         else if (meth->ml_flags & METH_STATIC) {
-            PyObject *cfunc = PyCFunction_New(meth, NULL);
+            PyObject *cfunc = PyCFunction_New(meth, (PyObject*)type);
             if (cfunc == NULL)
                 return -1;
             descr = PyStaticMethod_New(cfunc);

That may be a breaking change as existing code may rely on the 'None' behavior.  In 
fact, this causes a unit test to fail with the patch applied:

[meadori at motherbrain cpython]$ ./python -m test test_descr
[1/1] test_descr
test test_descr failed -- Traceback (most recent call last):
  File "/home/meadori/src/python/cpython/Lib/test/test_descr.py", line 1485, in test_staticmethods_in_c
    self.assertEqual(x, None)
AssertionError: <class 'xxsubtype.spamlist'> != None

sbt, have you been running the test suite before submitting patches?  If not, then
please do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Tue Dec 13 09:37:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Dec 2011 08:37:59 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323765479.84.0.869577099426.issue13585@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks Nick.  You're awesome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:30:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 13 Dec 2011 10:30:25 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323772225.78.0.540056482027.issue13516@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

See this for the proposed resolution:

http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:42:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=)
Date: Tue, 13 Dec 2011 10:42:24 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
Message-ID: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>


New submission from Martin H?cker <spamfaenger at gmx.de>:

When calling repr() on a compiled regex pattern like this:

> import re
> repr(re.compile('foo'))

you don't get the pattern of the regex out of the compiled form. Also all my research has shown no getter to allow this.

I noticed this in my application because I was unable to show good error messages for things involving regexes, which is a shame.

So please add the actual regex to the repr() form of the compiled regex, or alternatively provide a getter / property to get at it.

----------
messages: 149382
nosy: dwt
priority: normal
severity: normal
status: open
title: repr(regex) doesn't include actual regex
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:04:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Dec 2011 11:04:28 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323774268.06.0.128513741709.issue13592@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure having the pattern in the repr will make it more readable, since the regex might even be very long.  You can use the .pattern attribute if you want to see the pattern.

----------
nosy: +ezio.melotti
status: open -> pending
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 13:48:36 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Dec 2011 12:48:36 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323780516.81.0.0596381581851.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And the backport: http://contextlib2.readthedocs.org/

I haven't tested on anything other than 2.7 as yet - I have an account request in train with the Shining Panda folks, so I'll set up multi-version CI for this project (along with a couple of others) once that goes through.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:14:13 2011
From: report at bugs.python.org (sbt)
Date: Tue, 13 Dec 2011 13:14:13 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1323782053.28.0.418569011221.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> sbt, have you been running the test suite before submitting patches?  
> If not, then please do.

I ran it after I submitted.  Sorry.

Here is another patch.  It also makes sure that __self__ is reported as None when METH_STATIC.

----------
Added file: http://bugs.python.org/file23941/method_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:38:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2011 13:38:33 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <E1RaSYv-0000uc-9T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 132158b287d7 by Ezio Melotti in branch '2.7':
#13549: improve tutorial section about listcomps.
http://hg.python.org/cpython/rev/132158b287d7

New changeset ad5c70296c7b by Ezio Melotti in branch '3.2':
#13549: improve tutorial section about listcomps.
http://hg.python.org/cpython/rev/ad5c70296c7b

New changeset 37094a1454ab by Ezio Melotti in branch 'default':
#13549: merge with 3.2.
http://hg.python.org/cpython/rev/37094a1454ab

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13549>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:43:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Dec 2011 13:43:22 +0000
Subject: [issue13549] Incorrect nested list comprehension documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323783802.73.0.939943191077.issue13549@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed.
On a side note, using:
>>> [x, x**2 for x in range(6)]
  File "<stdin>", line 1
    [x, x**2 for x in range(6)]
               ^
SyntaxError: invalid syntax

In the 3.x docs seems to break the hightlight.
With 'File "<stdin>", line 1, in ?' the highlight works fine, so that's what I used.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13549>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:54:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2011 13:54:07 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <E1RaSo1-0002VL-2z@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d60856651139 by Ezio Melotti in branch '2.7':
#6570: clarify tutorial section about keyword arguments.
http://hg.python.org/cpython/rev/d60856651139

New changeset 44ca4264dc88 by Ezio Melotti in branch '3.2':
#6570: clarify tutorial section about keyword arguments.
http://hg.python.org/cpython/rev/44ca4264dc88

New changeset 207408428242 by Ezio Melotti in branch 'default':
#6570: merge with 3.2.
http://hg.python.org/cpython/rev/207408428242

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:54:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Dec 2011 13:54:39 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1323784479.17.0.498041778583.issue6570@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:08:16 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Dec 2011 14:08:16 +0000
Subject: [issue13593] importlib needs to be updated for __qualname__
Message-ID: <1323785296.62.0.631553026432.issue13593@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

I was recently reading the 'importlib' code and noticed that the utility 
decorators have not been updated for '__qualname__':

>>> def f(): pass
... 
>>> importlib.util.set_loader(f)
<function set_loader.<locals>.wrapper at 0x7f4b323f1f60>
>>> importlib.util.set_loader(f).__name__
'f'
>>> importlib.util.set_loader(f).__qualname__
'set_loader.<locals>.wrapper'

The attached patch fixes this.  OK to commit?

----------
components: Library (Lib)
files: importlib-qualname.patch
keywords: easy, patch
messages: 149389
nosy: brett.cannon, meador.inge
priority: normal
severity: normal
stage: patch review
status: open
title: importlib needs to be updated for __qualname__
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23942/importlib-qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13593>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:11:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Dec 2011 14:11:11 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323785472.0.0.137796620778.issue13394@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for splitting the patch.
I tried to apply the patch to 3.2 and I have 3 comments:
1) you changed a commented-out assertEqual with an assertNotEqual, because "ULAW is lossy compression, so frames *may* not match".  Does it mean that sometimes they might match and make the test fail or that they are always different for this specific test?  In the first case the test should make sure to have a consistent result and avoid sporadic failures.  In the second case the check could be removed altogether, because producing different results is not a feature of the format, but just a detail that depends on the input.
2) when I run the tests I now get 3 warnings:
Warning: bad COMM chunk size
Warning: bad COMM chunk size
Warning: MARK chunk contains only 0 markers instead of 1
These should be silenced, or better, tested with self.assertWarns (assertWarns should silence them too).
3) there's some trailing space just before test_write_header_comptype_raises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:14:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Dec 2011 14:14:16 +0000
Subject: [issue13593] importlib needs to be updated for __qualname__
In-Reply-To: <1323785296.62.0.631553026432.issue13593@psf.upfronthosting.co.za>
Message-ID: <1323785656.75.0.454848550119.issue13593@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +pitrou
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13593>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:08:31 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2011 15:08:31 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323788911.33.0.311115938702.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

You're right. The documentation isn't incorrect, if you're splitting hairs. But it's not super friendly either.

Questions that the documentation should answer:

1) Does the action always need to be a subclass of an Action, or is that recommended? If it's recommended, replace "easiest" with "recommended".
2) If it does not always need to be a subclass of Action, what is the interface expected of a class for a custom action?
3) If one does use a subclass of Action, are there any hooks that are called at any point? How does one customize an action other than to override __call__? What attributes are available on the object (the example shows .dest only)?
4) What is the action required to do in __call__, if anything? Is there any way to invoke the default behavior (if for example a special case wasn't detected)?

All of these questions can be answered by going to the source, but I've twice now gone to the documentation to reference how to provide a custom action and found the documentation insufficient.

Now that I review the source again, I think I know the answers to those questions.

1) It does not always need to be a subclass of Action, but it is recommended.
2) The action API expects a callable with the following signature: Action(option_strings, dest, nargs=None, const=None, default=None, type=None, choices=None, required=False, help=None, metavar=None) which when called returns another callable accepting the four parameters.
3) Argparse does nothing with the custom action except to call it first with the init parameters, then calls the result with four parameters. If subclassing Action, the default __init__ simply stores each of those parameters as attributes on the object. Most subclasses of Action will override the __init__ to validate the options and raise an exception (typically a ValueError) when the parameters aren't valid.
4) The action is not required to do anything. Most actions will perform some logic and then invoke setattr(namespace, self.dest, result) where result is the result of some logic.

I can see why no one wanted to write this documentation. It's difficult to describe simply.

Here's what I propose:

First, remove the phrase "Action API" which suggests that there's an API outside of subclassing the Action that's recommended.

Second, change "easiest" to "recommended" to using the class.

Third, explain what attributes are available on an object initialized from a subclass of Action. Provide a link to code or other section that describes advanced usage (overriding __init__).

Fourth, explain what is expected when calling an Action instance (i.e. setattr).

Fifth, consider extending the Action class so that __call__ calls an actual named method so that those writing custom actions aren't writing classes with only a __call__ method. Perhaps "invoke". I feel less strongly about this point, but it seems strange that the recommended usage is to write a class with only a __call__ method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:17:20 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Dec 2011 15:17:20 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323789440.14.0.587507072437.issue13591@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I can reproduce this on tip.  What happens is that 
'importlib.import_module("my_lib.bar")' is effectively computed as:

   import my_lib
   import bar

by '_bootstrap._gcd_import'.  When '_gcd_import' goes to do the import
of 'bar' it does *not* check to see if 'bar' has already been imported
by the parent import.

Here is a patch *without* tests that fixes this.  I will add the tests
next.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file23943/issue13591.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:41:48 2011
From: report at bugs.python.org (Sven Marnach)
Date: Tue, 13 Dec 2011 15:41:48 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1323790908.16.0.612869623142.issue13585@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

I think that the fact that Nick got the code to close multiple files wrong underlines that it is difficult to get right currently.  Nick's code

    try:
        files = [open(fname) for fname in names]
        # ...
    finally:
        for f in files:
            f.close()

only closes the files if all of them were opened successfully.  Moreover, `file.close()` can fail for various reasons, which would result in all remaining files being left open.  When we fix both problems, the code becomes

    try:
        files = []
        for fname in names:
            files.append(open(fname))
        # ...
    finally:
        for f in files:
            try:
                f.close()
            except IOError:
                pass

I think everyone will agree that the version using 'CleanupManager' is nicer.  To be fair, we should note that the need to open many files simultaneously is not very common -- usually, we can make to with opening the files one by one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:45:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Dec 2011 15:45:47 +0000
Subject: [issue13593] importlib needs to be updated for __qualname__
In-Reply-To: <1323785296.62.0.631553026432.issue13593@psf.upfronthosting.co.za>
Message-ID: <1323791147.84.0.149376046105.issue13593@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13593>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:46:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Dec 2011 15:46:37 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323791197.55.0.641851690157.issue13591@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:48:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Dec 2011 15:48:09 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323791289.1.0.412836984193.issue13592@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm not sure having the pattern in the repr will make it more readable, 
> since the regex might even be very long. 

Hmm, I think it's a reasonable feature request myself.
Oops, I meant "enhancement", not "feature request" :)

----------
nosy: +pitrou
stage:  -> needs patch
status: pending -> open
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:50:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Dec 2011 15:50:06 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323791406.15.0.318754710415.issue13592@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Regular Expressions
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 17:58:03 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 13 Dec 2011 16:58:03 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323795483.54.0.289323841245.issue13592@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

In reply to Ezio, the repr of a large string, list, tuple or dict is also long.

The repr of a compiled regex should probably also show the flags, but should it just be the numeric value?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 18:20:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Dec 2011 17:20:20 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323796820.86.0.665757193111.issue13592@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

ISTM that .pattern is the one way to do it.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 19:08:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Dec 2011 18:08:14 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323796820.86.0.665757193111.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323799677.3419.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> ISTM that .pattern is the one way to do it.

To me this is like saying the repr() of functions should not show their
name since .__name__ is the one way to do it. repr() is useful for
debugging and logging, why not make it more useful?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 19:23:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2011 18:23:21 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <E1RaX0Z-0006qt-SN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 14695b4825dc by Alexandre Vassalotti in branch '3.2':
Issue #13505: Make pickling of bytes object compatible with Python 2.
http://hg.python.org/cpython/rev/14695b4825dc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Tue Dec 13 19:29:51 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 13 Dec 2011 18:29:51 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1323800991.23.0.0644793071987.issue13505@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Fixed. Thanks for the patch!

----------
assignee:  -> alexandre.vassalotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Tue Dec 13 19:48:41 2011
From: report at bugs.python.org (Craig Foster)
Date: Tue, 13 Dec 2011 18:48:41 +0000
Subject: [issue4028] Problem compiling the multiprocessing module on sunos5
In-Reply-To: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>
Message-ID: <1323802121.09.0.87914920736.issue4028@psf.upfronthosting.co.za>


Craig Foster <foster.craig at gmail.com> added the comment:

I can confirm that the compile completes with a multiprocessing module where it hasn't before--at least in SunOS 5.9.

----------
nosy: +fosterremy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4028>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:08:06 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 19:08:06 +0000
Subject: [issue13594] Aifc markers write fix
Message-ID: <1323803286.63.0.487230833708.issue13594@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

1. Markers serialization test coverage improved.
2. Marker name changed from string to bytes, because _write_string function uses bytes.
3. Check for closed file handle moved to 'close' method, because otherwise  I caught 'attempt to write to closed file' error.

----------
components: Library (Lib)
files: aifc_markers.patch
keywords: patch
messages: 149402
nosy: Oleg.Plakhotnyuk, ezio.melotti, r.david.murray
priority: normal
severity: normal
status: open
title: Aifc markers write fix
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23944/aifc_markers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13594>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:23:53 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Tue, 13 Dec 2011 19:23:53 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1323804233.3.0.487615223777.issue13241@psf.upfronthosting.co.za>


Changes by Nam Nguyen <bitsink at gmail.com>:


----------
nosy: +Nam.Nguyen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:25:40 2011
From: report at bugs.python.org (Pyry Pakkanen)
Date: Tue, 13 Dec 2011 19:25:40 +0000
Subject: [issue13595] Weird behavior with generators with self-referencing
	output.
Message-ID: <1323804340.16.0.941499228251.issue13595@psf.upfronthosting.co.za>


New submission from Pyry Pakkanen <frostburn at suomi24.fi>:

The following self-referencing generator has incorrect output:

def ab_combinations():
    #'', 'a', 'b', 'aa', 'ab', 'ba', 'bb', 'aaa', ...
    def _deferred_output():
        yield ""
        tees = tee(output)

        #This definition works fine: '', 'a', 'b', 'aa', 'ab', 'ba', ...
        l = [(item+"a" for item in tees[0]), (item+"b" for item in tees[1])]

        #This definition results in: '', 'b', 'b', 'bb', 'bb', 'bb', ...
        #l = [(item+label for item in t) for t, label in zip(tees,"ab")]
        
        while True:
            for g in l:
                yield next(g)

    result, output = tee(_deferred_output())
    return result

----------
messages: 149403
nosy: PyryP
priority: normal
severity: normal
status: open
title: Weird behavior with generators with self-referencing output.
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13595>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:29:41 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 19:29:41 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323804581.59.0.663982622696.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23934/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:38:20 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 19:38:20 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323805100.14.0.576852994548.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

The split is in progress. There will be at least two more patches.
Regarding your comments:
1) Sorry for my english :-) It is fully determined by the input. With this particular test input the assertNotEqual will always pass. So I've removed it.
2) These were simple prints, not warnings. I've replaced them with warnings and tested with assertWarns. It resulted in some changes to aifc library itself, but they are trivial and cannot affect behavior.
3) Fixed.
Thanks.

----------
Added file: http://bugs.python.org/file23945/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:38:49 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 19:38:49 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1323805129.56.0.640922521124.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Third patch goes to issue 13594

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:41:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Dec 2011 19:41:04 +0000
Subject: [issue13596] Only recompile Lib/_sysconfigdata.py when needed
Message-ID: <1323805264.0.0.131711939459.issue13596@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached patch fixes Makefile.pre.in to only recompile Lib/_sysconfigdata.py when needed.

----------
files: sysconfigdata.patch
keywords: patch
messages: 149406
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Only recompile Lib/_sysconfigdata.py when needed
versions: Python 3.3
Added file: http://bugs.python.org/file23946/sysconfigdata.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13596>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:41:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Dec 2011 19:41:16 +0000
Subject: [issue13596] Only recompile Lib/_sysconfigdata.py when needed
In-Reply-To: <1323805264.0.0.131711939459.issue13596@psf.upfronthosting.co.za>
Message-ID: <1323805276.27.0.0616290716174.issue13596@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13596>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:59:17 2011
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 13 Dec 2011 19:59:17 +0000
Subject: [issue13588] Change name of internal closure functions in importlib
In-Reply-To: <1323703954.36.0.434643027987.issue13588@psf.upfronthosting.co.za>
Message-ID: <1323806357.37.0.972889469777.issue13588@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23947/issue13588_v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13588>
_______________________________________

From report at bugs.python.org  Tue Dec 13 21:25:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Dec 2011 20:25:16 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323807916.79.0.670987151471.issue13592@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If you change the repr, it should at least eval-able, so be sure to capture the flags and whatnot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 21:28:02 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 13 Dec 2011 20:28:02 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
Message-ID: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

The default buffering of standard output and standard error has changed in Python 3.x with respect to Python 2.x, and I have been unable to find decent documentation of either the current behaviour, or the change.

(See also http://groups.google.com/group/comp.lang.python/browse_thread/thread/43476d4682059f53#)

Part 1 - the change
-------------------
>From rude experiment it seems that:
a) In Python 2.x, standard error was always unbuffered while standard
output was buffered by default.  In python3, both are buffered. In
both cases, "buffered" means line-buffered when writing to the console
and not line-buffered when redirected to files.
b) In Python 2.x, the "-u" flag meant everything was totally
unbuffered. In Python 3.x, it means that both stdout and stderr are
line-buffered also when redirected to files. 

One important consequence of (a) is, if stderr is redirected
to a file, your program throws an exception and is then subsequently terminated with SIGTERM, you will not see the exception. This will not be expected for someone used to the Python 2.x behaviour.

"What's New in Python 3.0" has this to say about the change (in the section marked "Changes Already Present In Python 2.6"

"# PEP 3116: New I/O Library. The io module is now the standard way of doing file I/O, and the initial values of sys.stdin, sys.stdout and sys.stderr are now instances of io.TextIOBase. [...]"

This seems wrong in that, while the io module was present in Python 2.6, the change noted to sys.stdin, sys.stdout and sys.stderr was not.
Also, it is far from obvious from this note that any externally observable behaviour has changed.

I suggest changing this to 
a) note the buffering changes listed above
b) note the change in meaning of the -u flag
c) Move this to its own section which is not part of changes to Python 2.6 (it's OK to keep the note about the new io module there)

Part 2 - the behaviour
----------------------
a) The documentation for "sys.stdout" and "sys.stderr" does not say anything about their default buffering properties in various situations, nor how this can modified by setting the "-u" flag.

b) The documentation for "-u" is misleading:
"Force the binary layer of the stdin, stdout and stderr streams (which
is available as their buffer attribute) to be unbuffered. The text I/O
layer will still be line-buffered." 

The "still" in the last sentence is only relevant when stdout/stderr are writing to the console. If they are redirected to file, "-u" *modifies the behaviour such that* the text I/O layer will be line-buffered.

----------
assignee: docs at python
components: Documentation
messages: 149408
nosy: docs at python, gjb1002
priority: normal
severity: normal
status: open
title: Improve documentation of stdout/stderr buffering in Python 3.x
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Tue Dec 13 22:24:20 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 13 Dec 2011 21:24:20 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323811460.65.0.322133658866.issue13592@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Actually, one possibility that occurs to me is to provide the flags within the pattern. The .pattern attribute gives the original pattern, but repr could give the flags in-line at the start of the pattern:

>>> # Assuming Python 3.
>>> r = re.compile("a", re.I)
>>> r.flags
34
>>> r.pattern
'a'
>>> repr(r)
"<_sre.SRE_Pattern '(?i)a'>"

I'm not sure how to make it eval-able, unless you mean something more like:

>>> repr(r)
"re.Regex('(?i)a')"

where re.Regex == re.compile, which would be more meaningful than:

>>> repr(r)
"re.compile('(?i)a')"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Tue Dec 13 23:01:01 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 13 Dec 2011 22:01:01 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1323813661.17.0.843566809445.issue13241@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The bug in the 'gcc' command is still present when using Xcode 4.2.1 (that is, the attached unicode.c miscompiles with "gcc -O3").

Clang (again from Xcode 4.2.1) compiles the file correctly, but fails to do a proper build the last few lines of the build log:

clang -bundle -undefined dynamic_lookup build/temp.macosx-10.4-x86_64-3.3/Users/ronald/Projects/python/rw/cpython/Modules/_cursesmodule.o -L/usr/local/lib -lncurses -o build/lib.macosx-10.4-x86_64-3.3/_curses.so
/bin/sh: line 1: 84213 Segmentation fault: 11  CC='clang' LDSHARED='clang -bundle -undefined dynamic_lookup  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py build
make: *** [sharedmods] Error 139

The last bit of a gdb stack trace:

#0  0x00007fff86cd94f0 in strlen ()
#1  0x000000010005bee1 in PyUnicode_FromString (u=0x4c <Address 0x4c out of bounds>) at unicodeobject.c:1735
#2  0x000000010003bb65 in PyDict_GetItemString (v=0x10075cc58, key=<value temporarily unavailable, due to optimizations>) at dictobject.c:2187
#3  0x000000010004eaf8 in add_getset [inlined] () at /Users/ronald/Projects/python/rw/cpython/Objects/typeobject.c:3771
#4  0x000000010004eaf8 in PyType_Ready (type=0x10159efb8) at typeobject.c:4109
#5  0x000000010159209a in PyInit__curses () at /Users/ronald/Projects/python/rw/cpython/Modules/_cursesmodule.c:3293
#6  0x00000001000c0e20 in _PyImport_LoadDynamicModule (name=0x1010f9f80, path=0x10074c750, fp=<value temporarily unavailable, due to optimizations>) at importdl.c:85
#7  0x00000001000beca0 in imp_load_dynamic (self=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at import.c:3804
#8  0x000000010009f0c8 in call_function [inlined] () at /Users/ronald/Projects/python/rw/cpython/Python/ceval.c:4003

For some reason a clean rebuild got a failure in another location, this time in the Py_XDECREF call on line 2966 in ceval.c:

    while (!EMPTY()) {
        v = POP();
        Py_XDECREF(v);
    }

Due to the optimization level I couldn't get more information.

When I patch the Makefile to use '-O2' instead of '-O3' in CFLAGS the problems stays (obviously with full rebuild).

Patching the optimization level down to '-O1' gives a slightly better result, this time I get:

./python.exe -SE -m sysconfig --generate-posix-vars
Fatal Python error: Py_Initialize: unable to load the file system codec
SystemError: NULL result without error in PyObject_Call

BTW. I tried to build with srcdir==builddir and "./configure CC=clang" on an up-to-date OSX 10.7 system with Xcode 4.2.1.


Summary of compiler results:

- gcc-4.2 (i686-apple-darwin11-gcc-4.2.1):   unicode.c OK, build OK
- gcc (i686-apple-darwin11-llvm-gcc-4.2):    unicode.c fails, build fails
- clang: unicode.c OK, build fails

----------
nosy: +ronaldoussoren
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Tue Dec 13 23:04:58 2011
From: report at bugs.python.org (Irmen de Jong)
Date: Tue, 13 Dec 2011 22:04:58 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1323813898.13.0.186338262373.issue13503@psf.upfronthosting.co.za>


Irmen de Jong <irmen at razorvine.net> added the comment:

Alexandre: the existing test_bytes already performs byte array pickle tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13503>
_______________________________________

From report at bugs.python.org  Tue Dec 13 23:33:08 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Dec 2011 22:33:08 +0000
Subject: [issue13595] Weird behavior with generators with self-referencing
	output.
In-Reply-To: <1323804340.16.0.941499228251.issue13595@psf.upfronthosting.co.za>
Message-ID: <1323815588.65.0.849955298932.issue13595@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is expected, and is due to the late binding of the "label" variable in the "item+label" expression.  Look at the example below:

>>> l = [lambda item: item + label for label in "ab"]
>>> f1, f2 = l
>>> print f1(''), f2('')
b b

For the lambda function, 'label' is a free variable, whose value is fetched from the global environment at runtime.  But at the time the second time is executed, 'label' has only one value, the last one from the for loop, and both functions only see 'b'.
A Generator Expression also defines a code block, and the late binding also applies.

Now to fix your code, if 'ab' can be of arbitrary length, I can't find a simpler way without yet another inline function:

l = [(lambda lbl:(item + lbl for item in t))(label) for t, label in zip(tees,"ab")]

'lbl' is still a free variable, but now 'lbl' comes from the lambda function, and there is one *different* *function* per iteration of the loop; so they are in fact distinct 'lbl' variables, and the generator expressions will correctly see different labels.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13595>
_______________________________________

From report at bugs.python.org  Tue Dec 13 23:52:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Dec 2011 22:52:50 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1323816770.41.0.633011627267.issue9116@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I just tried out http://www.bitvise.com/winsshd , which is free for personal
and noncommercial use. If you run the tests via an ssh connection, WinSSHD
automatically translates pop-ups into error messages:

C:\Users\stefan\cdecimal\PCbuild>python.exe -m test -uall test_capi
[1/1] test_capi
Warning -- threading._dangling was modified by test_capi
test test_capi failed -- Traceback (most recent call last):
  File "C:\Users\stefan\cdecimal\lib\test\test_capi.py", line 51, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\nPlease contact the application's support team for more information." != b'Fatal Python error: PyThreadState_Get: no current thread'

1 test failed:
    test_capi                              



Thus, by using ...

   self.assertIn(b'Fatal Python error:', err.rstrip())

in test_capi, the tests pass without any further intervention! This is most
interesting, to the point that I'm considering setting up a buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Wed Dec 14 02:44:43 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 01:44:43 +0000
Subject: [issue13582] IDLE and pythonw.exe stderr problem
In-Reply-To: <1323632290.53.0.810720020667.issue13582@psf.upfronthosting.co.za>
Message-ID: <1323827083.59.0.336227562607.issue13582@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Here is a list of open issues that describe IDLE suddenly crashing, which can be traced back to pythonw.exe:

#4765, #5707, #6257, #6739, #9404, #9925, #10365, #11437, #12274, #12988, #13052, #13071, #13078, #13153

This patch does not fix these errors, but at least these errors will no longer be fatal. This patch also "future-proofs" against yet to be discovered (or yet to be introduced) bugs into IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13582>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:07:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 02:07:48 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323828468.2.0.862254712146.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We could force sys.stderr to be always line-buffered if that's better than the current settings.

----------
components: +IO
nosy: +benjamin.peterson, pitrou, stutzbach
versions:  -Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:09:43 2011
From: report at bugs.python.org (Pyry Pakkanen)
Date: Wed, 14 Dec 2011 02:09:43 +0000
Subject: [issue13595] Weird behavior with generators with self-referencing
	output.
In-Reply-To: <1323804340.16.0.941499228251.issue13595@psf.upfronthosting.co.za>
Message-ID: <1323828583.61.0.88544184241.issue13595@psf.upfronthosting.co.za>


Pyry Pakkanen <frostburn at suomi24.fi> added the comment:

Oh, I was sure it had to do with binding issues. I just couldn't put my finger on it because the behavior seemed so counterintuitive.
Thanks for clearing things up. I can now work around this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13595>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:35:14 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 02:35:14 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <1323830114.4.0.472111408329.issue4625@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

A quick test on Linux would be:
    chmod -w ~/.idlerc/recent-files.lst

IDLE will give a traceback and not start. This should not be a fatal error.

The provided patch will present an error dialog if the recent files list can not be written.

----------
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file23948/issue4625.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:48:48 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 02:48:48 +0000
Subject: [issue13532] In IDLE,
	sys.stdout and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1323830928.7.0.628887800946.issue13532@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
title: In IDLE, sys.stdout.write and sys.stderr can write any pickleable object -> In IDLE, sys.stdout and sys.stderr can write any pickleable object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:52:33 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 02:52:33 +0000
Subject: [issue9404] IDLE won't launch on XP
In-Reply-To: <1280352480.94.0.617351160567.issue9404@psf.upfronthosting.co.za>
Message-ID: <1323831153.53.0.388445124966.issue9404@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This is a duplicate of #4625.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9404>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:22:03 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 14 Dec 2011 03:22:03 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323832923.54.0.459905532497.issue13597@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

I'm surprised to hear that stderr is line buffered by default. Historically stderr is never buffered (at least on POSIX) and for good reason: errors should be seen immediately

Was this an oversight in migrating stdin/out/err to the new io module?

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:59:22 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 03:59:22 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
Message-ID: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

string.Formatter doesn't support empty curly braces "{}" unlike str.format .

>>> import string
>>> a = string.Formatter()
>>> a.format("{}","test")
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    a.format("{}","hello")
  File "/usr/lib/python3.2/string.py", line 180, in format
    return self.vformat(format_string, args, kwargs)
  File "/usr/lib/python3.2/string.py", line 184, in vformat
    result = self._vformat(format_string, args, kwargs, used_args, 2)
  File "/usr/lib/python3.2/string.py", line 206, in _vformat
    obj, arg_used = self.get_field(field_name, args, kwargs)
  File "/usr/lib/python3.2/string.py", line 267, in get_field
    obj = self.get_value(first, args, kwargs)
  File "/usr/lib/python3.2/string.py", line 226, in get_value
    return kwargs[key]
KeyError: ''

----------
messages: 149420
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: string.Formatter doesn't support empty curly braces "{}"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:18:08 2011
From: report at bugs.python.org (Ryan Twitchell)
Date: Wed, 14 Dec 2011 04:18:08 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323836288.83.0.136842324721.issue13591@psf.upfronthosting.co.za>


Ryan Twitchell <metatheorem at gmail.com> added the comment:

Confirmed that this patch fixes the behavior shown in my original example, with 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:39:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 04:39:35 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323837575.66.0.507879498472.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
hgrepos: +95

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:44:39 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 04:44:39 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323837879.18.0.709072166135.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've attached a repository and patch with the recommended changes. I created an additional section that includes the documentation for the Action class (specifically the __init__ and __call__ signatures).

I believe this addresses the issues I raised. Any objections to this change? I haven't tested the rendering yet, but I'll do that before pushing to the master if it's adequate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:46:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 04:46:35 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323837995.2.0.956711426355.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23949/956c6d33a57d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:25:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Dec 2011 05:25:27 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323840327.81.0.105431690915.issue13540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My guess from the way the docs are written now is that subclassing from Action and over-riding just the __call__ method is the intended way, not just the recommended. If so, Action is a quasi-private class, only exposed so it could be subclassed with one method given. And if so, one could question whether anything more need be documented.

However, in your patch, you write

"+Many actions also override the ``__init__`` method, validating the parameters to the argument definition and raising a ValueError or other Exception on failure."

What 'many actions' are you referring to? Ones you have written, by referring to the code? Ones you think might be written if the doc were added?

In any case, I would prefer input from Stephen before we expose and thereby freeze the __init__ signature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:39:53 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 05:39:53 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323841193.67.0.0471600700257.issue13598@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Attached is patch to fix this issue.

----------
keywords: +patch
type:  -> behavior
Added file: http://bugs.python.org/file23950/issue13598.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:40:30 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 05:40:30 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323841230.08.0.433228816471.issue13598@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
components: +Library (Lib)
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:45:04 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Dec 2011 05:45:04 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323841504.71.0.255919492848.issue13591@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Updated patch with tests.

----------
Added file: http://bugs.python.org/file23951/issue13591-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:51:30 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 05:51:30 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323841890.33.0.0723225148323.issue13598@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Sorry, the patch has an mistake.
ValueErro should be ValueError.

----------
Added file: http://bugs.python.org/file23952/issue13598.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:51:59 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 05:51:59 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323841919.63.0.394917414832.issue13598@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


Removed file: http://bugs.python.org/file23950/issue13598.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:54:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Dec 2011 05:54:30 +0000
Subject: [issue13582] IDLE and pythonw.exe stderr problem
In-Reply-To: <1323632290.53.0.810720020667.issue13582@psf.upfronthosting.co.za>
Message-ID: <1323842070.39.0.0917928475745.issue13582@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

IDLE.app on OS X also has the issue of stderr messages not being presented to users unless you know to look in the system log where they get written.  So writing to stderr is not fatal but displaying them in a popup would be an improvement.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13582>
_______________________________________

From report at bugs.python.org  Wed Dec 14 09:13:45 2011
From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=)
Date: Wed, 14 Dec 2011 08:13:45 +0000
Subject: [issue13599] Compiled regexes don't show all attributes in dir()
Message-ID: <1323850425.79.0.94934063883.issue13599@psf.upfronthosting.co.za>


New submission from Martin H?cker <spamfaenger at gmx.de>:

When looking at a regex with dir() you don't get all available attributes - which is inconvenient as some very important ones (like .pattern) are not visible.

To demonstrate:

> import re
> re.compile('foo').pattern
'foo'
> dir(re.compile('foo'))

['__copy__',
 '__deepcopy__',
 'findall',
 'finditer',
 'match',
 'scanner',
 'search',
 'split',
 'sub',
 'subn']

----------
components: Regular Expressions
messages: 149428
nosy: dwt, ezio.melotti
priority: normal
severity: normal
status: open
title: Compiled regexes don't show all attributes in dir()
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13599>
_______________________________________

From report at bugs.python.org  Wed Dec 14 09:16:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Dec 2011 08:16:51 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <1323850611.52.0.544957734918.issue4625@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

A couple of comments on the patch:
1. Displaying a popup is fine but it gets annoying when it does it repeatedly.  Since this is really a non-fatal error as the user can continue, it would be better to only display the popup once.
2. Another file in .idlerc, breakpoints.lst, has the same problem.

Here are updated patches that address these issues.

----------
nosy: +ned.deily
stage: test needed -> patch review
Added file: http://bugs.python.org/file23953/issue4625_rev1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Wed Dec 14 09:17:05 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Dec 2011 08:17:05 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <1323850625.69.0.395434004725.issue4625@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file23954/issue4625_rev1_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Wed Dec 14 09:21:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Dec 2011 08:21:41 +0000
Subject: [issue9404] IDLE won't launch on XP
In-Reply-To: <1280352480.94.0.617351160567.issue9404@psf.upfronthosting.co.za>
Message-ID: <1323850901.48.0.691682694783.issue9404@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As there are proposed patches in Issue4625 that address the original problem reported here, let's move the discussion there.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IDLE won't open anymore, .idlerc unaccessible
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9404>
_______________________________________

From report at bugs.python.org  Wed Dec 14 09:56:36 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 14 Dec 2011 08:56:36 +0000
Subject: [issue13600] rot_13 codec not working
Message-ID: <1323852996.8.0.468969751026.issue13600@psf.upfronthosting.co.za>


New submission from Ram Rachum <ram at rachum.com>:

The `rot_13` codec is supposed to work like this, no?

>>> 'qwerty'.encode('utf-8')
b'qwerty'
>>> 'qwerty'.encode('rot_13')
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    'qwerty'.encode('rot_13')
TypeError: encoder did not return a bytes object (type=str)

>>> b'qwerty'.decode('utf-8')
'qwerty'
>>> b'qwerty'.decode('rot_13')
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    b'qwerty'.decode('rot_13')
  File "C:\Python32\lib\encodings\rot_13.py", line 19, in decode
    return (input.translate(rot13_map), len(input))
AttributeError: 'memoryview' object has no attribute 'translate'

----------
components: Library (Lib)
messages: 149431
nosy: cool-RR
priority: normal
severity: normal
status: open
title: rot_13 codec not working
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13600>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:06:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Dec 2011 09:06:28 +0000
Subject: [issue13599] Compiled regexes don't show all attributes in dir()
In-Reply-To: <1323850425.79.0.94934063883.issue13599@psf.upfronthosting.co.za>
Message-ID: <1323853588.56.0.988006335259.issue13599@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This seems already fixed in 2.7.2+/3.2/3.3, what version have you tried?

----------
resolution:  -> out of date
status: open -> pending
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13599>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:06:49 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 09:06:49 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323853609.99.0.913566353645.issue13598@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Attached is a patch for test.test_string to test for this bug.
Can somebody please comment on my paches or commit my patches.

----------
Added file: http://bugs.python.org/file23955/test_string.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:08:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Dec 2011 09:08:07 +0000
Subject: [issue13600] rot_13 codec not working
In-Reply-To: <1323852996.8.0.468969751026.issue13600@psf.upfronthosting.co.za>
Message-ID: <1323853687.62.0.616354747935.issue13600@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See #7475.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13600>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:12:04 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 09:12:04 +0000
Subject: [issue13571] Backup files support in IDLE
In-Reply-To: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>
Message-ID: <1323853924.33.0.234099937363.issue13571@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

In response to Roger Serwy:
>>> I rarely have IDLE crash on Linux. If you're experiencing these issues on Windows, see #13582.

I'm on Ubuntu Linux and IDLE does'nt crash.
Many editors have backup files in the case of a crash and after a crash have an option to copy the backup file to the original.
Also if IDLE has a bug it can crash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13571>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:26:45 2011
From: report at bugs.python.org (Laurent Mazuel)
Date: Wed, 14 Dec 2011 09:26:45 +0000
Subject: [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1323854805.42.0.870605312739.issue13498@psf.upfronthosting.co.za>


Changes by Laurent Mazuel <laurent.mazuel at gmail.com>:


----------
nosy: +Laurent.Mazuel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13498>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:30:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 14 Dec 2011 09:30:36 +0000
Subject: [issue13600] rot_13 codec not working
In-Reply-To: <1323852996.8.0.468969751026.issue13600@psf.upfronthosting.co.za>
Message-ID: <1323855036.52.0.167594584134.issue13600@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ram Rachum wrote:
> The `rot_13` codec is supposed to work like this, no?

No it isn't. In Python 3, str.encode() always encodes to bytes and bytes.decode() always decodes to str. IOW, str.encode() encodes text (Unicode) to data (bytes), and bytes.decode() decodes data to text. ROT-13 is not a character encoding, so it cannot be used in this manner.

It's still available in the codecs module, though:

>>> import codecs
>>> codecs.lookup('rot-13').encode('qwerty')
('djregl', 6)

Other text->text and bytes->bytes codecs are also available there.

----------
nosy: +petri.lehtinen
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13600>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:47:56 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 14 Dec 2011 09:47:56 +0000
Subject: [issue13600] rot_13 codec not working
In-Reply-To: <1323852996.8.0.468969751026.issue13600@psf.upfronthosting.co.za>
Message-ID: <1323856076.57.0.281453400373.issue13600@psf.upfronthosting.co.za>


Ram Rachum <ram at rachum.com> added the comment:

Then I suggest replacing this error message:

    encoder did not return a bytes object (type=str)

and this one:

    'memoryview' object has no attribute 'translate'

With something like:

    Please use `codecs.lookup('rot-13').encode`

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13600>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:48:45 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 14 Dec 2011 10:48:45 +0000
Subject: [issue13600] rot_13 codec not working
In-Reply-To: <1323852996.8.0.468969751026.issue13600@psf.upfronthosting.co.za>
Message-ID: <1323859725.03.0.86968242117.issue13600@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Issue #7475 discusses fixing the error messages, too.

----------
components: +Library (Lib)
resolution:  -> duplicate
stage: committed/rejected -> 
status: open -> closed
superseder:  -> codecs missing: base64 bz2 hex zlib hex_codec ...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13600>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:51:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 14 Dec 2011 10:51:53 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1323859913.97.0.740678839273.issue7475@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Issue 13600 has been marked as a duplicate of this issue.

FRT, +1 to the idea of adding encoded_format and decoded_format attributes to CodecInfo, and also to adding {str,bytes}.{transform,untransform} back.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:55:00 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 14 Dec 2011 10:55:00 +0000
Subject: [issue13359] urllib2 doesn't escape spaces in http requests
In-Reply-To: <1320610427.07.0.982938376676.issue13359@psf.upfronthosting.co.za>
Message-ID: <1323860100.69.0.561112046238.issue13359@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13359>
_______________________________________

From report at bugs.python.org  Wed Dec 14 12:08:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=)
Date: Wed, 14 Dec 2011 11:08:54 +0000
Subject: [issue13599] Compiled regexes don't show all attributes in dir()
In-Reply-To: <1323850425.79.0.94934063883.issue13599@psf.upfronthosting.co.za>
Message-ID: <1323860934.82.0.842763349945.issue13599@psf.upfronthosting.co.za>


Martin H?cker <spamfaenger at gmx.de> added the comment:

Indeed, I'm on version

% python --version
Python 2.7.1


Sorry.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13599>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:08:24 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 14 Dec 2011 12:08:24 +0000
Subject: [issue13359] urllib2 doesn't escape spaces in http requests
In-Reply-To: <1320610427.07.0.982938376676.issue13359@psf.upfronthosting.co.za>
Message-ID: <1323864504.22.0.41373519415.issue13359@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Seems good.

----------
nosy: +maniram.maniram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13359>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:34:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2011 12:34:42 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <E1Rao2i-0004fV-MG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f5aed0dba844 by Giampaolo Rodola' in branch 'default':
Fix #8684: make sched.scheduler class thread-safe
http://hg.python.org/cpython/rev/f5aed0dba844

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:36:09 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 12:36:09 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1323866169.78.0.471491522772.issue8684@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:54:21 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 12:54:21 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1323867261.96.0.0866845745629.issue13449@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What about run(nowait=...) or run(only_ready=...)?
Doing this as a separate method seems unnecessarily complicated to me in terms of implementation (move run logic into _run, add "run" and "run_nowait", etc...).
Most importantly, the user will have to remember two methods which are basically equivalent in terms of "what they actually do".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:58:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 12:58:03 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1323867483.87.0.85053207748.issue13449@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's a good point. Then perhaps call the flag "wait" or "blocking", since it avoids false positives and is more explicit than "async"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:07:04 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 13:07:04 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1323868024.93.0.263621370769.issue13449@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

"blocking" seems the most explicit to me.
With this, we can also fix issue1641 by providing a specific section into asyncore doc which explains how to use asyncore in conjunction with sched.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:07:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 13:07:43 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323832923.54.0.459905532497.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323868045.3334.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm surprised to hear that stderr is line buffered by default.
> Historically stderr is never buffered (at least on POSIX) and for good
> reason: errors should be seen immediately
> 
> Was this an oversight in migrating stdin/out/err to the new io module?

Until recently it wasn't possible to have an unbuffered text stream with
the new io stack. Now it's possible in write-only mode, although the
open() builtin hasn't been updated for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:11:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 13:11:32 +0000
Subject: [issue13601] sys.stderr should be unbuffered (or always line-buffered)
Message-ID: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In issue13597, Philip Jenvey points out:

?I'm surprised to hear that stderr is line buffered by default. Historically stderr is never buffered (at least on POSIX) and for good reason: errors should be seen immediately?

Recent changes to the IO stack should allow stderr to be opened in fully unbuffered mode (and open(..., 'w', buffering=0) can be allowed too). Or at least it could be always line-buffered, even when redirected to a file.

----------
components: IO, Interpreter Core, Library (Lib)
messages: 149447
nosy: benjamin.peterson, gvanrossum, pitrou, pjenvey, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: sys.stderr should be unbuffered (or always line-buffered)
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:22:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Dec 2011 13:22:31 +0000
Subject: [issue13599] Compiled regexes don't show all attributes in dir()
In-Reply-To: <1323850425.79.0.94934063883.issue13599@psf.upfronthosting.co.za>
Message-ID: <1323868951.87.0.882283732575.issue13599@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13599>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:38:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2011 13:38:51 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <E1Rap2o-0002tA-BZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2975618965c0 by Giampaolo Rodola' in branch 'default':
Fix #13449: add 'blocking' parameter to sched.scheduler.run() so that the scheduler can be used in non-blocking applications
http://hg.python.org/cpython/rev/2975618965c0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:41:06 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 13:41:06 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1323870066.32.0.620065153635.issue13449@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee:  -> giampaolo.rodola
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:41:46 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 13:41:46 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1323870106.29.0.964791319985.issue13449@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +josiah.carlson, josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:44:09 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 13:44:09 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1323870249.3.0.67173830756.issue1641@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

With issue13449 fixed I think we can now provide this functionnality by adding a specific section into asyncore doc which explains how to use asyncore in conjunction with sched module.
As such, asyncore.py itself won't need any change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:54:31 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 13:54:31 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323870871.47.0.480315785399.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Most of the Action subclasses in argparse override __init__ and they raise ValueErrors when the parameters aren't as expected for that argument. This was my reason for adding that comment. If the basic Actions require this level of validation, wouldn't a custom action also want to supply this type of behavior? I'm sure I've overridden Action.__init__ in some of the subclasses I've created, but I don't remember specifically why.

I agree freezing the __init__ signature is undesirable. It would be preferable if the API called a hook for validating the argument parameters against the action. My intention, however, was to document the existing behavior, not influence changes in the behavior.

Perhaps the recommended API really isn't to subclass Action, but to supply a callable that takes the __init__ args which validates the parameters and returns a callable which takes the __call__ args which should set attributes on the namespace. Perhaps the Action class is only one such implementation of the API. Indeed, that was my understanding of the API as it is currently documented before Terry suggested otherwise.

What do you think about instead of documenting the Action class, we formalize the API, similar to how I described it in the previous paragraph, and then suggest that an Action subclass with an overridden __call__ is the most direct way to implement the Action API?


In reviewing the code again, I note that not just most, but all of the Action subclasses override __init__. I also note that not all of them accept the same parameters. For example, the _StoreConstAction does not accept an nargs parameter.

>>> p = argparse.ArgumentParser()
>>> p.add_argument('--awesome-sauce', action="store_const", const=True, nargs=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python\lib\argparse.py", line 1281, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() got an unexpected keyword argument 'nargs'

So it seems that the Action API is slightly different than I described. The first callable should accept all of the parameters passed to add_argument _except_ for the action parameter itself. I think by indicating this in the API description, we avoid the problem of freezing any additional signature.

I'll take another stab at updating the documentation with these findings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:58:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 13:58:27 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1323871107.97.0.606950293614.issue1641@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With issue13449 fixed I think we can now provide this functionnality by 
> adding a specific section into asyncore doc which explains how to use
> asyncore in conjunction with sched module.

How would it work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Wed Dec 14 15:24:38 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 14:24:38 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1323872678.16.0.0110370948978.issue1641@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Now that I think of it maybe some kind of wrapper would still be necessary.
As of right now, we'd do something like this.
At the core we would have:

import asyncore, asynchat, sched

# global
scheduler = sched.scheduler()

while 1:
    asyncore.loop(timeout=1.0, count=1)  # count=1 makes loop() return after 1 loop
    scheduler.run(blocking=False)       
    

Then, every dispatcher can define a scheduled function of its own:


class Client(asynchat.async_chat):
    # an already connected client 
    # (the "connector" code is not included in this example)

    def __init__(self, *args, **kwargs):
        asynchat.async_chat.__init__(self, *args, **kwargs)
        self.set_terminator("\r\n")
        self.set_timeout()
        
    def set_timeout(self):
        self.timeout = scheduler.enter(30, 0, self.handle_timeout)
        
    def reset_timeout(self):
        scheduler.cancel(self.timeout)
        self.set_timeout()
    
    def found_terminator(self):
        scheduler.cancel(self.timeout)
        self.timeout = scheduler.enter(30, 0, self.handle_timeout)
        # do something with the received data...
        
    def handle_timeout(self):
        self.push("400 connection timed out\r\n")
        self.close()
        
    def close(self):
        scheduler.cancel(self.timeout)
        asynchat.async_chat.close(self)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Wed Dec 14 15:33:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 14:33:28 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1323872678.16.0.0110370948978.issue1641@psf.upfronthosting.co.za>
Message-ID: <1323873190.3334.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> while 1:
>     asyncore.loop(timeout=1.0, count=1)  # count=1 makes loop() return after 1 loop
>     scheduler.run(blocking=False)       

Isn't that both ugly and imprecise?
The right way to do it is to set the timeout of the select() call
according to the deadline of the next scheduled call in the scheduler.
But you probably need to modify asyncore for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Wed Dec 14 16:29:54 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Dec 2011 15:29:54 +0000
Subject: [issue13601] sys.stderr should be unbuffered (or always line-buffered)
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1323876594.8.0.471569022136.issue13601@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I *thought* I mimicked what C stdio did ~20 years ago...  I'd be happy to follow what it does today if it changed or if I made a mistake.

That said, IMO:

Line-buffering should be good enough since in practice errors messages are always terminated by a newline.

I'm hesitant to make it line-buffered by default when directed to a file, since this could significantly slow down a program that for some reason produces super-voluminous output (e.g. when running a program with heavy debug logging turned on).

Maybe we need better command-line control to override the defaults?  Are there precedents e.g. in Bash flags?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Wed Dec 14 16:50:13 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 15:50:13 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <1323877813.87.0.916081627216.issue4625@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I just tested Ned's updated patches against 3.3a0 and 2.7 and they work as advertised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:16:04 2011
From: report at bugs.python.org (James C. Ahlstrom)
Date: Wed, 14 Dec 2011 16:16:04 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1323879364.93.0.603261771638.issue1757072@psf.upfronthosting.co.za>


James C. Ahlstrom <jahlstr at gmail.com> added the comment:

For completeness, I checked other versions of Python.  The example zip file fails in Python 3.1, but succeeds in Python 3.2.2.  The patch for 3.2.2 removed the check for correct comment length, but substituted no further check for validity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:33:08 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Dec 2011 16:33:08 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323880388.86.0.228078762316.issue13598@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/issue13598>
_______________________________________

From report at bugs.python.org  Wed Dec 14 18:07:59 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 17:07:59 +0000
Subject: [issue13571] Backup files support in IDLE
In-Reply-To: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>
Message-ID: <1323882479.33.0.419503269756.issue13571@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Would you want to collaborate on writing an extension to do this? Check out IdleX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13571>
_______________________________________

From report at bugs.python.org  Wed Dec 14 18:24:22 2011
From: report at bugs.python.org (Sophia K. Cheng)
Date: Wed, 14 Dec 2011 17:24:22 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1323877813.87.0.916081627216.issue4625@psf.upfronthosting.co.za>
Message-ID: <CAOWrcE26TnjrmqN-VU2wwFYd04jKoT7rbnpYwqhR-Qiqr+MJvw@mail.gmail.com>


Sophia K. Cheng <sophia.cheng at gmail.com> added the comment:

Hi Ned,

Thanks for the patch, I appreciate it.  Sadly, I've since upgraded my
laptop to Win 7, and don't seem to be having the problem anymore :-/ , so I
can't verify.  But thank you for writing a patch.

Sincerely,
Sophia

On Wed, Dec 14, 2011 at 10:50 AM, Roger Serwy <report at bugs.python.org>wrote:

>
> Roger Serwy <roger.serwy at gmail.com> added the comment:
>
> I just tested Ned's updated patches against 3.3a0 and 2.7 and they work as
> advertised.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4625>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Wed Dec 14 18:38:51 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 14 Dec 2011 17:38:51 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323729258.19.0.286424646454.issue13532@psf.upfronthosting.co.za>
Message-ID: <4EE8DF29.1080406@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> We should like the IDLE shell to give the same results as the standard shell. 

I disagree that this should be an absolute principle. Two standard
shells may not give the same result due to running in different
environments, so forcing IDLE to give the same result as a specific
standard shell is not reasonable when taken absolutely.

----------
title: In IDLE, sys.stdout and sys.stderr can write any pickleable object -> In IDLE,	sys.stdout.write and sys.stderr can write any pickleable object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Wed Dec 14 18:41:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2011 17:41:23 +0000
Subject: [issue4028] Problem compiling the multiprocessing module on sunos5
In-Reply-To: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>
Message-ID: <E1RaspV-00021I-VL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8c658b625475 by Charles-Fran?ois Natali in branch '2.7':
Issue #4028: Make multiprocessing build on SunOS.
http://hg.python.org/cpython/rev/8c658b625475

New changeset 49e82c885d6b by Charles-Fran?ois Natali in branch '3.2':
Issue #4028: Make multiprocessing build on SunOS.
http://hg.python.org/cpython/rev/49e82c885d6b

New changeset 4a27b5ab2710 by Charles-Fran?ois Natali in branch 'default':
Null merge - Issue #4028: Make multiprocessing build on SunOS.
http://hg.python.org/cpython/rev/4a27b5ab2710

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4028>
_______________________________________

From report at bugs.python.org  Wed Dec 14 18:45:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Dec 2011 17:45:10 +0000
Subject: [issue4028] Problem compiling the multiprocessing module on sunos5
In-Reply-To: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>
Message-ID: <1323884710.31.0.666637181146.issue4028@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks Craig.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4028>
_______________________________________

From report at bugs.python.org  Wed Dec 14 19:31:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2011 18:31:02 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <E1RatbY-0001Ru-JK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fbcaeb4a8654 by Charles-Fran?ois Natali in branch '2.7':
Issue #13453: Fix a race condition in test_poplib.
http://hg.python.org/cpython/rev/fbcaeb4a8654

New changeset e497a3ed9beb by Charles-Fran?ois Natali in branch '3.2':
Issue #13453: Fix a race condition in test_poplib.
http://hg.python.org/cpython/rev/e497a3ed9beb

New changeset 1eae8154c109 by Charles-Fran?ois Natali in branch 'default':
Issue #13453: Fix a race condition in test_poplib.
http://hg.python.org/cpython/rev/1eae8154c109

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Wed Dec 14 19:33:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Dec 2011 18:33:31 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1323887611.26.0.331023502442.issue11886@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Another failure on a 2.7 FreeBSD buildbot:
"""
test test_time failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_time.py", line 193, in test_tzset
    self.assertTrue(time.tzname[1] == 'AEDT', str(time.tzname[1]))
AssertionError: EDT
"""

http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2 2.7/builds/859/steps/test/logs/stdio

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11886>
_______________________________________

From report at bugs.python.org  Wed Dec 14 19:38:01 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 14 Dec 2011 18:38:01 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323887881.83.0.596639258787.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I would certainly be in favour of restoring the python 2.x behaviour, at least where standard error is concerned. When writing Python programs, it's important to see exceptions immediately, and not lose them entirely in some circumstances.

I reported this as a documentation bug because I got the impression it was deliberate, mostly from reading http://bugs.python.org/issue4705 and the comp.lang.python thread in the description, but I personally think the Python 2.x behaviour was preferable.

----------
components:  -IO
nosy:  -benjamin.peterson, pitrou, pjenvey, stutzbach
versions: +Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 14 19:41:03 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 14 Dec 2011 18:41:03 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323888063.78.0.866981965347.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Ooops, seems like I just ran into a bug in the bug tracker too, it seems to have backed out other people's changes. Restoring them...

----------
components: +IO
nosy: +benjamin.peterson, pitrou, pjenvey, stutzbach
versions:  -Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 14 19:49:56 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 18:49:56 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1323888596.49.0.718963769.issue4832@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I was unable to produce the crash that Pavel described in msg87703.  

Just adding "defaultextension=''" solves this issue for Windows and still preserves the correct behavior on Linux. Amaury's quote of tcl/tk documentation in msg87695 mentions this as well.

I tested this on Linux with 2.7.1 and 3.2 and on Windows Vista using 2.7.1 and 3.2.2. 

Attached is a diff against 3.3a0.

----------
nosy: +serwy
Added file: http://bugs.python.org/file23956/issue4832.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Wed Dec 14 20:13:23 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 19:13:23 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1323890003.4.0.558230174065.issue10365@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

William's explanation in msg123203 for the cause of the error and the solution for keeping a reference to "flist" is good. IDLE has only one instance of FileList while running anyways.

Attached is a patch that behaves like William's description.

The modification to PyShell.py is necessary for a corner-case. If the last IDLE window is closed with the Open File dialog still open, then FileList.py and WindowList.py both call .quit(). Without the modification, IDLE closes after selecting a file since root.mainloop() returns and root.destroy() gets executed. 

The alternative (and simpler) method is to have the Open File dialog be modal, but AFAIK it can't be set to modal.

----------
nosy: +serwy
Added file: http://bugs.python.org/file23957/issue10365_rev2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10365>
_______________________________________

From report at bugs.python.org  Wed Dec 14 20:28:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 14 Dec 2011 19:28:55 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1323890935.38.0.408295219864.issue13402@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attaching an updated patch. The documentation now says that sys.executable may be an empty string. The patch also adds a test to make sure that sys.executable is absolute.

----------
Added file: http://bugs.python.org/file23958/issue13402_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Wed Dec 14 20:31:31 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2011 19:31:31 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1323891091.7.0.623315307609.issue12082@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/issue12082>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:16:49 2011
From: report at bugs.python.org (Raul Morales)
Date: Wed, 14 Dec 2011 20:16:49 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323893809.78.0.815211904635.issue13516@psf.upfronthosting.co.za>


Raul Morales <raul.mh at gmail.com> added the comment:

I have just posted a comment, too.

http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.html?showComment=1323891345946#c2875224484376643310

With this approach, anyone can implement support for any format easily. It is powerful. But IMHO, built-in support for Gzip and Zip formats would cover the basic needs of almost all platforms where python run.

Mix-in classes can be implemented in just a few lines of code, and it matches with your idea. Of course, IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:18:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Dec 2011 20:18:26 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1323893906.38.0.273182843704.issue13532@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In English, "We should like" is far from an absolute statement. "IDLE must" would be such. In any case, I hope you agree that crashing is bad. It is also not good if IDLE, as a development environment, enables code that violates the doc specifications and that will not run in the standard interpreter in standard batch mode with no shell.

I also so not understand you reverting the title to the arguably incorrect non-parallel construction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:18:40 2011
From: report at bugs.python.org (James Classen)
Date: Wed, 14 Dec 2011 20:18:40 +0000
Subject: [issue13602] format string '%b' doesn't work as expected
Message-ID: <1323893920.67.0.120555920647.issue13602@psf.upfronthosting.co.za>


New submission from James Classen <jclassen at gmail.com>:

I notice that, in versions 2.7 and 3.2 on Windows XP (haven't tested any other versions or platforms), the following statements in the interpreter work as documented:

'%x' % 17
'%o' % 17

and output '11' and '21' respectively, as I expect. However,

'%b' % 17

throws "ValueError: unsupported format character 'b' (0x62) at index 1" instead of returning '10001'.

----------
components: None
messages: 149471
nosy: James.Classen
priority: normal
severity: normal
status: open
title: format string '%b' doesn't work as expected
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13602>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:30:45 2011
From: report at bugs.python.org (James Classen)
Date: Wed, 14 Dec 2011 20:30:45 +0000
Subject: [issue13602] format string '%b' doesn't work as expected
In-Reply-To: <1323893920.67.0.120555920647.issue13602@psf.upfronthosting.co.za>
Message-ID: <1323894645.08.0.166823156044.issue13602@psf.upfronthosting.co.za>


James Classen <jclassen at gmail.com> added the comment:

I didn't see section 4.6.2 of the library for 3.2 documentation, only section 5.6.2 of the 2.7 docs. So this is an invalid issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13602>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:45:51 2011
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 14 Dec 2011 20:45:51 +0000
Subject: [issue11574] TextIOWrapper: Unicode Fallback Encoding on Python 3.3
In-Reply-To: <1300296395.6.0.964785890032.issue11574@psf.upfronthosting.co.za>
Message-ID: <1323895551.16.0.870771052965.issue11574@psf.upfronthosting.co.za>


Carl Meyer <carl at dirtcircle.com> added the comment:

Here's an example real-world case where the only solution I could find was to simply avoid non-ASCII characters entirely (which is obviously not a real solution): https://github.com/pypa/virtualenv/issues/201#issuecomment-3145690

distutils/distribute require long_description to be a string, not bytes (so it can rfc822-escape it, and use string methods to do so), but does not explicitly set an output encoding when it writes egg-info. This means that a developer either has the choice to a) break installation of their package on any system with an ASCII default locale, or b) not use any non-ASCII characters in long_description.

One might say, "ok, this is a bug in distutils/distribute, it should explicitly specify UTF-8 encoding when writing egg-info." But if this is a sensible thing for distutils/distribute to do, regardless of user locale, why would it not be equally sensible for Python itself to have the default output encoding always be UTF-8 (with the ability for a developer who wants to support arbitrary user locale to explicitly do so)?

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11574>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:46:02 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 14 Dec 2011 20:46:02 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323895562.4.0.37565462068.issue13516@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It seems that you agree that the basic mechanism is good enough to build on, so I'd rather leave the proposed stdlib change as is, but provide examples of how to achieve gzip/zip compression for rotated logs in the Logging Cookbook. The reason I don't want to add these in the stdlib is that I have to support anything I add indefinitely, so I don't want to add anything which will not be often used. This is the first time the issue has come up in all the years since the rotating file handlers have been around, so while I want to support your use case, I want to minimise stdlib changes and additions as much as I can.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:59:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 14 Dec 2011 20:59:10 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323893906.38.0.273182843704.issue13532@psf.upfronthosting.co.za>
Message-ID: <4EE90E1C.6020009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I also so not understand you reverting the title to the arguably incorrect non-parallel construction.

That is an (unfortunate) side effect of replying by email.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:07:12 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 14 Dec 2011 21:07:12 +0000
Subject: [issue11574] TextIOWrapper: Unicode Fallback Encoding on Python 3.3
In-Reply-To: <1323895551.16.0.870771052965.issue11574@psf.upfronthosting.co.za>
Message-ID: <4EE90FFE.8000908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> One might say, "ok, this is a bug in distutils/distribute, it should
> explicitly specify UTF-8 encoding when writing egg-info." But if this
> is a sensible thing for distutils/distribute to do, regardless of
> user locale, why would it not be equally sensible for Python itself
> to have the default output encoding always be UTF-8 (with the ability
> for a developer who wants to support arbitrary user locale to
> explicitly do so)?

The file encoding is part of the file format. Just as Python can't know
what the file format is (else it could allow writing, say, dictionaries
to a file), it can't know what the file encoding is, either - there is
a need to guess. distutils *does* know the format, so it's clearly a
bug in distutils and not in Python.

The Zen says "In the face of ambiguity, refuse the temptation to guess."
>From that point of view, Python should just refuse to open files in text
mode with no encoding specified. However, it also says "Although
practicality beats purity.", which brings us back to guessing.

Guessing the "best" file encoding is really tricky, and Python has
chosen to use the locale's encoding. That can't be changed anymore
(except perhaps by PEP) since it would be an incompatible change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11574>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:13:56 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 14 Dec 2011 21:13:56 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1323897236.31.0.0621266535662.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file23959/be8a59fcba49.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:15:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 21:15:00 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323897300.71.0.852771913137.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I've opened issue13601 for the possible behaviour change)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:20:02 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Dec 2011 21:20:02 +0000
Subject: [issue13593] importlib needs to be updated for __qualname__
In-Reply-To: <1323785296.62.0.631553026432.issue13593@psf.upfronthosting.co.za>
Message-ID: <1323897602.63.0.151949326305.issue13593@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Seems fine to me, and if Antoine says it's doing the right thing then I'm cool with the patch.

----------
assignee:  -> meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13593>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:21:44 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Dec 2011 21:21:44 +0000
Subject: [issue13588] Change name of internal closure functions in importlib
In-Reply-To: <1323703954.36.0.434643027987.issue13588@psf.upfronthosting.co.za>
Message-ID: <1323897704.93.0.487264028442.issue13588@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the patch! I will try to find some time to do a proper review if someone else doesn't beat me to it (although first glance seems to suggest it all looks fine).

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13588>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:29:12 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Dec 2011 21:29:12 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323898152.32.0.0339494335709.issue13591@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch looks good to me.

----------
assignee:  -> meador.inge
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:54:00 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 14 Dec 2011 21:54:00 +0000
Subject: [issue13582] IDLE and pythonw.exe stderr problem
In-Reply-To: <1323632290.53.0.810720020667.issue13582@psf.upfronthosting.co.za>
Message-ID: <1323899640.64.0.966602035562.issue13582@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I don't have a Mac to test against. Is there anything I need to do to improve the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13582>
_______________________________________

From report at bugs.python.org  Wed Dec 14 23:06:49 2011
From: report at bugs.python.org (Raul Morales)
Date: Wed, 14 Dec 2011 22:06:49 +0000
Subject: [issue13516] Gzip old log files in rotating handlers
In-Reply-To: <1322762423.02.0.0799773449724.issue13516@psf.upfronthosting.co.za>
Message-ID: <1323900409.53.0.731136060806.issue13516@psf.upfronthosting.co.za>


Raul Morales <raul.mh at gmail.com> added the comment:

Ok, it is reasonable. It has no sense add support for compression since I am the only user who want it.

Maybe in the future ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13516>
_______________________________________

From report at bugs.python.org  Thu Dec 15 00:11:28 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 14 Dec 2011 23:11:28 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1323904288.66.0.767522480397.issue13402@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

sys.executable can be None on Jython (and I believe IronPython) when ran in an 'embedded' mode

----------
nosy: +dino.viehland, pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Thu Dec 15 00:18:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2011 23:18:30 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <E1Ray5k-0001j7-RP@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7857d1f4ce79 by Ned Deily in branch '2.7':
Issue #4625: If IDLE cannot write to its recent file or breakpoint
http://hg.python.org/cpython/rev/7857d1f4ce79

New changeset 26e3e542d20d by Ned Deily in branch '3.2':
Issue #4625: If IDLE cannot write to its recent file or breakpoint
http://hg.python.org/cpython/rev/26e3e542d20d

New changeset ba832d42cd9e by Ned Deily in branch 'default':
Issue #4625: If IDLE cannot write to its recent file or breakpoint
http://hg.python.org/cpython/rev/ba832d42cd9e

New changeset f6ca22bbf138 by Ned Deily in branch '2.7':
Issue #4625: add NEWS entry.
http://hg.python.org/cpython/rev/f6ca22bbf138

New changeset f1fe411bfd6b by Ned Deily in branch '3.2':
Issue #4625: add NEWS entry.
http://hg.python.org/cpython/rev/f1fe411bfd6b

New changeset f6510cdf4ada by Ned Deily in branch 'default':
Issue #4625: Add NEWS entry.
http://hg.python.org/cpython/rev/f6510cdf4ada

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Thu Dec 15 00:23:10 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Dec 2011 23:23:10 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1228966222.3.0.407670135818.issue4625@psf.upfronthosting.co.za>
Message-ID: <1323904990.98.0.720523744023.issue4625@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Applied to 2.7 (for release in 2.7.3), 3.2 (3.2.3), and default (3.3).

----------
assignee:  -> ned.deily
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Thu Dec 15 01:10:08 2011
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 15 Dec 2011 00:10:08 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323907808.06.0.237430871161.issue12149@psf.upfronthosting.co.za>


Mark Shannon <marks at dcs.gla.ac.uk> added the comment:

Please reopen this bug as the fix is wrong.

This fix merely hides the symptoms of _PyType_Lookup returning a dead object, by calling PyType_Modified() frequently, thus ensuring the type method cache is almost always invalidated.
This results in a significant slow down in pystones (~4%) due to a large slowdown (~60%) in _PyType_Lookup.

I don't know what the root cause is, but it could be:
A failure to call PyType_Modified() at the correct point (probably somewhere in iobase.c)
or it could be:
Deallocation not conforming to topographical ordering (ie. instance first then class), due to a cycle involving a borrowed reference.
(Or it could be something else)

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 02:13:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2011 01:13:34 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323911614.88.0.97288746639.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There are a *lot* of characters with semantic significance that are reported by the tokenize module as generic "OP" tokens:

token.LPAR
token.RPAR
token.LSQB
token.RSQB
token.COLON
token.COMMA
token.SEMI
token.PLUS
token.MINUS
token.STAR
token.SLASH
token.VBAR
token.AMPER
token.LESS
token.GREATER
token.EQUAL
token.DOT
token.PERCENT
token.BACKQUOTE
token.LBRACE
token.RBRACE
token.EQEQUAL
token.NOTEQUAL
token.LESSEQUAL
token.GREATEREQUAL
token.TILDE
token.CIRCUMFLEX
token.LEFTSHIFT
token.RIGHTSHIFT
token.DOUBLESTAR
token.PLUSEQUAL
token.MINEQUAL
token.STAREQUAL
token.SLASHEQUAL
token.PERCENTEQUAL
token.AMPEREQUAL
token.VBAREQUAL
token.CIRCUMFLEXEQUAL
token.LEFTSHIFTEQUAL
token.RIGHTSHIFTEQUAL
token.DOUBLESTAREQUAL?
token.DOUBLESLASH
token.DOUBLESLASHEQUAL
token.AT

However, I can't fault tokenize for deciding to treat all of those tokens the same way - for many source code manipulation purposes, these just need to be transcribed literally, and the "OP" token serves that purpose just fine.

As the extensive test updates in the current patch suggest, AMK is also correct that changing this away from always returning "OP" tokens (even for characters with more specialised tokens available) would be a backwards incompatible change.

I think there are two parts to this problem, one documentation related (affecting 2.7, 3.2, 3.3) and another that would be an actual change in 3.3:

1. First, I think 3.3 should add an "exact_type" attribute to TokenInfo instances (without making it part of the tuple-based API). For most tokens, this would be the same as "type", but for OP tokens, it would provide the appropriate more specific token ID.

2. Second, the tokenize module documentation should state *explicitly* which tokens it collapses down into the generic "OP" token, and explain how to use the "string" attribute to recover the more detailed information.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ncoghlan
stage:  -> needs patch
title: function generate_tokens at tokenize.py yields wrong token for colon -> Add new attribute to TokenInfo to report specific token IDs
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:00:33 2011
From: report at bugs.python.org (Achim Gaedke)
Date: Thu, 15 Dec 2011 02:00:33 +0000
Subject: [issue13551] pulldom doesn't populate DOM tree
In-Reply-To: <1323304899.35.0.878509919082.issue13551@psf.upfronthosting.co.za>
Message-ID: <1323914433.87.0.598176905606.issue13551@psf.upfronthosting.co.za>


Achim Gaedke <Achim.Gaedke at physik.tu-darmstadt.de> added the comment:

Potentially both: The xml.dom.pulldom documentation is not really there.

Maybe the PullDOM builds a partial tree, not caring about nested nodes. In contrast to SAX2DOM, which seems to fill the DOM tree completely.

I tried to figure out, what the programmer intended to do: Obviously SAX2DOM extends the behaviour of PullDOM.

The documentation (online V3.2, retrieved today) does state: "PullDOM allows building only selected portions of a Document Object Model representation"

Does that mean, one would derive a customized class from PullDOM, implement methods like SAX2DOM, but control the construction with conditions?

For example:

class MyDOM(PullDOM):
    def startElement(self, name, attrs):
        PullDOM.startElement(self, name, attrs)
        if name[:3]=="my_":
            curNode = self.elementStack[-1]
            parentNode = self.elementStack[-2]
            parentNode.appendChild(curNode)

When someone says "YEAH, MATE, ABSOLUTELY, YOU GOT IT!", I might be able fill some of the documentation gaps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13551>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:06:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Dec 2011 02:06:27 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323914787.82.0.905702258784.issue2134@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe that that list includes all symbols and symbol combinations that are syntactically significant in expressions. This is the generalized meaning of 'operator' that is being used. What do not appear are '#' which marks comments, '_' which is a name char, and '\' which escapes chars within strings. Other symbols within strings will also not be marked as OP tokens. The non-syntactic symbols '$' and '?' are also omitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:05:09 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 03:05:09 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1323918309.37.0.321397314522.issue13532@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

One reason to fix this bug:

People may develop code that calls sys.std{out,err}.write with the number 200.
like sys.stdout.write(200)
In IDLE the code works well but in Python from the command-line it fails to run.
Creating a bug in the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:16:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2011 03:16:53 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323919013.83.0.854406512576.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sure, but what does that have to do with anything? tokenize isn't a general purpose tokenizer, it's specifically for tokenizing Python source code.

The *problem* is that it doesn't currently fully tokenize everything, but doesn't explicitly say that in the module documentation.

Hence my proposed two-fold fix: document the current behaviour explicitly and also add a separate "exact_type" attribute for easy access to the detailed tokenization without doing your own string comparisons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:35:23 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 03:35:23 +0000
Subject: [issue13603] Add prime-related functions to Python
Message-ID: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

It would be nice to have prime-related and number theory functions in a new module or some existing module (like math).
like this:
>>> import prime
>>> prime.isprime(7)
True
>>> prime.isprime(35)
False
>>> prime.primerange(10,18)
(11,13,17)
>>> prime.isperfect(6) #Is 6 a perfect number (http://en.wikipedia.org/wiki/Perfect_number)
True
>>> prime.factorize(60)
{2:2,3:1,5:1} #2**2 * 3**1 * 5**1

----------
components: Library (Lib)
messages: 149492
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: Add prime-related functions to Python
type: enhancement
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/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:36:16 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 03:36:16 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323920176.15.0.247335779285.issue13603@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
title: Add prime-related functions to Python -> Add prime-related and number theory functions to Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:38:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 03:38:14 +0000
Subject: [issue12923] test_urllib fails in refleak mode
In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>
Message-ID: <1323920294.08.0.244175490159.issue12923@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I just noticed this problem as well.

I don't know the code well enough to determine if Brian's patch is the
right thing to do.  The documentation claims that maxtries is used to
put a limit on recursion: http://docs.python.org/dev/library/urllib.request.html#urllib.request.FancyURLopener.  
The way the code is written it is limiting recursion, but the recursion count
is *not* being reset when an exception is thrown from 'redirect_internal'.

I see why this is a problem with our test code.  'Lib/test/test_urllib.py' 
has the following helper function:

_urlopener = None
def urlopen(url, data=None, proxies=None):
    """urlopen(url [, data]) -> open file-like object"""
    global _urlopener
    if proxies is not None:
        opener = urllib.request.FancyURLopener(proxies=proxies)
    elif not _urlopener:
        opener = urllib.request.FancyURLopener()
        _urlopener = opener
    else:
        opener = _urlopener
    if data is None:
        return opener.open(url)
    else:
        return opener.open(url, data)

Notice that the 'FancyURLopener' instance is cached in a global variable.  
The fact that the same instance is used from run to run causes max tries to 
be overrun.  If resetting maxtries on the exception path isn't safe, then we
can just remove the caching from the tests.  The more I think about it, the
more Brian's patch seem correct, though.

Senthil, can you chime in?

----------
nosy: +meador.inge
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12923>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:51:52 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 03:51:52 +0000
Subject: [issue13571] Backup files support in IDLE
In-Reply-To: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>
Message-ID: <1323921112.43.0.325475501001.issue13571@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

I would be happy to help :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13571>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:59:38 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Dec 2011 03:59:38 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323921578.27.0.879864342404.issue13603@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

-1 in general. I think that's too domain specific to belong in stdlib.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:05:54 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 04:05:54 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323921954.7.0.482403370282.issue13603@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I agree with Benjamin about this being too domain specific for stdlib.  
Also, I don't really see a good argument as to why this functionality is 
useful.  -1 from me too.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:25:47 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 04:25:47 +0000
Subject: [issue13604] update PEP 393 (match implementation)
Message-ID: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

The implementation has a larger state.kind
Clarified wording on wstr_length and surrogate pairs.
Clarified that the canonical "data" format doesn't always have a data pointer.
Mentioned that calling PyUnicode_READY would finalize a string, so that it couldn't be resized.
Changed section head "Other macros" to "Finalization macro" and removed the non-existent PyUnicode_CONVERT_BYTES (there is a similarly named private macro).

----------
files: pep-0393.txt.patch
keywords: patch
messages: 149497
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: update PEP 393 (match implementation)
Added file: http://bugs.python.org/file23960/pep-0393.txt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:27:24 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 04:27:24 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323923244.34.0.184127257425.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.3
Added file: http://bugs.python.org/file23961/pep-0393.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:28:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 04:28:06 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <E1Rb2vM-0006dY-6e@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d2504d30f259 by Meador Inge in branch '3.2':
Issue #13591: import_module potentially imports a module twice.
http://hg.python.org/cpython/rev/d2504d30f259

New changeset e8fb61a0a2d7 by Meador Inge in branch 'default':
Issue #13591: import_module potentially imports a module twice.
http://hg.python.org/cpython/rev/e8fb61a0a2d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:30:15 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 04:30:15 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <1323923415.07.0.189906685601.issue13591@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the review Brett.  Fix committed.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:41:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 04:41:13 +0000
Subject: [issue13591] import_module potentially imports a module twice
In-Reply-To: <1323726204.09.0.608665838185.issue13591@psf.upfronthosting.co.za>
Message-ID: <E1Rb383-0008BS-Jd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 541f215a31f7 by Meador Inge in branch '3.2':
Issue #13591: Moving the NEWS line to the right release.
http://hg.python.org/cpython/rev/541f215a31f7

New changeset 92e94fd303d4 by Meador Inge in branch 'default':
Issue #13591: Moving the NEWS line to the right release.
http://hg.python.org/cpython/rev/92e94fd303d4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13591>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:55:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 04:55:08 +0000
Subject: [issue13593] importlib needs to be updated for __qualname__
In-Reply-To: <1323785296.62.0.631553026432.issue13593@psf.upfronthosting.co.za>
Message-ID: <E1Rb3LX-0001P0-3V@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 54a77c556d9a by Meador Inge in branch 'default':
Issue #13593: updating the importlib utility decorators for __qualname__.
http://hg.python.org/cpython/rev/54a77c556d9a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13593>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:56:09 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 04:56:09 +0000
Subject: [issue13593] importlib needs to be updated for __qualname__
In-Reply-To: <1323785296.62.0.631553026432.issue13593@psf.upfronthosting.co.za>
Message-ID: <1323924969.97.0.678971150578.issue13593@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Fix committed.  Thanks for the review Antoine and Brett.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13593>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:56:23 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 04:56:23 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323924983.55.0.00616619064499.issue13603@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

I think math.sin is also domain-specific.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:58:03 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Dec 2011 04:58:03 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323925083.14.0.357095409223.issue13603@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Hardly, being a widely applicable mathematical function. Also, it's in a C math library which is what Python's is originally based on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:00:49 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 05:00:49 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323925083.14.0.357095409223.issue13603@psf.upfronthosting.co.za>
Message-ID: <CAK1QoopUY3XZvU3ih0R==CLm20ttBgkrTnGpR+77RTC2+w6+mw@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Wed, Dec 14, 2011 at 10:58 PM, Benjamin Peterson
<report at bugs.python.org> wrote:

> Hardly, being a widely applicable mathematical function.

I was just typing a similar response.

> Also, it's in a C math library which is what Python's is originally based on.

Not just *a* C math library.  *The* Standard C library! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:01:31 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Dec 2011 05:01:31 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <CAK1QoopUY3XZvU3ih0R==CLm20ttBgkrTnGpR+77RTC2+w6+mw@mail.gmail.com>
Message-ID: <CAPZV6o9tz4Ft9sVUqp8Xc9unZvBY-oFWEvGk7oHu+2SZVikX+Q@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/12/15 Meador Inge <report at bugs.python.org>:
>
> Not just *a* C math library. ?*The* Standard C library! :-)

Quite!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:03:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Dec 2011 05:03:51 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323925431.99.0.243567390098.issue2134@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If you are responding to me, I am baffled. I gave a concise way to document the current behavior with respect to .OP, which you said you wanted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:05:02 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 05:05:02 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1322727070.74.0.529182027643.issue13097@psf.upfronthosting.co.za>
Message-ID: <CAK1QooqmjroiZ3ahWKs+YeEd+63BNj9gAkRc=LPDJ8TjqX3HbA@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Thu, Dec 1, 2011 at 2:11 AM, STINNER Victor <report at bugs.python.org> wrote:

> Is there really an use case where you need 2 ** 20 (1,048,576) arguments? If yes, I'm not against the torture in this case :-)

Not very likely :-)  However, the segfault can occur with less
arguments in low stack space situations (e.g. deep callstack).

> If no, why not raising an error if there are too many arguments? E.g. limit to 1,024 arguments or maybe just 10?

That is certainly an option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13097>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:25:31 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 05:25:31 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323926731.85.0.679625135448.issue13603@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Anybody else than Benjamin and Meador please comment on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:48:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2011 05:48:32 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323928112.43.0.498634176463.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, I didn't read it as suggested documentation at all - you moved seamlessly from personal commentary to a docs suggestion without separating the two, so it appeared to be a complete non sequitur to me.

As for the docs suggestion, I think it works as the explanation of which tokens are affected once the concept of the token stream simplification is introduced:
=====
To simplify token stream handling, all literal tokens (':', '{', etc) are returned using the generic 'OP' token type. This allows them to be simply handled using common code paths (e.g. for literal transcription directly from input to output). Specific tokens can be distinguished by checking the "string" attribute of OP tokens for a match with the expected character sequence.

The affected tokens are all symbols and symbol combinations that are syntactically significant in expressions (as listed in the token module). Anything which is not an independent token (i.e. '#' which marks comments, '_' which is just part of a name, '\' which is used for line continuations, the contents of string literals and any symbols which are not a defined part of Python's syntax) is completely unaffected by this difference in behaviour.
===========

If "exact_type" is introduced in 3.3, then the first paragraph can be adjusted accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:09:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 15 Dec 2011 07:09:33 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1323932973.7.0.563445719031.issue13402@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> sys.executable can be None on Jython (and I believe IronPython) when ran in an 'embedded' mode

In CPython, embedding doesn't change the behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:28:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 07:28:17 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323934097.3.0.554372822257.issue13603@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Anybody else than Benjamin and Meador please comment on this.

I don't know why we would want to maintain this in the stdlib. We would also need a dedicated maintainer so that efficient algorithms are chosen and implemented.

Such functions are available in PyCrypto by the way: https://www.dlitz.net/software/pycrypto/doc/#crypto-util-number

----------
nosy: +mark.dickinson, pitrou
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:30:14 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 15 Dec 2011 07:30:14 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323934214.21.0.532086993858.issue13603@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

I'll chip in my 2 cents as well and say this also seems too domain specific and not useful enough for the stdlib.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:39:05 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 07:39:05 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323934745.58.0.507136330791.issue13603@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

On further thought, I have changed my mind.
I think this is domain-specific.
Shall we close this bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:42:09 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 07:42:09 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323934929.87.0.939919093836.issue13598@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Why isn't anybody commiting or commenting on my patches?

----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:44:54 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 07:44:54 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323935094.03.0.995172098395.issue13598@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
status: languishing -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:05:03 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 15 Dec 2011 08:05:03 +0000
Subject: [issue13601] sys.stderr should be unbuffered (or always line-buffered)
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1323936303.14.0.444971177375.issue13601@psf.upfronthosting.co.za>


Changes by Geoffrey Bache <gjb1002 at users.sourceforge.net>:


----------
nosy: +gjb1002

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:13:19 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Dec 2011 08:13:19 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323936799.42.0.482013667376.issue13603@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Agree with the -1s.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:16:48 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 08:16:48 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323937008.9.0.0287337776428.issue13603@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:20:22 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Dec 2011 08:20:22 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1323937222.47.0.786493450743.issue1559549@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Just following up on this ticket.  Anyone have any objections to Brian's patch?

Also, would 'fullname' be more appropriate than 'name', to be more in sync with that identifier in importlib?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:24:59 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Dec 2011 08:24:59 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1323937499.92.0.278471386215.issue2377@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

AFAICT, #1559549 is the ImportError attribute ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:29:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Dec 2011 08:29:50 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323937790.21.0.169283165796.issue13603@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> rejected
status: languishing -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:03:43 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Thu, 15 Dec 2011 09:03:43 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323939823.33.0.572762232849.issue12149@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Mark, it's been a long time since I went through this bug and don't remember the details. Are you sure subtype_dealloc should not call PyType_Modified? It looked like the appropriate place at the time. In the example the reference cycle was introduced on purpose by the Python program. Maybe we can try and explore the reference graph again?

I understood while posting the patch that this would have impacted performance. But deallocation of a subtype is not something that happens a lot in most programs. An overall 4% looks huge though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:47:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 09:47:03 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1323942423.58.0.130130653653.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. Can someone take a look?

----------
Added file: http://bugs.python.org/file23962/oserror_new.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:57:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 09:57:50 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1323943070.05.0.565296591375.issue1559549@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch doesn't appear to have the necessary mechanics to pass the new arguments from the import machinery when an ImportError is raised, is this deliberate?

Also, I'm not sure why the new arguments are keyword-only.

----------
nosy: +pitrou
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:58:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 09:58:42 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323943122.01.0.606205197748.issue13604@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, loewis
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:03:10 2011
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 15 Dec 2011 10:03:10 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1323939823.33.0.572762232849.issue12149@psf.upfronthosting.co.za>
Message-ID: <4EE9C5DC.2040404@hotpy.org>


Mark Shannon <mark at hotpy.org> added the comment:

Absolutely. subtype_dealloc deals with deallocation of subtype 
*instances*, not the types themselves.

 > Maybe we can try and explore the reference graph again?
This sort of thing is one of the reasons that the cycle GC does not call 
any finalisers. Attempting to do finalisation during deallocation is 
asking for trouble, and it seems to be pervasive in CPython.
I'm surprised this sort of bug is not more common.

But subtype_dealloc deals with instances not classes, and deallocation 
of instances may happen many millions of times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:15:28 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 15 Dec 2011 10:15:28 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1323944128.51.0.430379669855.issue13598@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This bug is assigned to me. Sometimes it takes a while before a committer has time to review a bug and act on it. I can assure you that I will review this before the next release of Python.

Thank you for the bug report, and especially thanks for the patch!

One thing that will definitely need to be developed before this is committed is one or more tests. Either you can add them, or I will before I commit the fix. There are some existing tests for str.format that can be leveraged for string.Formatter.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:16:38 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:16:38 +0000
Subject: [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323944198.95.0.291707373871.issue13540@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Sorry about being out of contact (I'm flying back and forth between the US and the EU every 4-5 weeks right now), and thanks Terry for bringing this to my attention.

Essentially, the API is:

* The argument to action= must be a callable that accepts at least a "dest" and "option_strings" keyword arguments, and returns some object. The keyword arguments passed to this callable will be dest, option_strings, and whatever other keyword arguments were passed to add_argument().

* The object returned by the action= callable should have attributes "dest", "option_strings", "default", "type", "required", "help", etc. defined in essentially the same way as the add_argument() documentation.

* The object returned by the action= callable should itself be callable, and should accept the arguments (self, parser, namespace, values, option_string=None). This method can do whatever it wants, but as you note, the typical approach is to invoke setattr(namespace, self.dest, ...)

Now, all that said, the easiest way of creating a callable that returns an callable where both have the right signatures and the right attributes is to subclass argparse.Action. In fact, doing it any other way is probably crazy. I'm against changing the name of __call__ to invoke because it removes the possibility of defining an action as a function returning another function (which is currently possible), but I'm all for making the documentation strongly recommend subclassing argparse.Action. I would just say something like:

"You may also specify an arbitrary action by passing a subclass of :class:`argparse.Action`, or another callable object that implements the same interface."

I wouldn't bother to go into more detail about "implements the same interface" - all sane people will just subclass Action. ;-)

As to argparse.Action.__init__, hopefully the above bullet points make it clear that you must accept "dest" and "option_strings", but what other keyword arguments you want to accept are up to you. Be sure to call the superclass __init__ to set any attributes that you didn't accept to appropriate default values. A simple example of accepting an additional keyword argument is the _VersionAction, which accepts a "version" keyword argument that the other actions don't accept. The current "example of a custom action" should probably define __init__ to show how this works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13540>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:22:34 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:22:34 +0000
Subject: [issue13584] argparse doesn't respect double quotes
In-Reply-To: <1323644776.15.0.954128215296.issue13584@psf.upfronthosting.co.za>
Message-ID: <1323944554.43.0.11090378328.issue13584@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Can you submit some example code that shows this? I can't reproduce this with:

---------- temp.py ----------
import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--ng", action="store_true")
parser.add_argument("--INP")
print(parser.parse_args())
------------------------------

$ python temp.py --ng --INP="Demo IO"
Namespace(INP='Demo IO', ng=True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13584>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:47:30 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:47:30 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1323946050.49.0.0302398325776.issue12776@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Could you add a test to verify that custom actions are still getting the converted values passed to their __call__? I suspect this may not be happening under the current patch - if that's the case, you may also need to add conversions in _get_values, where the lines look like "value = action.default".

Also, "action.default == getattr(namespace, action.dest)" should probably use "is" instead of "==".

Other than that, the patch looks okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:49:35 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:49:35 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1323946175.68.0.00573172519504.issue10772@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good to me too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:51:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 10:51:05 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323946265.22.0.264319302928.issue12149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the writeup, Mark. Here is a patch, calling PyType_Modified in the type's (not the instance's) tp_clear.

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file23963/type_clear.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:56:44 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:56:44 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1323946604.5.0.632195866467.issue13249@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The ArgumentParser constructor is definitely only intended to be called with keyword arguments, so it's definitely a documentation bug that it doesn't say this. I haven't actually applied the patch, but the basic approach and wording look fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:01:57 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 11:01:57 +0000
Subject: [issue13271] When -h is used with argparse,
	default values that fail should not matter
In-Reply-To: <1319664352.05.0.511704738067.issue13271@psf.upfronthosting.co.za>
Message-ID: <1323946917.92.0.247399917775.issue13271@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I think http://bugs.python.org/issue12776, which delays type conversions on defaults should solve this problem, right? If you agree, could you add your code here as a test case to that issue and mark this as duplicate?

(And yes, I agree this is a bug.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13271>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:08:46 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 11:08:46 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1323947326.53.0.696243903181.issue13041@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'd feel more comfortable with the argparse fix if it were simply calling "os.get_terminal_size()". I recommend that you:

* Create a new issue called, say "add os.get_terminal_size()" proposing just the single method.

* Add that issue to the Dependencies of this issue.

Once that is fixed, then the argparse fix should be simple.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:22:14 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 11:22:14 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1323948134.49.0.793594429115.issue12806@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

As I understand it the current proposal is:

* Wrap each paragraph separately
* Don't wrap any lines indented by at least one additional space

This sounds like a useful formatter. I would probably call it "PargraphWrappingFormatter" or something like that which is more descriptive than FlexiFormatter.

Sadly, it can't be the default, since that would break backwards compatibility, but I'd certainly agree to an obvious note somewhere in the docs recommending the use of this formatter instead of the current default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:28:32 2011
From: report at bugs.python.org (Chromatix)
Date: Thu, 15 Dec 2011 11:28:32 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1323948512.73.0.937608967346.issue12082@psf.upfronthosting.co.za>


Changes by Chromatix <cpmicropro at gmail.com>:


----------
nosy: +chromatix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:31:13 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 11:31:13 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1323948673.28.0.294252152564.issue9253@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

If you can make your patch relative to the cpython source tree, and add a couple tests, it will be easier to review.

Thanks for working on this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:36:20 2011
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 15 Dec 2011 11:36:20 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323948980.89.0.483432108732.issue12149@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

What's happening is that the cycle GC calls type_clear to clear the type, but the method-cache is not invalidated.
I have added a call to PyType_Modified in type_clear (as well as type_set_name and type_set_qualname, which also modify the type).

Patch is attached.

----------
Added file: http://bugs.python.org/file23964/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:38:28 2011
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 15 Dec 2011 11:38:28 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323949108.4.0.250357237613.issue12149@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Beat me to it, Antoine!

Don't forget type_set_name and type_set_qualname.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 12:43:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 11:43:47 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1323948980.89.0.483432108732.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323949406.3345.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have added a call to PyType_Modified in type_clear (as well as
> type_set_name and type_set_qualname, which also modify the type).

Can __name__ and __qualname__ be looked up through the method cache?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:05:44 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:05:44 +0000
Subject: [issue13023] argparse should allow displaying argument default values
	in addition to setting a formatter class
In-Reply-To: <1316557707.22.0.0719652961871.issue13023@psf.upfronthosting.co.za>
Message-ID: <1323950744.91.0.106916648172.issue13023@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Your solution is actually the current recommended solution - mix together both classes that you want to combine and pass your subclass as the parameter. This should probably be documented somewhere (and tested more).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13023>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:06:19 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Thu, 15 Dec 2011 12:06:19 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323950779.07.0.0687959795276.issue12149@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

As much as I hate being wrong, I must concur with you. ;) Thank you, Mark.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:13:43 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2011 12:13:43 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1323951223.73.0.949486828541.issue1559549@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The keyword-only idea is a backwards compatibility hack we discussed at the PyCon US sprints because ImportError currently accepts an arbitrary number of arguments:

>>> raise ImportError(1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: (1, 2, 3)

We don't really want to be claiming that the module name is some strange value due to existing code that passes multiple arguments, hence the suggestion to make this a keyword-only argument.

Regarding import.c, I think Brian misinterpreted Brett's last message. import.c absolutely *should* be modified by this patch, since it's still the default import implementation for the moment. Brett's comment was just to say that *he* wasn't going to do that part, since his aim with the importlib bootstrapping exercise is to nuke most of import.c from orbit :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:13:50 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:13:50 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1323951230.4.0.750061957677.issue12713@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Modulo the comments already on the patch by others, this approach looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:19:31 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:19:31 +0000
Subject: [issue12686] argparse - document (and improve?) use of SUPPRESS with
	help=
In-Reply-To: <1312356221.08.0.599664751964.issue12686@psf.upfronthosting.co.za>
Message-ID: <1323951571.63.0.997818317045.issue12686@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Could you give some examples of bugs that you observed? Otherwise, this looks like a duplicate of issue 9349.

The intention is that help=SUPPRESS should cause the given argument to not be displayed in the help message. If there are cases where that's not true, then it's definitely a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12686>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:21:07 2011
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 15 Dec 2011 12:21:07 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1323949406.3345.0.camel@localhost.localdomain>
Message-ID: <4EE9E632.7010805@hotpy.org>


Mark Shannon <mark at hotpy.org> added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> I have added a call to PyType_Modified in type_clear (as well as
>> type_set_name and type_set_qualname, which also modify the type).
> 
> Can __name__ and __qualname__ be looked up through the method cache?

__name__ and __qualname__ are not looked up through the method cache,
but their descriptors could be.
Changing the descriptors would be caught elsewhere,
so there is no need to to add any PyType_Modified to
type_set_name and type_set_qualname.

However, calls to PyType_Modified will never cause any errors,
and if only used for genuine type modifications, will cause no 
discernible performance degradation.

Since PyType_Modified is generally called whenever a type is modified, 
it is likely to act as a guardian for any future optimisations that 
require classes to be unchanged.

Thus, given these two reasons, it seems wise to call PyType_Modified 
anywhere the type is modified, however minor that modification appears 
to be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:23:02 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:23:02 +0000
Subject: [issue11708] argparse: suggestion for formatting optional positional
	args
In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za>
Message-ID: <1323951782.28.0.289438385692.issue11708@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I agree that this is a bug in current argparse formatting.

It might be a little difficult to fix though because the current option formatting handles arguments one at a time, and producing something like [arg1 [arg2]] requires some understanding of how arguments interact, which the formatter currently doesn't have.

But patches are certainly welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11708>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:33:00 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:33:00 +0000
Subject: [issue12284] argparse.ArgumentParser: usage example option
In-Reply-To: <1307540382.34.0.477677451975.issue12284@psf.upfronthosting.co.za>
Message-ID: <1323952380.64.0.543574496137.issue12284@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

%(prog)s is available in epilog:

---------- temp.py ----------
import argparse

epilog = """\
Example usage:
  %(prog)s option1 option2
"""
parser = argparse.ArgumentParser(
    formatter_class=argparse.RawTextHelpFormatter,
    epilog=epilog)
parser.parse_args()
------------------------------
$ python temp.py -h
usage: temp.py [-h]

optional arguments:
  -h, --help  show this help message and exit

Example usage:
  temp.py option1 option2
------------------------------

Did you need more than that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12284>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:36:05 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:36:05 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1323952565.19.0.681928894785.issue9938@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:38:20 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:38:20 +0000
Subject: [issue11839] argparse: unexpected behavior of default for
	FileType('w')
In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za>
Message-ID: <1323952700.09.0.818334679746.issue11839@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I think Issue 12776, which delays type conversions on defaults, should solve this problem, right? If you agree, could you add your code here as a test case to that issue and mark this as duplicate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11839>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:42:30 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:42:30 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1323952950.85.0.872243468348.issue11874@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I agree this is a bug. The patch needs to add unit tests that make sure metavars with []?work as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:04:10 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 13:04:10 +0000
Subject: [issue11807] Documentation of add_subparsers lacks information about
	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1323954250.85.0.805684910473.issue11807@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good. A few minor comments (click "review" by the patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11807>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:06:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 13:06:38 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1323954398.28.0.256712640398.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch. I've renamed oserror_post_init to oserror_init. Also addressed Nick's other comments.

----------
Added file: http://bugs.python.org/file23965/oserror_new2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:11:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 13:11:36 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <4EE9E632.7010805@hotpy.org>
Message-ID: <1323954674.3345.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since PyType_Modified is generally called whenever a type is modified, 
> it is likely to act as a guardian for any future optimisations that 
> require classes to be unchanged.
> 
> Thus, given these two reasons, it seems wise to call PyType_Modified 
> anywhere the type is modified, however minor that modification appears 
> to be.

Well, unless we start reviewing all the places where a type might be
directly modified, I'm not sure there's much point in adding
PyType_Modified to those two.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:21:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 13:21:42 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <E1RbBFj-0004n1-6X@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b196bcd7c34f by Antoine Pitrou in branch '3.2':
Fix the fix for issue #12149: it was incorrect, although it had the side
http://hg.python.org/cpython/rev/b196bcd7c34f

New changeset 195bfd4c3ea1 by Antoine Pitrou in branch 'default':
Fix the fix for issue #12149: it was incorrect, although it had the side
http://hg.python.org/cpython/rev/195bfd4c3ea1

New changeset da1d7f8cd487 by Antoine Pitrou in branch '2.7':
Fix the fix for issue #12149: it was incorrect, although it had the side
http://hg.python.org/cpython/rev/da1d7f8cd487

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:28:30 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 13:28:30 +0000
Subject: [issue13605] document argparse's nargs=REMAINDER
Message-ID: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

There is an undocumented value for add_argument's nargs parameter, REMAINDER, which can be used to consume all the remaining arguments. This is commonly useful for command line utilities that dispatch to other command line utilities.

Though undocumented, it has been used successfully by at least a few different people:

http://stackoverflow.com/questions/5826881/how-to-use-argparse-to-collect-arguments-for-a-separate-command-line-without

http://code.google.com/p/argparse/issues/detail?id=52

And I just received an email from yet another user who used it successfully.

So I think it's time to graduate this from a hidden feature to a real documented one.

----------
assignee: docs at python
components: Documentation
messages: 149552
nosy: bethard, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: document argparse's nargs=REMAINDER
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13605>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:32:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 13:32:28 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1323955948.69.0.475814956655.issue12149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hopefully this is fixed for good now. Thank you!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:33:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 13:33:10 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <E1RbBQq-00068E-Mr@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d22c99e77768 by Antoine Pitrou in branch 'default':
Fix OSError.__init__ and OSError.__new__ so that each of them can be
http://hg.python.org/cpython/rev/d22c99e77768

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:34:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 13:34:42 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1323956082.18.0.79314913531.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:00:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Dec 2011 14:00:52 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1323957652.29.0.640111460598.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Amaury has asked for more comments (and I agree). However, I'm not sure what 
level of detail would be appropriate. As an example, I've posted the full
proof of the x87 modular multiplication in umodarith.h.


Even with the Coq parts stripped, this would still be a massive comment.


Would you prefer that level of detail or should I just post the core
of the algorithm?

----------
Added file: http://bugs.python.org/file23966/ppro-mulmod.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:03:28 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Dec 2011 14:03:28 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1323957652.29.0.640111460598.issue7652@psf.upfronthosting.co.za>
Message-ID: <20111215140327.GA5631@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Stefan Krah <report at bugs.python.org> wrote:
> Would you prefer that level of detail or should I just post the core
> of the algorithm?

Argh. s/post/add to comments in umodarith.h/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:03:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2011 14:03:43 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323957823.18.0.0570232959902.issue13604@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Various comments of the PEP 393 and your patch.

"For compatibility with existing APIs, several representations
may exist in parallel; over time, this compatibility should be phased
out."
and
"For compatibility, redundant representations may be computed."

I never understood this statement: in most cases, PyUnicode_READY() replaces the Py_UNICODE* (wchar_t*) representation by a compact representation.

PyUnicode_AsUnicode(), PyUnicode_AS_UNICODE(), PyUnicode_GET_SIZE(), ... do reallocate a Py_UNICODE* string for a ready string, but I don't think that it is a usual use case. 
PyUnicode_AS_UNICODE() & friends are usually only used to build strings. So this issue should be documented in a section different than the Abstract, maybe in a Limitations section.

So even if a third party module uses the legagy Unicode API, the PEP 393 will still optimize the memory usage thanks to implicit calls to PyUnicode_READY() (done everywhere in Python source code).

In the current code, the most common case where a string has two representations is the conversion to wchar_t* on Windows. PyUnicode_AsUnicode() is used to encode arguments for the Windows Unicode API, and PyUnicode_AsUnicode() keeps the result in the wstr attribute.

Note: there is also the utf8 attribute which may contain a third representation if PyUnicode_AsUTF8() or PyUnicode_AsUTF8AndSize() (or the old _PyUnicode_AsString()) is called.

"Objects for which the maximum character is not given at creation time are called "legacy" objects, created through PyUnicode_FromStringAndSize(NULL, length)."

They can also be created by PyUnicode_FromUnicode().

"Resizing a Unicode string remains possible until it is finalized, generally by calling PyUnicode_READY."

I changed PyUnicode_Resize(): it is now *always* possible to resize a string. The change was required because some decoders overallocate the string, and then resize after decoding the input.

The sentence can be simply removed.

+    + 000 => str is not initialized (data are in wstr)
+    + 001 => 1 byte (Latin-1)
+    + 010 => 2 byte (UCS-2)
+    + 100 => 4 byte (UCS-4)
+    + Other values are reserved at this time.

I don't like binary numbers, I would prefer decimal numbers here. Binary was maybe useful when we used bit masks, but we are now using the C "unsigned int field:bit_size;" trick for a nicer API. With the new values, it is even easier to remember them:

 1 byte <=> kind=1
 2 bytes <=> kind=2
 4 bytes <=> kind=4

"[PyUnicode_AsUTF8] is thus identical to the existing _PyUnicode_AsString, which is removed"

_PyUnicode_AsString() does still exist and is still heavily used (66 calls). It is not documented as deprecated in What's New in Python 3.3 (but it is a private function, so nobody uses it, right?.

"This section summarizes the API additions."

PyUnicode_IS_ASCII() is missing.

PyUnicode_CHARACTER_SIZE() has been removed (use kind directly).

UCS4 utility functions:

Py_UCS4_{strlen, strcpy, strcat, strncpy, strcmp, strncpy, strcmp, strncmp, strchr, strrchr} have been removed.


"The following functions are added to the stable ABI (PEP 384), as they
are independent of the actual representation of Unicode objects: ...
... PyUnicode_WriteChar ...."

PyUnicode_WriteChar() allows to modify an immutable object, which is something specific to CPython. Well, the function does now raise an error if the string is no more modifiable (e.g. more than 1 reference to the string, the hash has already been computed, etc.), but I don't know if it should be added to the stable ABI.

"PyUnicode_AsUnicodeAndSize"

This function was added to Python 3.3 and is directly deprecated. Why adding a function to deprecate it? PyUnicode_AsUnicode() and PyUnicode_GET_SIZE() were not enough?

"Deprecations, Removals, and Incompatibilities"

Missing: PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp


--

A very important point is not well explained: it is very important that a ("final") string is in its canonical representation. It means that a UCS2 string must contain at least a character bigger than U+00FF for example. Not only some optimizations rely on the canonical representation, but also some core methods of the Unicode type.

I tried to list all properties of Unicode objects in the definition of the PyASCIIbject structure. And I implemented checks in _PyUnicode_CheckConsistency(). This method is only available in debug mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:08:00 2011
From: report at bugs.python.org (Julian Berman)
Date: Thu, 15 Dec 2011 14:08:00 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1323958080.48.0.340324851782.issue7897@psf.upfronthosting.co.za>


Changes by Julian Berman <Julian+Python.org at GrayVines.com>:


----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:12:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 14:12:25 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1323957652.29.0.640111460598.issue7652@psf.upfronthosting.co.za>
Message-ID: <1323958323.3345.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Amaury has asked for more comments (and I agree). However, I'm not sure what 
> level of detail would be appropriate. As an example, I've posted the full
> proof of the x87 modular multiplication in umodarith.h.
> 
> 
> Even with the Coq parts stripped, this would still be a massive comment.

You could ship it as a separate .txt file (like we have e.g.
Objects/dict_notes.txt).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:13:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 14:13:05 +0000
Subject: [issue13594] Aifc markers write fix
In-Reply-To: <1323803286.63.0.487230833708.issue13594@psf.upfronthosting.co.za>
Message-ID: <1323958385.6.0.914165470348.issue13594@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13594>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:27:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 14:27:01 +0000
Subject: [issue13601] sys.stderr should be unbuffered (or always line-buffered)
In-Reply-To: <1323876594.8.0.471569022136.issue13601@psf.upfronthosting.co.za>
Message-ID: <1323959199.3345.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Line-buffering should be good enough since in practice errors messages
> are always terminated by a newline.

What I think too.

> I'm hesitant to make it line-buffered by default when directed to a
> file, since this could significantly slow down a program that for some
> reason produces super-voluminous output (e.g. when running a program
> with heavy debug logging turned on).

The slow-down is impressive in relative terms (6x) but the timings are
still small in absolute value:

$ ./python -m timeit -s "f=open('/dev/null', 'a', buffering=4096)" "f.write('log message\n')"
10000000 loops, best of 3: 0.156 usec per loop
$ ./python -m timeit -s "f=open('/dev/null', 'a', buffering=1)" "f.write('log message\n')"
1000000 loops, best of 3: 0.961 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:30:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 14:30:32 +0000
Subject: [issue13601] sys.stderr should be unbuffered (or always line-buffered)
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1323959432.22.0.772133479041.issue13601@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, I forgot the last two questions:

> Maybe we need better command-line control to override the defaults?

We already have -u to switch all stdio to unbuffered. This issue proposes to make stderr line-buffered/unbuffered by default, since it's less surprising than fully buffered.

> Are there precedents e.g. in Bash flags?

Well, `man bash` doesn't appear to say anything about stdio buffering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:31:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Dec 2011 14:31:39 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323959499.94.0.177188082865.issue13592@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If an eval-able re.Regex is used, the flags can be showed as second arg, like:
  re.Regex('a', re.I|re.S)
instead of being added to the pattern as in
  re.Regex('(?is)a')

The repr can be generated with something like
  're.Regex({r.pattern!r}, {r.flags})'.format(r=r)
that currently prints
  re.Regex('abc', 50)
but if #11957 is fixed, the result will look like
  re.Regex('abc', re.I|re.S)
for a regex created with
  r = re.compile('abc', re.I|re.S)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:42:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Dec 2011 14:42:17 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1323960137.65.0.107998541239.issue7502@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/issue7502>
_______________________________________

From report at bugs.python.org  Thu Dec 15 16:26:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 15:26:32 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <E1RbDCY-00015J-Ut@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 313fa7ea6c79 by Antoine Pitrou in branch '3.2':
Issue #13597: Improve documentation of standard streams.
http://hg.python.org/cpython/rev/313fa7ea6c79

New changeset 7343730185a3 by Antoine Pitrou in branch 'default':
Issue #13597: Improve documentation of standard streams.
http://hg.python.org/cpython/rev/7343730185a3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Thu Dec 15 16:27:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 15:27:55 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323962875.37.0.795666701273.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be ok now.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:03:45 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 15 Dec 2011 17:03:45 +0000
Subject: [issue13571] Backup files support in IDLE
In-Reply-To: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>
Message-ID: <1323968625.16.0.459946699002.issue13571@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Let's move this discussion to the IDLE-dev mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13571>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:18:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Dec 2011 17:18:39 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1323969519.9.0.550497942057.issue2292@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:20:10 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Dec 2011 17:20:10 +0000
Subject: [issue5131] pprint doesn't know how to print a defaultdict
In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
Message-ID: <1323969610.82.0.780917719072.issue5131@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/issue5131>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:20:29 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Dec 2011 17:20:29 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1323969629.74.0.765899118735.issue7434@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/issue7434>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:20:33 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Dec 2011 17:20:33 +0000
Subject: [issue13004] pprint: add option to truncate sequences
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1323969633.68.0.0761947426205.issue13004@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/issue13004>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:20:36 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Dec 2011 17:20:36 +0000
Subject: [issue6743] Add function compatible with print to pprint module
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1323969636.77.0.217902541291.issue6743@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/issue6743>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:20:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Dec 2011 17:20:44 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1323969644.96.0.541980827181.issue10592@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/issue10592>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:20:53 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Dec 2011 17:20:53 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1323969653.12.0.0151346134046.issue10017@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/issue10017>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:26:54 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 17:26:54 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323934929.87.0.939919093836.issue13598@psf.upfronthosting.co.za>
Message-ID: <CAK1QoopOQCVz6FWY9w05uvuuJqoFDe7nYExv5z9SfRt24R9Cqw@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Thu, Dec 15, 2011 at 1:42 AM, maniram maniram <report at bugs.python.org> wrote:

> Why isn't anybody commiting or commenting on my patches?

Your patch is much appreciated.  Thank you.  It takes some time to get
things reviewed.  Please read the Dev Guide.  In particular, the
"Lifecycle of a Patch"
section: http://docs.python.org/devguide/patch.html.

Also, please quit marking issues as "languishing" unless the issue meets the
qualifications spelled out here:
http://docs.python.org/devguide/languishing.html.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:33:09 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Dec 2011 17:33:09 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1323957652.29.0.640111460598.issue7652@psf.upfronthosting.co.za>
Message-ID: <CAGmFidbNPbRYFbfu68=GNahghObaP4dpp3erEQ-CfhSNA1L1cA@mail.gmail.com>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

2011/12/15 Stefan Krah <report at bugs.python.org>

>
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
>
> Amaury has asked for more comments (and I agree). However, I'm not sure
> what
> level of detail would be appropriate. As an example, I've posted the full
> proof of the x87 modular multiplication in umodarith.h.
>
>
> Even with the Coq parts stripped, this would still be a massive comment.
>
>
> Would you prefer that level of detail or should I just post the core
> of the algorithm?
>

For my part, a two-lines description of the purpose of file is enough.
Something like
"Routines for the reverse transmogrification of randomized digits,
used in multiplication of numbers above 2**32 bits"
Or something else that makes sense :-)

At least something that makes it clear that I don't have to read further if
I'm only interested in the definition of Python classes for example.

----------
nosy: +Amaury.Forgeot.d'Arc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Dec 15 19:42:53 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 18:42:53 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323974573.34.0.0458116602162.issue2134@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:08:01 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Dec 2011 19:08:01 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1323976081.22.0.142188509242.issue11957@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:08:20 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Dec 2011 19:08:20 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1323976100.66.0.542275758452.issue13592@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:09:38 2011
From: report at bugs.python.org (Darren Dale)
Date: Thu, 15 Dec 2011 19:09:38 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1323976178.27.0.50348202045.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Is this patch ready to go? I haven't heard any feedback on the most recent version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:22:21 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Dec 2011 19:22:21 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323976941.45.0.34536367632.issue2134@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:26:53 2011
From: report at bugs.python.org (John Nagle)
Date: Thu, 15 Dec 2011 19:26:53 +0000
Subject: [issue11900] 2.7.1 unicode subclasses not calling __str__() for print
	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1323977213.36.0.570939207833.issue11900@psf.upfronthosting.co.za>


John Nagle <nagle at users.sourceforge.net> added the comment:

This has nothing to do with Python 3.  There's a difference in __str__ handling between Python 2.6 and Python 2.7.2.  It's enough to crash BeautifulSoup:

[Thread-8] Unexpected EXCEPTION while processing page "http://www.verisign.com": global name '__str__' is not defined
[Thread-8] Traceback (most recent call last):
...
[Thread-8]   File "C:\projects\sitetruth\BeautifulSoup.py", line 646, in prettify
[Thread-8]     return self.__str__(encoding, True)
[Thread-8]   File "C:\projects\sitetruth\BeautifulSoup.py", line 621, in __str__
[Thread-8]     contents = self.renderContents(encoding, prettyPrint, indentContents)
[Thread-8]   File "C:\projects\sitetruth\BeautifulSoup.py", line 656, in renderContents
[Thread-8]     text = c.__str__(encoding)
[Thread-8]   File "C:\projects\sitetruth\BeautifulSoup.py", line 415, in __str__
[Thread-8]     return "<!--%s-->" % NavigableString.__str__(self, encoding)
[Thread-8]   File "C:\projects\sitetruth\BeautifulSoup.py", line 393, in __unicode__
[Thread-8]     return __str__(self, None)
[Thread-8] NameError: global name '__str__' is not defined

The class method that's failing is simply

class NavigableString(unicode, PageElement):
...
    def __unicode__(self):
        return __str__(self, None)   #### EXCEPTION RAISED HERE ####

    def __str__(self, encoding=DEFAULT_OUTPUT_ENCODING):
        if encoding:
            return self.encode(encoding)
        else:
            return self

Using __str__ in the global namespace is probably wrong, and in a later version of BeautifulSoup, that code is changed to

    def __unicode__(self):
        return str(self).decode(DEFAULT_OUTPUT_ENCODING)

which seems to work.  However, it is a real change from 2.6 to 2.7 that breaks code.

----------
nosy: +nagle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11900>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:34:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 20:34:11 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <E1RbI0H-0005Im-Vw@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e979b26a9172 by Benjamin Peterson in branch 'default':
improve abstract property support (closes #11610)
http://hg.python.org/cpython/rev/e979b26a9172

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:40:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 20:40:41 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <E1RbI6Z-00067v-9p@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5ec7ecf62c1d by Victor Stinner in branch '3.2':
Issue #13545: Fix platform.libc_version() is the SO version is missing
http://hg.python.org/cpython/rev/5ec7ecf62c1d

New changeset a9ee21ac0879 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13545: Fix platform.libc_version() is the SO version is missing
http://hg.python.org/cpython/rev/a9ee21ac0879

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13545>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:42:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2011 20:42:31 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <1323981751.55.0.067094394761.issue13545@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch in msg<148968> solves the issue for me.

Cool, I applied the patch to Python 3.2 and 3.3.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13545>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:44:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 20:44:01 +0000
Subject: [issue13545] Pydoc3.2: TypeError: unorderable types
In-Reply-To: <1323245650.84.0.0982873930807.issue13545@psf.upfronthosting.co.za>
Message-ID: <E1RbI9o-0006NO-86@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f2a5dcced66d by Victor Stinner in branch '2.7':
Issue #13545: Fix platform.libc_version() is the SO version is missing
http://hg.python.org/cpython/rev/f2a5dcced66d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13545>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:46:33 2011
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 15 Dec 2011 20:46:33 +0000
Subject: [issue13606] test_clear_dict_in_ref_cycle in test_module only works
	by coincidence
Message-ID: <1323981993.25.0.0624214650154.issue13606@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

test_clear_dict_in_ref_cycle in test_module only works by coincidence,
if the name of the variable on line 77 is changed from 'a' to 'x', then the test fails.
This is a result of the arbitrary ordering of removals of values from a modules globals() during GC. 
Patch which passes in list, rather than using a global is attached.

----------
components: Tests
files: test_module.patch
keywords: patch
messages: 149574
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: test_clear_dict_in_ref_cycle in test_module only works by coincidence
type: behavior
Added file: http://bugs.python.org/file23967/test_module.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13606>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:47:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 20:47:10 +0000
Subject: [issue13596] Only recompile Lib/_sysconfigdata.py when needed
In-Reply-To: <1323805264.0.0.131711939459.issue13596@psf.upfronthosting.co.za>
Message-ID: <E1RbICr-0006gf-8g@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 06d83098d9a9 by Victor Stinner in branch 'default':
Close #13596: Only recompile Lib/_sysconfigdata.py when needed
http://hg.python.org/cpython/rev/06d83098d9a9

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13596>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:48:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 20:48:27 +0000
Subject: [issue13606] test_clear_dict_in_ref_cycle in test_module only works
	by coincidence
In-Reply-To: <1323981993.25.0.0624214650154.issue13606@psf.upfronthosting.co.za>
Message-ID: <1323982107.62.0.346319341431.issue13606@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson
stage:  -> patch review
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13606>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:57:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 20:57:53 +0000
Subject: [issue13606] test_clear_dict_in_ref_cycle in test_module only works
	by coincidence
In-Reply-To: <1323981993.25.0.0624214650154.issue13606@psf.upfronthosting.co.za>
Message-ID: <E1RbIND-0007UD-PV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c9ae0eb66959 by Benjamin Peterson in branch 'default':
fix this test to actually test something (closes #13606)
http://hg.python.org/cpython/rev/c9ae0eb66959

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13606>
_______________________________________

From report at bugs.python.org  Thu Dec 15 22:15:33 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 21:15:33 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323983733.86.0.601307259645.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


Added file: http://bugs.python.org/file23968/pep-0393.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 22:20:48 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 21:20:48 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323984048.71.0.813354803625.issue13604@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Updated to resolve most of Victor's concerns, but this meant enough changes that I'm not sure it quite counts as editorial only.

A few questions that I couldn't answer:

(1)  Upon string creation, do we want to *promise* to discard the UTF-8 and wstr, so that the caller can memory manage?

(2)  PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp seemed to be there in the code I was looking at.

(3)  I can't justify the born-deprecated function "PyUnicode_AsUnicodeAndSize".  Perhaps rename it with a leading underscore?  Though I'm not sure it is really needed at all.

(4)  I tried to reword the "for compatibility" ... "redundant" part ... but I'm not sure I resolved it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 23:02:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Dec 2011 22:02:11 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323986531.89.0.79873254354.issue2134@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Both the proposed text and 3.3 addition look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 23:18:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Dec 2011 22:18:25 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323987505.23.0.06739091553.issue2134@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/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 23:45:27 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Dec 2011 22:45:27 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323957823.18.0.0570232959902.issue13604@psf.upfronthosting.co.za>
Message-ID: <4EEA7885.2070206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> PyUnicode_AsUnicode(), PyUnicode_AS_UNICODE(), PyUnicode_GET_SIZE(),
> ... do reallocate a Py_UNICODE* string for a ready string, but I
> don't think that it is a usual use case.

Define "usual". There were certainly plenty of occurrences of that
in the Python code base, and I believe that extension modules also
use it, provided they care about the content of string objects at all.

> PyUnicode_AS_UNICODE() &
> friends are usually only used to build strings.

No. They are also used to inspect them.

> So even if a third party module uses the legagy Unicode API, the PEP
> 393 will still optimize the memory usage thanks to implicit calls to
> PyUnicode_READY() (done everywhere in Python source code).

... unless they inspect a given Unicode string, in which case it
will use twice the memory (or 1.5x).

> "Resizing a Unicode string remains possible until it is finalized,
> generally by calling PyUnicode_READY."
> 
> I changed PyUnicode_Resize(): it is now *always* possible to resize a
> string. The change was required because some decoders overallocate
> the string, and then resize after decoding the input.
> 
> The sentence can be simply removed.

Well, I meant the resizing of strings that doesn't move the object
in memory (i.e. unicode_resize). You (apparently) changed its signature
to take PyUnicode_Object** (instead of PyUnicode_Object*). It's probably
irrelevant since that's a unicodeobject.c-internal function, anyway.

> "PyUnicode_AsUnicodeAndSize"
> 
> This function was added to Python 3.3 and is directly deprecated. Why
> adding a function to deprecate it? PyUnicode_AsUnicode() and
> PyUnicode_GET_SIZE() were not enough?

If it was not in 3.2, we should certainly remove it right away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 23:50:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Dec 2011 22:50:05 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323984048.71.0.813354803625.issue13604@psf.upfronthosting.co.za>
Message-ID: <4EEA799B.7080009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> (1)  Upon string creation, do we want to *promise* to discard the UTF-8 and wstr, so that the caller can memory manage?

I don't understand the question. Assuming "discards" means "releases"
here, then there is no API which releases memory during creation of
the string object - let alone that there is any promise to do so. I'm
also not aware of any candidate buffer that you might want to release.

> (2)  PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp seemed to be there in the code I was looking at.

That's very well possible. What's the question?

> (3)  I can't justify the born-deprecated function "PyUnicode_AsUnicodeAndSize".  Perhaps rename it with a leading underscore?  Though I'm not sure it is really needed at all.

Nobody noticed that it is born-deprecated. If it really is, it should be
removed before the release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Thu Dec 15 23:52:11 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Dec 2011 22:52:11 +0000
Subject: [issue13603] Add prime-related and number theory functions to Python
In-Reply-To: <1323920122.96.0.499037580838.issue13603@psf.upfronthosting.co.za>
Message-ID: <1323989531.01.0.456860412211.issue13603@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

maniram: the proper course is to publish such a module on PyPI. Then, if there is enough interest in it (after a few years), propose addition to the standard library.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13603>
_______________________________________

From report at bugs.python.org  Fri Dec 16 00:16:07 2011
From: report at bugs.python.org (Paul Moore)
Date: Thu, 15 Dec 2011 23:16:07 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1323990967.13.0.957624610725.issue2292@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:01:54 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 16 Dec 2011 00:01:54 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <1323993714.46.0.195083989531.issue13575@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Is mro_internal's second call to type_mro_modified still needed? Its comment makes me suspect that it's not:

    type_mro_modified(type, type->tp_mro);
    /* corner case: the old-style super class might have been hidden
       from the custom MRO */
    type_mro_modified(type, type->tp_bases);

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:02:55 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 16 Dec 2011 00:02:55 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
Message-ID: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>


New submission from Ron Adam <ron3200 at gmail.com>:

The following changes cleanup the eval loop and result in a pretty solid 2 to 3% improvement in pybench for me.

And it is about 5% faster for long generators.

* Change why enum type to int and #defines.  And moved the why defines to opcode.h so that they can be seen by the genrator objects after a yield, return, or exception.

* Added an "int f_why" to frames so the generator can see why it returned from a send.

* Refactored generator obj so it can use the "f->f_why" to determine what to do without having to do several checks first.

* Moved the generator specific execption save/swap/and clear out of the cevel main loop.  No need to check for those on every function call.


The only test that fails is the frame size is test_sys.  I left that in for now so someone could check that, and tell me if it's ok to fix it, or if I need to do something else.

I also considered putting the why on the tstate object.  It might save some memory as there wouldn't be as many of those.

----------
components: Interpreter Core
files: f_why.diff
keywords: patch
messages: 149583
nosy: ron_adam
priority: normal
severity: normal
status: open
title: Move generator specific sections out of ceval.
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23969/f_why.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:34:30 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 00:34:30 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323995670.92.0.499848201076.issue13604@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

>> So even if a third party module uses the legagy Unicode API, the PEP
>> 393 will still optimize the memory usage thanks to implicit calls to
>> PyUnicode_READY() (done everywhere in Python source code).

> ... unless they inspect a given Unicode string, in which case it
> will use twice the memory (or 1.5x).

Why is the utf-8 representation not cached when it is generated for ParseTuple et alia?

It seems like these parameters are likely to either be re-used as parameters (in which case caching makes sense) or not re-used at all (in which case, the whole string can go away).

> Well, I meant the resizing of strings that doesn't move the object
> in memory (i.e. unicode_resize).

This may easily fail because the new size can't be found at that location; wouldn't it be better to just encourage proper sizing in the first place?

>> (1)  Upon string creation, do we want to *promise* to discard
>> the UTF-8 and wstr, so that the caller can memory manage?

> I don't understand the question. Assuming "discards" means
> "releases" here, then there is no API which releases memory
> during creation of the string object - let alone that there is
> any promise to do so. I'm also not aware of any candidate buffer
> that you might want to release.

When a string is created from a wchar_t array, who is responsible for releasing the original wchar_t array?  As I read it now, Python doesn't release the buffer, and the caller can't because maybe Python just pointed to it as memory shared with the canonical representation.  

>> (2)  PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp 
>> seemed to be there in the code I was looking at.

> That's very well possible. What's the question?

Victor listed them as missing.  I now suspect he meant "missing from the PEP list of deprecated functions and macros", and I just misunderstood.

----------
Added file: http://bugs.python.org/file23970/pep-0393.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:34:35 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Fri, 16 Dec 2011 00:34:35 +0000
Subject: [issue9399] Provide a 'print' action for argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1323995675.59.0.278583343659.issue9399@psf.upfronthosting.co.za>


Changes by Denilson Figueiredo de S? <denilsonsa at gmail.com>:


----------
nosy: +denilsonsa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9399>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:38:51 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 00:38:51 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323995931.18.0.652005622573.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


Added file: http://bugs.python.org/file23971/pep-0393v20111215.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:52:05 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 16 Dec 2011 00:52:05 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1323996725.61.0.226019664839.issue2292@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:55:50 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 00:55:50 +0000
Subject: [issue13608] remove born-deprecated PyUnicode_AsUnicodeAndSize
Message-ID: <1323996950.0.0.0916946145672.issue13608@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

In reviewing issue 13604 (aligning PEP 393 with the implementation) Victor Stinner noticed that PyUnicode_AsUnicodeAndSize is new in 3.3, but that it is already deprecated (because it relies on the old PyUnicode type).  

This born-deprecated function is just a shortcut for PyUnicode_AsUnicode plus PyUnicode_GET_SIZE, and should be removed.

----------
components: Unicode
messages: 149585
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: remove born-deprecated PyUnicode_AsUnicodeAndSize
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13608>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:01:39 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Fri, 16 Dec 2011 01:01:39 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
Message-ID: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>


New submission from Denilson Figueiredo de S? <denilsonsa at gmail.com>:

Please add a function called "os.get_terminal_size()" that should return a tuple "(width, height)".

The built-in "argparse" module would directly benefit from this function, as it would wrap the help text correctly. I'm pretty sure many users would also benefit from it.

Once this function gets implemented, issue #13041 can be trivially fixed. There are some suggestions about how to implement this feature in issue #8408.

[extra feature:] After this function gets implemented, it might be a good idea to implement some kind of API to detect size changes without requiring probing. (or, at least, the documentation should give some directions about how to achieve it)

----------
components: Library (Lib)
messages: 149586
nosy: denilsonsa
priority: normal
severity: normal
status: open
title: Add "os.get_terminal_size()" function
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:05:44 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Fri, 16 Dec 2011 01:05:44 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1323997544.54.0.219150519861.issue13041@psf.upfronthosting.co.za>


Denilson Figueiredo de S? <denilsonsa at gmail.com> added the comment:

Issue #13609 created, but I don't have permission to edit the dependencies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:27:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2011 01:27:10 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1323998830.04.0.315085986531.issue2292@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the python-ideas thread "list / array comprehensions extension"
Guido replied in reference to an earlier quote from him:
"I think that -0 was contextual (too many moving parts for the original Py3k release). Today I am +1."

There are others in favor, pending a PEP that specifies all the details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:28:00 2011
From: report at bugs.python.org (Phillip M. Feldman)
Date: Fri, 16 Dec 2011 01:28:00 +0000
Subject: [issue13584] argparse doesn't respect double quotes
In-Reply-To: <1323944554.43.0.11090378328.issue13584@psf.upfronthosting.co.za>
Message-ID: <CAB2ViTbgxJ8pYzXoO4WWTHJOeGbjKRzjYdTH5QToKg2X8q_SoQ@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

Hello Steven,

I'm embarrassed to report that I can't reproduce the problem.  The
input line is parsed correctly if I enclose the string 'Demo IO' in
double quotes.  It is parsed incorrectly if I enclose it in single
quotes, but it looks as though this is the fault of the Windows shell,
and not Python.

My apologies.

Phillip

On Thu, Dec 15, 2011 at 2:22 AM, Steven Bethard <report at bugs.python.org> wrote:
>
> Steven Bethard <steven.bethard at gmail.com> added the comment:
>
> Can you submit some example code that shows this? I can't reproduce this with:
>
> ---------- temp.py ----------
> import argparse
>
> parser = argparse.ArgumentParser()
> parser.add_argument("--ng", action="store_true")
> parser.add_argument("--INP")
> print(parser.parse_args())
> ------------------------------
>
> $ python temp.py --ng --INP="Demo IO"
> Namespace(INP='Demo IO', ng=True)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13584>
> _______________________________________

----------
nosy: +Phillip.M.Feldman at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13584>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:37:01 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Dec 2011 01:37:01 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1323999421.55.0.155015946828.issue12014@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:20:56 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 16 Dec 2011 02:20:56 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1324002056.87.0.224593364579.issue12776@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

> Could you add  a test to verify that custom  actions are still getting
> the converted values passed to their  __call__? I suspect this may not
> be happening  under the current  patch - if  that's the case,  you may
> also need to add conversions in _get_values, where the lines look like
> "value = action.default".

There seems to be already a test for that, namely TestActionUserDefined,
which use type=float  and type=int.  The value is  properly converted to
{int,float} when passed to __call__().  Just in case, I also tested with
a  'type' function  I defined  myself (which  only returns  float()) for
OptionalAction and it's working fine.

> Also,  "action.default  ==   getattr(namespace,  action.dest)"  should
> probably use "is" instead of "==".

Good point, it would be much better.  Thanks for the advice. I have just
modified the patch with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:24:04 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 16 Dec 2011 02:24:04 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1324002244.89.0.6230009115.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Added file: http://bugs.python.org/file23972/py2.7-argparse-call-type-function-once-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:24:29 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 16 Dec 2011 02:24:29 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1324002269.13.0.146979797555.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Added file: http://bugs.python.org/file23973/py3k-argparse-call-type-function-once-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Fri Dec 16 04:48:33 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 16 Dec 2011 03:48:33 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324007313.02.0.0091384336258.issue13607@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

A simple test to show the difference.

BEFORE:

$ python3 -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(10))"
100000 loops, best of 3: 3.87 usec per loop
$ python3 -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(1000000))"
10 loops, best of 3: 186 msec per loop

AFTER:
$ ./python -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(10))"
100000 loops, best of 3: 3.81 usec per loop
$ ./python -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(1000000))"
10 loops, best of 3: 168 msec per loop

                       before   after
y(10)         usec's   3.87    3.81     - 1.55%   
y(1000000)    msec's   186     168      - 9.67%

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Fri Dec 16 06:15:45 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 16 Dec 2011 05:15:45 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1324012545.54.0.366780148811.issue1559549@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'm guessing that more than just Python/import.c should be updated, and more than one spot in import.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Dec 16 06:20:45 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 16 Dec 2011 05:20:45 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1324012845.2.0.361413666377.issue1559549@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

If I add back in the import.c change, would this then be alright?

Eric - fullname seems fine, I'll update that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Dec 16 06:22:39 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 16 Dec 2011 05:22:39 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1324012959.22.0.923724361481.issue12082@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Fri Dec 16 06:41:31 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Dec 2011 05:41:31 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323995670.92.0.499848201076.issue13604@psf.upfronthosting.co.za>
Message-ID: <4EEADA09.7080405@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Why is the utf-8 representation not cached when it is generated for
> ParseTuple et alia?

It is.

> When a string is created from a wchar_t array, who is responsible for
> releasing the original wchar_t array?

The caller.

> As I read it now, Python
> doesn't release the buffer, and the caller can't because maybe Python
> just pointed to it as memory shared with the canonical
> representation.

But Python won't; it will always make a copy for itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Fri Dec 16 07:51:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 06:51:15 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324018275.21.0.946601218931.issue13607@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson, ncoghlan
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Fri Dec 16 07:53:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 06:53:05 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324018385.84.0.959146475577.issue13609@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, do you want to propose a patch yourself?
See http://docs.python.org/devguide/ for how to contribute a patch.

----------
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 08:27:21 2011
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 16 Dec 2011 07:27:21 +0000
Subject: [issue13610] On Python parsing numbers.
Message-ID: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

Can this be fixed? As far as I can remember (ver. 1.5.6),
it has always existed. Python does not crash, I find it
inelegant. Should it not be a SyntaxError?

Side effect. Searching for keywords, (eg. with re, "\b") may
practically always implies to handle this case separately.

Python all versions.

>>> 1and 0
0
>>> 1or 0
1
>>> 9if True else 22
9
>>> 0.1234if True else 22
0.1234
>>> [999for i in range(3)]
[999, 999, 999]

----------
components: Interpreter Core
messages: 149596
nosy: Jean-Michel.Fauth
priority: normal
severity: normal
status: open
title: On Python parsing numbers.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Fri Dec 16 08:31:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 07:31:52 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324020712.48.0.761203497665.issue13610@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/issue13610>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:14:55 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Fri, 16 Dec 2011 08:14:55 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324023295.72.0.259710679295.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

The patch is already almost there (in #13041). I'll post an updated version here in a moment.

----------
nosy: +zbysz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:17:41 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 16 Dec 2011 08:17:41 +0000
Subject: [issue13611] Integrate ElementC14N module into xml.etree package
Message-ID: <1324023461.04.0.625039310668.issue13611@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

The ElementC14N.py module by Fredrik Lundh implements XML canonicalisation for the ElementTree serialiser. Given that the required API hooks to use it are already in xml.etree.ElementTree, this would make a nice, simple and straight forward addition to the existing xml.etree package.

The source can be found here (unchanged since at least 2009):

https://bitbucket.org/effbot/et-2009-provolone/src/tip/elementtree/elementtree/ElementC14N.py

Note that the source needs some minor modifications to use relative imports at the top. Also, the "2.3 compatibility" code section can be dropped.

----------
components: Library (Lib), XML
messages: 149598
nosy: scoder
priority: normal
severity: normal
status: open
title: Integrate ElementC14N module into xml.etree package
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13611>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:24:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 08:24:54 +0000
Subject: [issue13611] Integrate ElementC14N module into xml.etree package
In-Reply-To: <1324023461.04.0.625039310668.issue13611@psf.upfronthosting.co.za>
Message-ID: <1324023894.53.0.927206077581.issue13611@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13611>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:28:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 16 Dec 2011 08:28:02 +0000
Subject: [issue11900] 2.7.1 unicode subclasses not calling __str__() for print
	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1324024082.89.0.228486999285.issue11900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> However, it is a real change from 2.6 to 2.7 that breaks code.

John, this issue is not the same as the one above.  The difference between Python 2.6 and Python 2.7.2 you mention only applies to % formatting.
The change is clearly documented in http://docs.python.org/dev/whatsnew/2.7.html
"""It?s now possible for a subclass of the built-in unicode type to override the __unicode__() method."""

This is clearly a bug in the application.  There are many ways to break compatibility with bogus code...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11900>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:51:38 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Dec 2011 08:51:38 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1324025498.56.0.360649994462.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> For my part, a two-lines description of the purpose of file is enough.

OK, I'll go for small comments in the files themselves and put big
ones in separate files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:00:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 09:00:47 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1324026047.42.0.798460546482.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is there any reason why this issue is still open?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:04:11 2011
From: report at bugs.python.org (Dongying Zhang)
Date: Fri, 16 Dec 2011 09:04:11 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
Message-ID: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>


New submission from Dongying Zhang <zhangdongying1986 at gmail.com>:

I've been trying to parse xml string using python, codes following:

    #-*- coding: utf-8 -*-
    import xml.etree.ElementTree as xmlet
    s = '<?xml version="1.0" encoding="GBK"?><info></info>'
    xmlet.fromstring(s)

Then:
    $ python2.6 test.py
or:
    $ pypy test.py

Traceback message came out like this:

    Traceback (most recent call last):
      File "test.py", line 4, in <module>
        xmlet.fromstring(s)
      File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/xml/etree/ElementTree.py", line 963, in XML
        parser.feed(text)
      File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/xml/etree/ElementTree.py", line 1245, in feed
        self._parser.Parse(data, 0)
    xml.parsers.expat.ExpatError: unknown encoding: line 1, column 30

I've seen this in following cases:

    Python2.5.6 on Mac OS X Lion
    Python2.6.5 on Ubuntu 10.04
    pypy1.7.0 on Mac OS X Lion

But not in these cases:

    Python2.6.7 on Mac OS X Lion
    Python2.7.1 on Mac OS X Lion

----------
components: Library (Lib)
files: test.py
messages: 149602
nosy: dongying
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree says unknown encoding of a regular encoding
versions: Python 2.6
Added file: http://bugs.python.org/file23974/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13612>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:04:34 2011
From: report at bugs.python.org (Dongying Zhang)
Date: Fri, 16 Dec 2011 09:04:34 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1324026274.21.0.167949971678.issue13612@psf.upfronthosting.co.za>


Changes by Dongying Zhang <zhangdongying1986 at gmail.com>:


----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13612>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:05:08 2011
From: report at bugs.python.org (Dongying Zhang)
Date: Fri, 16 Dec 2011 09:05:08 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1324026308.7.0.31675957623.issue13612@psf.upfronthosting.co.za>


Changes by Dongying Zhang <zhangdongying1986 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13612>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:11:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 09:11:27 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1324026687.33.0.382322577866.issue1559549@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"fullname" is technically wrong:

>>> import logging.bar
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'bar'

"module_name" sounds fine and explicit enough to me. Also, as Eric points out, there are many places where an ImportError is raised. You might want to create a private helper API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:29:16 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 16 Dec 2011 09:29:16 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1324027756.83.0.832480259647.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I started a mailing list thread on the same topic:

http://thread.gmane.org/gmane.comp.python.devel/127963

Especially see

http://thread.gmane.org/gmane.comp.python.devel/127963/focus=128162

where I extract a proposal from the discussion. Basically, there should be a note at the top of the xml.dom documentation as follows:

"""
[[Note: The xml.dom.minidom module provides an implementation of the W3C-DOM whose API is similar to that in other programming languages. Users who are unfamiliar with the W3C-DOM interface or who would like to write less code for processing XML files should consider using the xml.etree.ElementTree module instead.]]
"""

I think this should go on the xml.dom.minidom page as well as the xml.dom package page. Hand-wavingly, users who are new to the DOM are more likely to hit the package page first, whereas those who know it already will likely find the MiniDOM page directly.

Note that I'd still encourage the removal of the misleading word "lightweight" until it makes sense to put it back in a meaningful way. I therefore propose the following minimalistic changes to the first paragraph on the minidom page:

"""
xml.dom.minidom is a [-XXX: light-weight] implementation of the Document Object Model interface. It is intended to be simpler than the full DOM and also [+XXX: provide a] significantly smaller [+XXX: API].
"""

Additionally, the documentation on the xml.sax page would benefit from the following paragraph:

"""
[[Note: The xml.sax package provides an implementation of the SAX interface whose API is similar to that in other programming languages. Users who are unfamiliar with the SAX interface or who would like to write less code for efficient stream processing of XML files should consider using the iterparse() function in the xml.etree.ElementTree module instead.]]
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:37:03 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 16 Dec 2011 09:37:03 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1324028223.43.0.415500415039.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Yes, almost half of the buildbots still don't have the xz-utils headers
installed, and thus are not building/testing the lzma module. I've kept
the issue open as a reminder to myself to follow up on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:58:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 09:58:39 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1324029519.43.0.781202042853.issue1785@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch for 3.2.

----------
stage:  -> patch review
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file23975/inspect-and-pydoc-bug2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:05:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 10:05:34 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1324029934.26.0.651772245549.issue1785@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch that adds a test for classifying builtin types (checks that ``inspect.classify_class_attrs(type)`` does not throw as in issue13581).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:05:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 10:05:43 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1324029943.97.0.474458634207.issue1785@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file23976/inspect-and-pydoc-bug3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:15:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 10:15:00 +0000
Subject: [issue12809] Missing new setsockopts in Linux (eg: IP_TRANSPARENT)
In-Reply-To: <1313983612.44.0.0564079708334.issue12809@psf.upfronthosting.co.za>
Message-ID: <1324030500.84.0.705037411096.issue12809@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12809>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:21:39 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Dec 2011 10:21:39 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324030899.48.0.846463737238.issue13610@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Can this be fixed?

More or less.
The following patch does the trick, but is not really elegant:
"""
--- a/Parser/tokenizer.c        2011-06-01 02:39:38.000000000 +0000
+++ b/Parser/tokenizer.c        2011-12-16 08:48:45.000000000 +0000
@@ -1574,6 +1576,10 @@
             }
         }
         tok_backup(tok, c);
+        if (is_potential_identifier_start(c)) {
+            tok->done = E_TOKEN;
+            return ERRORTOKEN;
+        }
         *p_start = tok->start;
         *p_end = tok->cur;
         return NUMBER;
"""

"""
> python -c "1and 0"
  File "<string>", line 1
    1and 0
    ^
SyntaxError: invalid token
"""

Note that there are other - although less bothering - limitations:
"""
> python -c "1 and@ 2"
  File "<string>", line 1
    1 and@ 2
       ^
SyntaxError: invalid syntax
"""

This should be catched by the lexer, not the parser (i.e. it should raise an "Invalid token" error).
That's a limitation of the ad-hoc scanner.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:25:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2011 10:25:43 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <E1RbUyz-0003MQ-Va@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 57f0af61da53 by Antoine Pitrou in branch 'default':
Issue #6695: Full garbage collection runs now clear the freelist of set objects.
http://hg.python.org/cpython/rev/57f0af61da53

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:26:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 10:26:27 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1324031187.23.0.564582381433.issue6695@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The clearing the dict and list freelists has been added independently, so I committed the part of the patch pertaining to sets. Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:09:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 11:09:21 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1324033761.17.0.903654175636.issue11379@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> xml.dom.minidom is a [-XXX: light-weight] implementation of the Document Object Model interface.

This is ok.

> It is intended to be simpler than the full DOM and also
> [+XXX: provide a] significantly smaller [+XXX: API].

Doesn't "simpler" here refer to the API already?

Another option is to add somewhere a section like:
"If you have to work with XML, ElementTree is usually the best choice, because it has a simple API and it's efficient [or whatever].  xml.dom.minidom provides a subset of the W3C-DOM API, and xml.sax a SAX interface.", possibly expanding a bit on the differences and showing a minimal example with the 3 different implementations, and then link to it from the other modules' pages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:21:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 11:21:58 +0000
Subject: [issue5424] Packed IPaddr conversion tests should be extended
In-Reply-To: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>
Message-ID: <1324034518.74.0.208754063176.issue5424@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5424>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:26:45 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 16 Dec 2011 11:26:45 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1324034805.33.0.644386454984.issue13612@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Actually, this fails on 2.6 and 2.7 on wide unicode builds, and passes with narrow unicode builds (on my 64bit Linux box).

In pyexpat.c, PyUnknownEncodingHandler accesses 256 characters of a unicode buffer, without checking its length... which happens to be 192 chars long.
So buffers overflow, etc.  The function has a comment "supports only 8bit encodings"; indeed.
Versions 3.2 and 3.3 happen to pass the test, probably by pure luck.

Supporting multibytes codecs won't be easy: pyexpat requires to fill an array which specifies the number of bytes needed by each start byte (for example, in utf-8, 0xc3 starts a 2-bytes sequence, 0xef starts a 3-bytes sequence).  Our codecs framwork does not provide this information, and some codecs (gb18030 for example) need the second char to determine whether it will need 4 bytes.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13612>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:28:37 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Fri, 16 Dec 2011 11:28:37 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324034917.26.0.537689379571.issue13609@psf.upfronthosting.co.za>


Denilson Figueiredo de S? <denilsonsa at gmail.com> added the comment:

Zbyszek, I just looked at [1] and I disagree that the environment variable should have higher precedence. In fact, I believe it should have lower precedence, and should be used as a fallback.

[1]: http://bugs.python.org/file23241/patch1.1.diff

Reason? Imagine a program is launched, and thus it has COLUMNS set to some value. While the program is running, the user resizes the terminal. I believe (though I have not tested) that the envvar will keep the old value, and this function would return wrong dimensions.

In my opinion, the system-specific code (termios/windll) should be tried first, and then the envvars (as fallback). If all else fails, maybe it would be better to return (None, None) and let the caller of this function handle that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:32:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2011 11:32:41 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <E1RbW1m-0008VE-Mf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6a966179c73a by Antoine Pitrou in branch '3.2':
Issue #10350: Read and save errno before calling a function which might overwrite it.
http://hg.python.org/cpython/rev/6a966179c73a

New changeset 8e0b2e75ca7a by Antoine Pitrou in branch 'default':
Issue #10350: Read and save errno before calling a function which might overwrite it.
http://hg.python.org/cpython/rev/8e0b2e75ca7a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10350>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:33:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 11:33:10 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <1324035190.51.0.853258798268.issue10350@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in 3.x. I won't bother backporting to 2.x. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10350>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:33:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 11:33:47 +0000
Subject: [issue9975] Incorrect use of flowinfo and scope_id in IPv6 sockaddr
	tuple
In-Reply-To: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>
Message-ID: <1324035227.14.0.611605361497.issue9975@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9975>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:07:30 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Dec 2011 12:07:30 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324037250.75.0.16878212288.issue13609@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

http://bugs.python.org/file23241/patch1.1.diff
This looks like something which would fit better into shutil module rather than os.
Also, the Windows implementation should not rely on ctypes.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:12:27 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Dec 2011 12:12:27 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1324037547.24.0.30429988897.issue13041@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
dependencies: +Add "os.get_terminal_size()" function
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13041>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:16:48 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Dec 2011 12:16:48 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324037808.53.0.202196035989.issue13609@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Plus, you should provide also heigth, not only width, possibly as a namedtuple:

>>> import shutil
>>> shutil.get_terminal_size()
size(width=80, heigth=170)
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:20:15 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Dec 2011 12:20:15 +0000
Subject: [issue12809] Missing new setsockopts in Linux (eg: IP_TRANSPARENT)
In-Reply-To: <1313983612.44.0.0564079708334.issue12809@psf.upfronthosting.co.za>
Message-ID: <1324038015.68.0.991362364418.issue12809@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/issue12809>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:44:35 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Dec 2011 12:44:35 +0000
Subject: [issue13229] Improve tools for iterating over filesystem directories
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1324039475.99.0.224125258225.issue13229@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/issue13229>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:53:38 2011
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 16 Dec 2011 12:53:38 +0000
Subject: [issue13584] argparse doesn't respect double quotes
In-Reply-To: <1323644776.15.0.954128215296.issue13584@psf.upfronthosting.co.za>
Message-ID: <1324040018.16.0.150378422279.issue13584@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Closing then. Thanks for checking it again!

----------
assignee:  -> bethard
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13584>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:58:01 2011
From: report at bugs.python.org (Edmund Eyles)
Date: Fri, 16 Dec 2011 12:58:01 +0000
Subject: [issue13613] Small error in regular expression poker hand example
Message-ID: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>


New submission from Edmund Eyles <hotel at heddonsgate.co.uk>:

The documentation for Python 2.7.2 has a section of examples for the regular expression match() function, based on a poker hand, at section 7.2.6.1.  These examples show a suit of cards as having 14 cards!  The ace is counted twice, as '1' and 'a'.  Remind me not to play poker against the author.  

I would suggest changing the range of the characters that represent the cards' denominations to [2-9tjqka], with a 't' representing a 10, rather than using a '0', and not using either the '0' or the '1'.

----------
assignee: docs at python
components: Documentation
messages: 149619
nosy: Eddie E, docs at python
priority: normal
severity: normal
status: open
title: Small error in regular expression poker hand example
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13613>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:11:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 13:11:46 +0000
Subject: [issue13613] Small error in regular expression poker hand example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324041106.77.0.880005802942.issue13613@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti
keywords: +patch
nosy: +ezio.melotti
stage:  -> commit review
type: behavior -> enhancement
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23977/issue13613.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13613>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:27:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 13:27:58 +0000
Subject: [issue13613] Small error in regular expression poker hand example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324042078.23.0.784946018816.issue13613@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file23977/issue13613.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13613>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:28:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 13:28:18 +0000
Subject: [issue13613] Small error in regular expression poker hand example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324042098.01.0.824631307753.issue13613@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file23978/issue13613.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13613>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:41:32 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Fri, 16 Dec 2011 13:41:32 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324042892.11.0.759534392024.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

One reply to three comments:

[To myself]:
>  I'll post an updated version here in a moment.
Hm, it's not so simple. The implementation is simple,
but the configure defines are harder than I thought.
But I'm getting there :)

> Zbyszek, I just looked at [1] and I disagree that the environment variable should have higher precedence. In fact, I believe it should have lower precedence, and should be used as a fallback.

I disagree. $COLUMNS will usually _not_ be set:

$ echo $COLUMNS
119

$ ./python -c 'import os; print("COLUMNS" in os.environ)'
False

As I wrote before, the shell only sets COLUMNS for use in the shell, without exporting. Giving a precedence to the environment variable (if it is set by the user) allows to do something like this:
$ COLUMNS=80 python program.py
... do whatever is to be dome for 80 columns ...
and the normal case (with dynamic checking) will also work correctly.

Anyway, I think that two functions should be provided: a "raw" one, which does the ioctl, and the "normal" one, which queries $COLUMNS and the the "raw" function. If different behaviour is wanted, than just
the "raw" one can be called.

> Also, the Windows implementation should not rely on ctypes.
Of course. For windows I have:
  #include <conio.h>
  ...
  GetConsoleScreenBufferInfo(handle, &csbi)
  ...

> This looks like something which would fit better into shutil module rather than os.
This is problematic. The docstring for shutil says:
  Utility functions for copying and archiving files and directory trees.
So it doesn't seem to fit at all.

OTOH, there's termios and tty, but they are UNIX only. Module curses is also UNIX only, and slightly different topic, because get_terminal_width should be independent of curses.

> Plus, you should provide also heigth, not only width, possibly as a namedtuple.
Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:47:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2011 13:47:07 +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: <E1RbY7u-00042O-DM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1f23bb74f4bc by Antoine Pitrou in branch 'default':
Issue #8373: The filesystem path of AF_UNIX sockets now uses the filesystem
http://hg.python.org/cpython/rev/1f23bb74f4bc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:47:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 13:47:41 +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: <1324043261.91.0.189129118096.issue8373@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in 3.3 (default branch), thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8373>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:50:20 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 13:50:20 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1324043420.57.0.997600776979.issue13604@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

>> Why is the utf-8 representation not cached when it is generated for
>> ParseTuple et alia?

My error -- I read something backwards.

>> When a string is created from a wchar_t array, who is responsible for
>> releasing the original wchar_t array?

> The caller.

OK, I'll document that.

>> As I read it now, Python
>> doesn't release the buffer, and the caller can't because maybe Python
>> just pointed to it as memory shared with the canonical
>> representation.

> But Python won't; it will always make a copy for itself.

I thought I found an example each way, but it is possible that the shared version was something python had already copied.  If not, I'll raise that as a separate issue to get the code changed.

(Note that I may not be able to look at this again until after Christmas, so I'm likely to go silent for a while.)

----------
Added file: http://bugs.python.org/file23979/pep-0393.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:51:04 2011
From: report at bugs.python.org (Edmund Eyles)
Date: Fri, 16 Dec 2011 13:51:04 +0000
Subject: [issue13613] Small error in regular expression poker hand example
In-Reply-To: <1324042098.07.0.889145331491.issue13613@psf.upfronthosting.co.za>
Message-ID: <4EEB4CCD.3090800@heddonsgate.co.uk>


Edmund Eyles <hotel at heddonsgate.co.uk> added the comment:

Changes proposed in file 23978 look good to me!

On 16/12/2011 13:28, Ezio Melotti wrote:
>
> Changes by Ezio Melotti<ezio.melotti at gmail.com>:
>
>
> Added file: http://bugs.python.org/file23978/issue13613.diff
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue13613>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13613>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:52:38 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 13:52:38 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1324043558.34.0.696937150115.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


Added file: http://bugs.python.org/file23980/pep-0393_20111216.txt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13604>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:38:43 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Dec 2011 14:38:43 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324046323.93.0.15855496054.issue13610@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Can this be fixed?

Not without breaking backwards compatibility, I would think.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:53:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Dec 2011 14:53:44 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324047224.93.0.287710329445.issue13610@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think it's fairly harmless. Perhaps Python 4.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:50:36 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 16 Dec 2011 15:50:36 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324050636.09.0.425598992157.issue13609@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> The docstring for shutil says: Utility functions for copying and 
> archiving files and directory trees. So it doesn't seem to fit at all.

Well... shutil should stand for "shell utilities" and it already contains stuff which is not strictly related to file/directory direct operations (see shutil.disk_usage and upcoming shutil.which).

But maybe you're right... I don't know...
My point is that a function which attempts different fallbacks (ask OS -> ask os.environ -> return (None, None) / raise exception) sounds more like an utility function rather than something belonging to os module, where you tipically see 1-to-1 interfaces for the underlying system functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:56:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 16 Dec 2011 15:56:44 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1324051004.44.0.30180231526.issue1559549@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I think I'm going to stick with name unless anyone is super opposed. If we can eventually import something else (sausages?), then setting module_name with a sausage name will seem weird.

I'll work up a more complete patch. The private helper is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Dec 16 17:02:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Dec 2011 16:02:33 +0000
Subject: [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1324051353.54.0.693522558317.issue13604@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/issue13604>
_______________________________________

From report at bugs.python.org  Fri Dec 16 17:09:30 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Fri, 16 Dec 2011 16:09:30 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324051770.7.0.389687767252.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

This is proof-of-concept implementation.

This adds two modules: termsize (python) and _termsize (C). The first one contains the get_terminal_size user-facing function and namedtuple definition. The second on contains the function query_terminal_size which does the real job.

Two simple tests are added. I'm not sure if it is feasible to test with different terminal sizes: it certainly _could_ be done, e.g. by launching an xterm with a specified geometry, but this would be much
more complicated than this implementation, so probably not worth it.

This was only tested on 64-bit linux, seems to work.

I'm not sure how to the configure tests should be done: right now the presence of <sys/ioctl.h> is checked, and it is used. If not available, 
<conio.h> is checked, and used. Otherwise NotImplementedError is thrown.

Would be nice to test on a mac and other systems, but I don't have one available at the moment unfortunately.

I think that the python part (termsize.py) should be either merged with os.py (or whatever home we find for this function), or rewritten in C in _termsizemodule.c and only imported into os. But since it hasn't yet been decided where this should go, keeping it separate is easier for now.

----------
keywords: +patch
Added file: http://bugs.python.org/file23981/termsize.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 17:45:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 16 Dec 2011 16:45:15 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324053915.67.0.238769333811.issue13609@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Don't forget the Windows platform... here is an implementation: https://bitbucket.org/hpk42/py/src/980c8d526463/py/_io/terminalwriter.py#cl-284 
But it would be better written in C, of course.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:04:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Dec 2011 17:04:04 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324055044.21.0.497001482269.issue13607@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/issue13607>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:28:04 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 16 Dec 2011 17:28:04 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1324056484.73.0.312217498033.issue1785@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:32:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Dec 2011 17:32:03 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324056723.82.0.244104141843.issue13609@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, a couple of general comments:
- there is no point having a separate module for a single function; I think the os module (and posixmodule.c for the C side) is a reasonable place where to put this
- C code should be indented with 4 spaces increments and no tabs (see PEP 7)
- constants in C code should be uppercase
- C code should be C89-compliant and therefore we don't use named struct initializers (such as ".m_size = 0")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:45:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Dec 2011 17:45:07 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324057507.13.0.175403857432.issue13610@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/issue13610>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:45:14 2011
From: report at bugs.python.org (Josh)
Date: Fri, 16 Dec 2011 17:45:14 +0000
Subject: [issue818201] distutils: clean does not use build_base option from
	build
Message-ID: <1324057514.74.0.481210548496.issue818201@psf.upfronthosting.co.za>


Josh <josh.davidson at lmco.com> added the comment:

Where was this fixed?  It is still a problem in Python 2.6.6.

For example, if I do: 
python setup.py build_ext --compiler=mingw32  build --build-platlib=build\win64

Then follow it up with:
python setup.py clean --build-base=build\win64 -a

This is what it does:
running clean
'build\lib.win-amd64-2.6' does not exist -- can't clean it
removing 'build\bdist.win-amd64' (and everything under it)
'build\scripts-2.6' does not exist -- can't clean it

As you can see, the base directory argument is ignored.

----------
nosy: +davidsj2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue818201>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:52:52 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Dec 2011 17:52:52 +0000
Subject: [issue13611] Integrate ElementC14N module into xml.etree package
In-Reply-To: <1324023461.04.0.625039310668.issue13611@psf.upfronthosting.co.za>
Message-ID: <1324057972.58.0.729270037639.issue13611@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Code added to the standard library should be contributed by its author, with an explicit statement of plans to support it in an ongoing manner, and preferably also with plans to stop providing standalone releases over time.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13611>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:59:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Dec 2011 17:59:07 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1324033761.17.0.903654175636.issue11379@psf.upfronthosting.co.za>
Message-ID: <4EEB86E9.7070802@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> "If you have to work with XML, ElementTree is usually the best
> choice, because it has a simple API and it's efficient [or whatever].

I still object such a wording, for many reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:02:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Dec 2011 18:02:22 +0000
Subject: [issue5424] Packed IPaddr conversion tests should be extended
In-Reply-To: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>
Message-ID: <1324058542.57.0.824927472703.issue5424@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree with Antoine: a single test testing that we actually raise exceptions properly should be sufficient.

OTOH, the patch doesn't hurt (AFAICT), so I wouldn't mind if it was applied as-is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5424>
_______________________________________

From report at bugs.python.org  Fri Dec 16 22:00:50 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Dec 2011 21:00:50 +0000
Subject: [issue13614] `setup.py register` fails with traceback
Message-ID: <1324069250.69.0.136486094973.issue13614@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It seems that invalid ReST in long_description causes traceback in distutils `register` command. See attached log.

More details:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/905500

----------
assignee: tarek
components: Distutils
files: traceback.txt
messages: 149636
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: `setup.py register` fails with traceback
versions: Python 2.7
Added file: http://bugs.python.org/file23982/traceback.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13614>
_______________________________________

From report at bugs.python.org  Fri Dec 16 22:21:38 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Dec 2011 21:21:38 +0000
Subject: [issue13615] `setup.py register` fails with -r argument
Message-ID: <1324070497.95.0.248126770194.issue13615@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

$ python setup.py sdist register -r https://pypi.python.org/pypi upload
...

Creating tar archive
removing 'pager-0.2' (and everything under it)
running register
Traceback (most recent call last):
  File "setup.py", line 17, in <module>
    'Operating System :: OS Independent',
  File "/usr/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/distutils/command/register.py", line 47, in run
    self._set_config()
  File "/usr/lib/python2.7/distutils/command/register.py", line 82, in _set_config
    raise ValueError('%s not found in .pypirc' % self.repository)
ValueError: https://pypi.python.org/pypi not found in .pypirc



---

$ python setup.py register -h
...
Options for 'register' command:
  --repository (-r)   url of repository [default: http://pypi.python.org/pypi]
...
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
...

----------
assignee: tarek
components: Distutils
messages: 149637
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: `setup.py register` fails with -r argument
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13615>
_______________________________________

From report at bugs.python.org  Fri Dec 16 22:21:55 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Dec 2011 21:21:55 +0000
Subject: [issue13615] `setup.py register` fails with -r argument
In-Reply-To: <1324070497.95.0.248126770194.issue13615@psf.upfronthosting.co.za>
Message-ID: <1324070515.32.0.956210938794.issue13615@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Ubuntu 11.10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13615>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:20:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2011 23:20:23 +0000
Subject: [issue13613] Small error in regular expression poker hand example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <E1Rbh4f-0003mF-K0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 766a21ebf82e by Ezio Melotti in branch '2.7':
#13613: fix example in re doc.
http://hg.python.org/cpython/rev/766a21ebf82e

New changeset 0b86da9d6964 by Ezio Melotti in branch '3.2':
#13613: fix example in re doc.
http://hg.python.org/cpython/rev/0b86da9d6964

New changeset f2e1867f33b8 by Ezio Melotti in branch 'default':
#13613: merge with 3.2.
http://hg.python.org/cpython/rev/f2e1867f33b8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13613>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:22:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 23:22:17 +0000
Subject: [issue13613] Small error in regular expression poker hand example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324077737.46.0.913117209608.issue13613@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13613>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:27:13 2011
From: report at bugs.python.org (David Butler)
Date: Fri, 16 Dec 2011 23:27:13 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
Message-ID: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>


New submission from David Butler <croepha at gmail.com>:

CPU will sit a 100% indefinitely, this is also pretty tough (takes several hours) to reproduce

if you step through the program it is stuck between 290 and 292


Modules/gcmodule.c:

/* Set all gc_refs = ob_refcnt.  After this, gc_refs is > 0 for all objects
 * in containers, and is GC_REACHABLE for all tracked gc objects not in
 * containers.
 */
static void
update_refs(PyGC_Head *containers)
{
    PyGC_Head *gc = containers->gc.gc_next;
    for (; gc != containers; gc = gc->gc.gc_next) {      <-- line 290
        assert(gc->gc.gc_refs == GC_REACHABLE);
        gc->gc.gc_refs = Py_REFCNT(FROM_GC(gc));         <-- line 292
        /* Python's cyclic gc should never see an incoming refcount
         * of 0:  if something decref'ed to 0, it should have been
         * deallocated immediately at that time.
         * Possible cause (if the assert triggers):  a tp_dealloc
         * routine left a gc-aware object tracked during its teardown
         * phase, and did something-- or allowed something to happen --
         * that called back into Python.  gc can trigger then, and may
         * see the still-tracked dying object.  Before this assert
         * was added, such mistakes went on to allow gc to try to
         * delete the object again.  In a debug build, that caused
         * a mysterious segfault, when _Py_ForgetReference tried
         * to remove the object from the doubly-linked list of all
         * objects a second time.  In a release build, an actual
         * double deallocation occurred, which leads to corruption
         * of the allocator's internal bookkeeping pointers.  That's
         * so serious that maybe this should be a release-build
         * check instead of an assert?
         */
        assert(gc->gc.gc_refs != 0);
    }
}



GDB backtrace:

#0  0xb7750fcb in update_refs (generation=2) at Modules/gcmodule.c:290
#1  collect (generation=2) at Modules/gcmodule.c:873
#2  0xb77515e3 in collect_generations (basicsize=20) at Modules/gcmodule.c:996
#3  _PyObject_GC_Malloc (basicsize=20) at Modules/gcmodule.c:1457
#4  0xb775163e in _PyObject_GC_NewVar (tp=0xb77a0640, nitems=2) at Modules/gcmodule.c:1477
#5  0xb76df4b7 in PyTuple_New (size=2) at Objects/tupleobject.c:90
#6  0xb77230fd in PyEval_EvalFrameEx (f=
    Frame 0x889acdc, for file /usr/lib/python2.7/site-packages/twisted/python/failure.py, line 443, in __getstate__ (self=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<...>, _runningCallbacks=False) at remote 0x9f1cb2c>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type...(truncated), throwflag=0) at Python/ceval.c:2178
#7  0xb772489a in fast_function (f=
    Frame 0x889ab84, for file /usr/lib/python2.7/site-packages/twisted/python/failure.py, line 452, in cleanFailure (self=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<...>, _runningCallbacks=False) at remote 0x9f1cb2c>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type...(truncated), throwflag=0) at Python/ceval.c:4099
#8  call_function (f=
    Frame 0x889ab84, for file /usr/lib/python2.7/site-packages/twisted/python/failure.py, line 452, in cleanFailure (self=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<...>, _runningCallbacks=False) at remote 0x9f1cb2c>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type...(truncated), throwflag=0) at Python/ceval.c:4034
#9  PyEval_EvalFrameEx (f=
    Frame 0x889ab84, for file /usr/lib/python2.7/site-packages/twisted/python/failure.py, line 452, in cleanFailure (self=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<...>, _runningCallbacks=False) at remote 0x9f1cb2c>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type...(truncated), throwflag=0) at Python/ceval.c:2666
#10 0xb772489a in fast_function (f=
    Frame 0x9e4fea4, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 578, in _runCallbacks (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <classob...(truncated), throwflag=0) at Python/ceval.c:4099
#11 call_function (f=
    Frame 0x9e4fea4, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 578, in _runCallbacks (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages---Type <return> to continue, or q <return> to quit---
/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <classob...(truncated), throwflag=0) at Python/ceval.c:4034
#12 PyEval_EvalFrameEx (f=
    Frame 0x9e4fea4, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 578, in _runCallbacks (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <classob...(truncated), throwflag=0) at Python/ceval.c:2666
#13 0xb772489a in fast_function (f=
    Frame 0x9b745cc, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 455, in _startRunCallbacks (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <cl...(truncated), throwflag=0) at Python/ceval.c:4099
#14 call_function (f=
    Frame 0x9b745cc, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 455, in _startRunCallbacks (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <cl...(truncated), throwflag=0) at Python/ceval.c:4034
#15 PyEval_EvalFrameEx (f=
    Frame 0x9b745cc, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 455, in _startRunCallbacks (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <cl...(truncated), throwflag=0) at Python/ceval.c:2666
#16 0xb772489a in fast_function (f=
    Frame 0x9ee4c04, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 361, in callback (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <classobj at ...(truncated), throwflag=0) at Python/ceval.c:4099
#17 call_function (f=
    Frame 0x9ee4c04, for file /usr/lib/python2.7/site-packages/twisted/internet/defer.py, line 361, in callback (self=<Deferred(_chainedTo=None, called=True, _canceller=None, callbacks=[], result=<Failure(count=3460, tb=<traceback at remote 0x9884fa4>, value=exceptions.AttributeError("DeferredList instance has no attribute 'resultList'",), parents=['exceptions.AttributeError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.AttributeError'], frames=[['_runCallbacks', '/usr/lib/python2.7/site-packages/twisted/internet/defer.py', 542, [('chain', [<...>]), ('callback', <instancemethod at remote 0x9dbf98c>), ('self', <...>), ('args', (1, True)), ('current', <...>), ('item', ((<instancemethod at remote 0x9dbf98c>, (...), None), (<instancemethod at remote 0x9f1e11c>, (1, False), None))), ('finished', True), ('kw', {})], [('AlreadyCalledError', <type at remote 0x885dd6c>), ('DeferredFilesystemLock', <type at remote 0x8860f54>), ('DebugInfo', <classobj at ...(truncated), throwflag=0) at Python/ceval.c:4034

----------
messages: 149641
nosy: David.Butler
priority: normal
severity: normal
status: open
title: Never ending loop in in update_refs Modules/gcmodule.c
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:28:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2011 23:28:17 +0000
Subject: [issue13571] Backup files support in IDLE
In-Reply-To: <1323486572.25.0.465631438567.issue13571@psf.upfronthosting.co.za>
Message-ID: <1324078097.11.0.00657651189109.issue13571@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Roger that developing an extension elsewhere is the proper first step. I suspect that you will want to experiment with the exact behavior and interface. So I am closing this for now, though you can reopen later if there is a renewed proposal to change IDLE as distributed. But I would sooner incorporate some of the other extensions that have already been written and tested as part of IdleX.

Because I don't usually do the things that cause IDLE to crash, at least not while coding, and do use a fairly short code/F5-run test cycle, I am not sure I would need this much. On the other hand, a 5 or 10 minute timed backup might not be a bad idea.

----------
nosy: +terry.reedy
resolution:  -> later
status: open -> closed
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13571>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:31:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2011 23:31:20 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <1324078280.95.0.738069968876.issue13573@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this complete and ready to close, or does the doc need a note?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:43:33 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 16 Dec 2011 23:43:33 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324079013.73.0.917485533243.issue13616@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Are you sure that the program is really stuck in the gc module?
The loop you mention has to go through all objects of the process.  It's possible that it allocated many objects, that one garbage collection takes a few seconds, and even that most of the time is spent inside the garbage collector.
But can you check whether this function terminates?  For example, you could put a breakpoint in the collect() function.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:47:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2011 23:47:32 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1324079252.11.0.43136263125.issue13579@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

At line 237 of string.py:
    def convert_field(self, value, conversion):
        # do any conversion on the resulting object
        if conversion == 'r':
            return repr(value)
        elif conversion == 's':
            return str(value)
        elif conversion is None:
            return value
add
        elif conversion == 'a':
            return ascii(value)

The alternatives should be ordered by decreasing frequency. I suspect that should be None, 's', 'r', 'a'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:50:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2011 23:50:03 +0000
Subject: [issue13579] string.Formatter doesn't understand the !a conversion
	specifier
In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za>
Message-ID: <1324079403.85.0.805281064711.issue13579@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13579>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:54:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2011 23:54:17 +0000
Subject: [issue13582] IDLE and pythonw.exe stderr problem
In-Reply-To: <1323632290.53.0.810720020667.issue13582@psf.upfronthosting.co.za>
Message-ID: <1324079657.76.0.278941090707.issue13582@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13582>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:55:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2011 23:55:54 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>
Message-ID: <1324079754.12.0.0239667008953.issue13583@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ghaering
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13583>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:01:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Dec 2011 00:01:17 +0000
Subject: [issue13573] csv.writer uses str() for floats instead of repr()
In-Reply-To: <1323542995.09.0.555276242173.issue13573@psf.upfronthosting.co.za>
Message-ID: <1324080077.54.0.846755067689.issue13573@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The code is fixed.  Am leaving this open until I have a chance to see if anything in the docs need to be updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13573>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:01:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:01:58 +0000
Subject: [issue13586] Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324080118.41.0.593638791438.issue13586@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.2 on Win 7, selected text *is* put in the 'find' field of Replace boxes, just as with Find boxes, just as it should be. So there is something specific either to 2.7 (which is unusual, since the code base in mostly the same, but possible) or to your OS. What are you running Python with?

----------
nosy: +terry.reedy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:02:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:02:29 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324080149.89.0.219610725635.issue13586@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Replace selected not working/consistent with find -> IDLE: Replace selected not working/consistent with find

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:03:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:03:18 +0000
Subject: [issue13587] Correcting the typos error in Doc/howto/urllib2.rst
In-Reply-To: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za>
Message-ID: <1324080198.65.0.273217144435.issue13587@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13587>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:06:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:06:55 +0000
Subject: [issue13587] Correcting the typos error in Doc/howto/urllib2.rst
In-Reply-To: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za>
Message-ID: <1324080415.99.0.065549799555.issue13587@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Error is in 3.2 docs as well.

2.6/3.1 only get security patches. 3.4 is for future enhancements what will not even go into 3.3.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13587>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:09:23 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:09:23 +0000
Subject: [issue13590] Prebuilt python-2.7.2 binaries for macosx can not
	compile c extensions
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1324080563.34.0.13853132361.issue13590@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:16:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:16:41 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1324081001.1.0.937777788522.issue13592@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> but if #11957 is fixed, the result will look like
  re.Regex('abc', re.I|re.S)

That is what I would like to see.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:22:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:22:17 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1324081337.32.0.642868633366.issue13598@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:29:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:29:00 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324081740.89.0.219353787223.issue13607@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:31:17 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Dec 2011 00:31:17 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324081877.08.0.0624380370283.issue13607@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Seems mostly fine to me.

----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Sat Dec 17 02:19:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 01:19:46 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324084786.79.0.503524831287.issue13610@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The proposal is to change the definition of numbers literals from X to one that is context-sensitive: X followed by whitespace or a syntactic symbol but not anything else, in particular, not by an identifier_start character. I am +-0 at the moment.

> 1 and@ 2
I presume this is parsed as 1 and @ 2, which is a syntax error.

----------
nosy: +terry.reedy
type:  -> enhancement
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 02:25:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 01:25:37 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1324085137.53.0.528150669734.issue13612@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.2, Win7 (a narrow build) it indeed works and returns
<Element 'info' at 0x3389128>

----------
nosy: +terry.reedy
versions: +Python 2.7 -3rd party, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13612>
_______________________________________

From report at bugs.python.org  Sat Dec 17 02:41:33 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 17 Dec 2011 01:41:33 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1324086093.88.0.473648211956.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Here's updated version: termsize.diff.1

> Ok, a couple of general comments:
> - there is no point having a separate module for a single function; I > think the os module (and posixmodule.c for the C side) is a
> reasonable place where to put this
Done. (But posixmodule.c is so enourmous... I feel bad making it even longer.)

> - C code should be indented with 4 spaces increments and no tabs (see > PEP 7)
> - constants in C code should be uppercase
> - C code should be C89-compliant and therefore we don't use named
> struct initializers (such as ".m_size = 0")
All done, I hope.

This version was tested on linux/amd64 and win32 (XP).

----------
Added file: http://bugs.python.org/file23983/termsize.diff.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Sat Dec 17 03:00:20 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 17 Dec 2011 02:00:20 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1324087220.41.0.938397892525.issue1294232@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Sat Dec 17 03:55:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 02:55:56 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
In-Reply-To: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>
Message-ID: <1324090556.36.0.130550136058.issue13560@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

changeset:   74002:279b0aee0cfb
user:        Victor Stinner <victor.stinner at haypocalc.com>
date:        Fri Dec 16 23:56:01 2011 +0100
files:       Doc/c-api/unicode.rst Include/unicodeobject.h Modules/_localemodule.c Modules/main.c Modules/timemodule.c
description:
Add PyUnicode_DecodeLocaleAndSize() and PyUnicode_DecodeLocale()

 * PyUnicode_DecodeLocaleAndSize() and PyUnicode_DecodeLocale() decode a string
   from the current locale encoding
 * _Py_char2wchar() writes an "error code" in the size argument to indicate
   if the function failed because of memory allocation failure or because of a
   decoding error. The function doesn't write the error message directly to
   stderr.
 * Fix time.strftime() (if wcsftime() is missing): decode strftime() result
   from the current locale encoding, not from the filesystem encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13560>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:46:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 03:46:08 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
In-Reply-To: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>
Message-ID: <E1RblDq-0002xt-KE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 88198b93ff2f by Victor Stinner in branch 'default':
Issue #13560: Add PyUnicode_EncodeLocale()
http://hg.python.org/cpython/rev/88198b93ff2f

New changeset 51412b4b81ae by Victor Stinner in branch 'default':
Issue #13560: os.strerror() now uses the current locale encoding instead of UTF-8
http://hg.python.org/cpython/rev/51412b4b81ae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13560>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:53:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 03:53:42 +0000
Subject: [issue13617] Reject embedded null characters in wchar* strings
Message-ID: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The curses module (only since Python 3.3), locale.strcoll(), locale.strxfrm(), time.strftime() and imp.NullImporter() (only on Windows) accept embedded null characters, whereas they convert the Unicode string to a wide character (wchar_t*) string.

The problem is that the null character truncates the string. Example:


>>> locale.strxfrm('a')
'a'
>>> locale.strxfrm('a\0b')
'a'

Attached patch fixes these functions. I wrote the patch for Python 3.3.

----------
components: Library (Lib), Unicode
files: embedded_nul.patch
keywords: patch
messages: 149656
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Reject embedded null characters in wchar* strings
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23984/embedded_nul.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13617>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:56:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 03:56:00 +0000
Subject: [issue13617] Reject embedded null characters in wchar* strings
In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za>
Message-ID: <1324094160.83.0.701342457603.issue13617@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyUnicode_AsWideCharString() documentation should also warn about this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13617>
_______________________________________

From report at bugs.python.org  Sat Dec 17 05:46:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 04:46:27 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
In-Reply-To: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>
Message-ID: <E1RbmA8-0006aJ-Fy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 07802351ccad by Victor Stinner in branch 'default':
Issue #13560: Locale codec functions use the classic "errors" parameter,
http://hg.python.org/cpython/rev/07802351ccad

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13560>
_______________________________________

From report at bugs.python.org  Sat Dec 17 06:37:33 2011
From: report at bugs.python.org (Silverback Networks)
Date: Sat, 17 Dec 2011 05:37:33 +0000
Subject: [issue13618] bytes.deocde() UnicodeEncodeError on Apple iOS characters
Message-ID: <1324100253.42.0.832436521818.issue13618@psf.upfronthosting.co.za>


New submission from Silverback Networks <silverbacknet at gmail.com>:

I've searched high and low to find a way to make Python accept Apple's iOS characters, but it looks like Python is not supporting greater than 16-bit characters correctly. If you look at the leading character of each group, it's \xf0, indicating a 4-character sequence, which also indicates greater than 16-bit characters. I've tried all three "errors" arguments to decode - ignore, replace, and strict - and still get this error each time:

UnicodeEncodeError: 'charmap' codec can't encode characters in position 140: character maps to <undefined>

So I have no way to proceed short of rolling my own corrected unicode decoder. My assumption is that Python should convert a character regardless of whether it's found in the internal lookup database, or at a minimum there should be a way to signal Python to do so.

Below is a sample bytes string that will reproduce the problem:

b'<?xml version=\'1.0\' encoding=\'utf-8\'?>\n  <dict>\n   <key>\n    average-user-rating\n   </key>\n   <real>\n    1\n   </real>\n   <key>\n    text\n   </key>\n   <string>\n    \xf0\x9f\x8e\x84\xf0\x9f\x8e\x85\xf0\x9f\x8e\x81\xf0\x9f\x8e\x84\xf0\x9f\x8e\x85\xf0\x9f\x8e\x81  if you haven&#39;t checked this out yet please do. download APP TRAILERS and go to videos use promo code FREE4U and enjoy free apps courtesy of apple MERRY CHRISTMAS \xf0\x9f\x8e\x84\xf0\x9f\x8e\x85\xf0\x9f\x8e\x81\xf0\x9f\x8e\x84\xf0\x9f\x8e\x85\xf0\x9f\x8e\x81\n   </string>\n   <key>\n    title\n   </key>\n   <string>\n    4. IF YOU LOVE FREE STUFF (v1.5)\n   </string>\n   <key>\n    type\n   </key>\n   <string>\n    review\n   </string>\n   <key>\n    user-name\n   </key>\n   <string>\n    Freenesss on Dec 16, 2011\n   </string>\n  </dict>\n  <dict>\n   <key>\n    average-user-rating\n   </key>\n   <real>\n    0.8\n   </real>\n   <key>\n    text\n   </key>\n   <string>\n    This application is very cool .. I hope only be added to the dictionary other languages \xe2\x80\x8b\xe2\x80\x8b..\n   </string>\n   <key>\n    title\n   </key>\n   <string>\n    8. the dictionary (v1.5)\n   </string>\n   <key>\n    type\n   </key>\n   <string>\n    review\n   </string>\n   <key>\n    user-name\n   </key>\n   <string>\n    Rnaa on Dec 16, 2011\n   </string>\n  </dict>\n  <dict>\n   <key>\n    average-user-rating\n   </key>\n   <real>\n    1\n   </real>\n   <key>\n    text\n   </key>\n   <string>\n    Hey I&#39;m 13 trying to b discovered plz check my 1st video out on you tube its called speak now cover  by Bekka burton thnx and I luv luv luv this app\n   </string>\n   <key>\n    title\n   </key>\n   <string>\n    9. Love this app+check me out on you tube (v1.5)\n   </string>\n   <key>\n    type\n   </key>\n   <string>\n    review\n   </string>\n   <key>\n    user-name\n   </key>\n   <string>\n    Lol\xee\x84\x86 on Dec 16, 2011\n   </string>\n  </dict>\n'

(Obviously, stripped down to not-well-formed XML, but for conversion purposes that's irrelevant.)

----------
components: Unicode
messages: 149659
nosy: ezio.melotti, silverbacknet
priority: normal
severity: normal
status: open
title: bytes.deocde() UnicodeEncodeError on Apple iOS characters
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13618>
_______________________________________

From report at bugs.python.org  Sat Dec 17 06:37:54 2011
From: report at bugs.python.org (Silverback Networks)
Date: Sat, 17 Dec 2011 05:37:54 +0000
Subject: [issue13618] bytes.decode() UnicodeEncodeError on Apple iOS (>16-bit)
	characters
In-Reply-To: <1324100253.42.0.832436521818.issue13618@psf.upfronthosting.co.za>
Message-ID: <1324100274.68.0.271237025505.issue13618@psf.upfronthosting.co.za>


Changes by Silverback Networks <silverbacknet at gmail.com>:


----------
title: bytes.deocde() UnicodeEncodeError on Apple iOS characters -> bytes.decode() UnicodeEncodeError on Apple iOS (>16-bit) characters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13618>
_______________________________________

From report at bugs.python.org  Sat Dec 17 06:54:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 05:54:02 +0000
Subject: [issue13618] bytes.decode() UnicodeEncodeError on Apple iOS (>16-bit)
	characters
In-Reply-To: <1324100253.42.0.832436521818.issue13618@psf.upfronthosting.co.za>
Message-ID: <1324101242.99.0.351328338046.issue13618@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/issue13618>
_______________________________________

From report at bugs.python.org  Sat Dec 17 07:13:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 06:13:46 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
Message-ID: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

To factorize the code and to fix encoding issues in the time module, I added functions to decode/encode from/to the locale encoding: PyUnicode_DecodeLocale(), PyUnicode_DecodeLocaleAndSize() and PyUnicode_EncodeLocale() (issue #13560). During tests, I realized that os.strerror() should also use the current locale encoding.

Do you think that the codec should be exposed in Python?

--

The C functions are used by:

 * the locale module to decode result of locale functions
 * Py_Main() to decode the PYTHONWARNING environment variable (PyUnicode_DecodeFSDefault can be used here, but PyUnicode_DecodeFSDefault would just call PyUnicode_DecodeLocale because the Python codec is not loaded yet, a funny bootstrap issue)
 * PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefault[AndSize]() before the locale encoding is known and the Python codec is fully ready
 * os.strerror() and PyErr_SetFromErrno*() to decode the error message
 * time.strftime() to encode the format and decode the result if the wcsftime() function is not available and on Windows. On Windows, wcsftime() is available but avoided to workaround an encoding issue in the timezone (see the issue #10653)
 * time to decode time.tzname

The codec can be useful for developers interacting with C functions depending on the locale. Examples: strerror(), strftime(), ... Use the filesystem encoding would be wrong for such function because the locale encoding can be changed by setlocale() with LC_CTYPE or LC_ALL. Use the filesystem encoding would lead to mojibake.

Even if the most common usecases of C functions depending on the locale are already covered by the Python standard library, developers may want to bind new functions using ctypes (or something else), and I believe that the locale encoding would be useful for these bindings.

--

The problem with a new codec is that it becomes more difficult to choose the right encoding:

 * filesystem encoding: filenames, directory names, hostname, environment variables, command line arguments
 * mbcs (ANSI code page): (basically, it is just an alias of the filesystem encoding)
 * locale: write bindings for new C functions?

I suppose that this issue can be solve by writing documentation explaining the usage of each codec.

--

Attached patch adds the new locale codec.

The major limitation of the current implementation is that the codec only supports the strict and the surrogateescape error handlers. I don't plan to implement other error handlers because I don't think that they would be useful, but it would be possible to implement them.

--

I would be "nice" to fix os.strerror() and time.strftime() in Python 3.2, but I don't want to fix them because it would require to add the locale codec and I don't want to do such change in a stable version. The issue only concerns few people changing their locale encoding at runtime. I hope that everybody uses UTF-8 and never change their locale encoding to something else ;-)

----------
components: Library (Lib)
messages: 149660
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: Add a new codec: "locale", the current locale encoding
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Sat Dec 17 07:15:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 06:15:01 +0000
Subject: [issue13560] Add PyUnicode_DecodeLocale and
	PyUnicode_DecodeLocaleAndSize
In-Reply-To: <1323385336.87.0.489685352091.issue13560@psf.upfronthosting.co.za>
Message-ID: <1324102501.23.0.114238075744.issue13560@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, I think that the current code is good enough to close the issue. I opened a more global issue about the Python codec: #13619.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13560>
_______________________________________

From report at bugs.python.org  Sat Dec 17 07:15:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 06:15:44 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324102544.48.0.0575172226899.issue13619@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23985/locale_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Sat Dec 17 07:31:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 06:31:18 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324103478.8.0.199899990591.issue13619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

# On FreeBSD, Solaris and Mac OS X, b'\xff' can be decoded in
# the C locale. The C locale is something like ISO-8859-1, not
# 7-bit ASCII.

On FreeBSD, it *is* the ISO-8859-1 encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Sat Dec 17 07:41:39 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Sat, 17 Dec 2011 06:41:39 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324104099.76.0.630216659795.issue13586@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

Win 7 Pro 32bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sat Dec 17 08:04:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Dec 2011 07:04:14 +0000
Subject: [issue13618] bytes.decode() UnicodeEncodeError on Apple iOS (>16-bit)
	characters
In-Reply-To: <1324100253.42.0.832436521818.issue13618@psf.upfronthosting.co.za>
Message-ID: <1324105454.1.0.794287819179.issue13618@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried to decode this with utf-8 and I got
'...\U0001f384\U0001f385\U0001f381\U0001f384\U0001f385\U0001f381  if you haven&#39;t checked this out yet please do. download APP TRAILERS and go to videos use promo code FREE4U and enjoy free apps courtesy of apple MERRY CHRISTMAS \U0001f384\U0001f385\U0001f381\U0001f384\U0001f385\U0001f381...'

How did you get that error?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13618>
_______________________________________

From report at bugs.python.org  Sat Dec 17 10:20:34 2011
From: report at bugs.python.org (Silverback Networks)
Date: Sat, 17 Dec 2011 09:20:34 +0000
Subject: [issue13618] bytes.decode() UnicodeEncodeError on Apple iOS (>16-bit)
	characters
In-Reply-To: <1324100253.42.0.832436521818.issue13618@psf.upfronthosting.co.za>
Message-ID: <1324113634.71.0.362199541637.issue13618@psf.upfronthosting.co.za>


Silverback Networks <silverbacknet at gmail.com> added the comment:

I feel like a 'tard now, it was because I was trying to print() it at the same time I decoded it, which is what threw up. Well, sorry about that, next time I'll be a little more careful to separate every step before I go reporting it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13618>
_______________________________________

From report at bugs.python.org  Sat Dec 17 12:22:32 2011
From: report at bugs.python.org (Oleg Broytman)
Date: Sat, 17 Dec 2011 11:22:32 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
Message-ID: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>


New submission from Oleg Broytman <phd at phdru.name>:

Support Google Chrome/Chromium browsers in webbrowser.py.

The attached patch is against Python 2.7, but it should be applied cleanly to Python 3+.

----------
components: Library (Lib)
files: webbrowser.py.patch
keywords: patch
messages: 149666
nosy: phd
priority: normal
severity: normal
status: open
title: Support Chrome in webbrowser.py
type: enhancement
Added file: http://bugs.python.org/file23986/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:01:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 14:01:35 +0000
Subject: [issue12809] Missing new setsockopts in Linux (eg: IP_TRANSPARENT)
In-Reply-To: <1313983612.44.0.0564079708334.issue12809@psf.upfronthosting.co.za>
Message-ID: <E1RbupS-0001MF-BN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 59ea1d1a4137 by Charles-Fran?ois Natali in branch 'default':
Issue #12809: Expose IP_TRANSPARENT in the socket module. Patch by Michael
http://hg.python.org/cpython/rev/59ea1d1a4137

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12809>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:04:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Dec 2011 14:04:09 +0000
Subject: [issue12809] Missing new setsockopts in Linux (eg: IP_TRANSPARENT)
In-Reply-To: <1313983612.44.0.0564079708334.issue12809@psf.upfronthosting.co.za>
Message-ID: <1324130649.97.0.78583463318.issue12809@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks Michael.
I committed a simpler version of your patch.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12809>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:27:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 14:27:11 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1324132031.61.0.321446919372.issue13453@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/1327/steps/test/logs/stdio

======================================================================
ERROR: test_list_active (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 41, in test_list_active
    resp, groups = self.server.list(self.GROUP_PAT)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 596, in list
    resp, lines = self._longcmdstring(command, file)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 513, in _longcmdstring
    resp, list = self._getlongresp(file)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 464, in _getlongresp
    resp = self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_newgroups (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 56, in test_newgroups
    resp, groups = self.server.newgroups(dt)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 565, in newgroups
    resp, lines = self._longcmdstring(cmd, file)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 513, in _longcmdstring
    resp, list = self._getlongresp(file)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 464, in _getlongresp
    resp = self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_over (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 127, in test_over
    resp, count, first, last, name = self.server.group(self.GROUP_NAME)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 649, in group
    resp = self._shortcmd('GROUP ' + name)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 499, in _shortcmd
    return self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_starttls (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 201, in test_starttls
    self.server.starttls()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 986, in starttls
    resp = self._shortcmd('STARTTLS')
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 499, in _shortcmd
    return self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_unknown_command (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 48, in test_unknown_command
    self.server._shortcmd("XYZZY")
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 499, in _shortcmd
    return self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_xhdr (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 144, in test_xhdr
    resp, count, first, last, name = self.server.group(self.GROUP_NAME)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 649, in group
    resp = self._shortcmd('GROUP ' + name)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 499, in _shortcmd
    return self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_xover (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 116, in test_xover
    resp, count, first, last, name = self.server.group(self.GROUP_NAME)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 649, in group
    resp = self._shortcmd('GROUP ' + name)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 499, in _shortcmd
    return self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_zlogin (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 221, in test_zlogin
    user=baduser, password=badpw, usenetrc=False)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 571, in assertRaises
    return context.handle('assertRaises', callableObj, args, kwargs)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 135, in handle
    callable_obj(*args, **kwargs)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 950, in login
    resp = self._shortcmd('authinfo user ' + user)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 499, in _shortcmd
    return self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

======================================================================
ERROR: test_zzquit (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 243, in wrapped
    meth(self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_nntplib.py", line 231, in test_zzquit
    self.server.quit()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 923, in quit
    resp = self._shortcmd('QUIT')
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 499, in _shortcmd
    return self._getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 437, in _getresp
    resp = self._getline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/nntplib.py", line 422, in _getline
    line = self.file.readline()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
    raise IOError("cannot read from timed out object")
OSError: cannot read from timed out object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Sat Dec 17 16:29:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 15:29:43 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324135783.69.0.287983452641.issue11231@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oooh, I missed the important sentence "Accordingly, constructor arguments are interpreted as for bytearray()." The 5 constructors are documented in bytearray doc:

http://docs.python.org/dev/library/functions.html#bytearray

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Sat Dec 17 16:46:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 15:46:33 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324136793.78.0.343145712663.issue13619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 2: improve the test. Try also the user locale encoding if the C locale uses ISO-8859-1 (should improve the code coverage on FreeBSD, Mac OS X and Solaris).

----------
Added file: http://bugs.python.org/file23987/locale_encoding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Sat Dec 17 16:49:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Dec 2011 15:49:20 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324136960.0.0.838571072509.issue13610@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't see a good reason to change this.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:10:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Dec 2011 16:10:19 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324138219.52.0.176500408821.issue13619@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti, lemburg
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:21:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Dec 2011 16:21:30 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324138890.47.0.844223294241.issue13555@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So it seems unlikely to be the explanation.

Victor reproduced in on IRC, and it's indeed an overflow.
The problematic code is in readline_file:
"""
        bigger = self->buf_size << 1;
        if (bigger <= 0) {              /* overflow */
            PyErr_NoMemory();
            return -1;
        }
        newbuf = (char *)realloc(self->buf, bigger);
        if (!newbuf)  {
            PyErr_NoMemory();
            return -1;
        }
"""

self->buf_size is an int, which overflow pretty easily.

>>> 196 * 240000
47040000
>>> 196 * 240000 * 8   # assuming 8 bytes per float
376320000
>>> 2**31
2147483648

Hmmm... A byte is 8 bit, which gives:
>>> 196 * 240000 * 8 * 8
3010560000L
>>> 196 * 240000 * 8 * 8 > 2**31
True

Now, if it works on your box, it's probably due to the compiler optimizing the check away. Since `bigger` is cast to an unsigned 64-bit (size_t) when calling malloc(), it happens to work.
Maybe your distro doesn't build python with -fwrapv.

So, what do you suggest? Should we fix this (Py_ssize_t, overflow check before computation), as in #11564?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:24:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 16:24:08 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324139048.83.0.139382887085.issue13555@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Should we fix this (Py_ssize_t, overflow check before computation), as in #11564?

Yes. Use Py_ssize_t type for the buf_size attribute, and replace "bigger <= 0" (test if an overflow occurred) by "self->buf_size > (PY_SSIZE_T_MAX >> 1)".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:24:44 2011
From: report at bugs.python.org (=?utf-8?b?SsOpcsOpbXkgQW5nZXI=?=)
Date: Sat, 17 Dec 2011 16:24:44 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324139084.74.0.908906173157.issue13530@psf.upfronthosting.co.za>


J?r?my Anger <kidanger at gmail.com> added the comment:

Here is a patch which add the return value of lseek into the documentation.

----------
nosy: +kidanger
Added file: http://bugs.python.org/file23988/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13530>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:35:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 16:35:30 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324139730.65.0.414914156536.issue13555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, I see. It's a bit of a pity not to be able to load files > 1GB, especially on a 64-bit build (!). Perhaps cPickle could be made partly 64-bit compatible? Or at least, indeed, do a proper anti-overflow check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:45:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 16:45:53 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324140353.79.0.30604593903.issue13530@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13530>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:53:52 2011
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sat, 17 Dec 2011 16:53:52 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324140832.35.0.530432774494.issue13610@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

I have done a little bit hd/files archeology and
found some of my comments.

Pointing on number litterals is probably wrong. The fact
is that, this happens with practically any expression. And 
strangely, not all keywords (constructs?) are affected.

>>> 999if 1 else 888
999
>>> """"""if 1 else 888

>>> {1: 'a'}if 1 else 888
{1: 'a'}
>>> 999 if 'a' else 888
999
>>> 999if 'a' else 888
999
>>> 999if 'a'else 888
999
>>> 999if 888else 888
  File "<eta last command>", line 1
    999if 888else 888
             ^
SyntaxError: invalid token
>>> 999if """"""else 888
888

To summarize: The Python syntax does not require an "isolated"
keyword, something like \b<keyword>\b.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:55:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 16:55:15 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324140915.71.0.401286250289.issue13610@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gvanrossum
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:05:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 17:05:39 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324141539.45.0.020826016078.issue13619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested locale_encoding-2.patch on Linux, FreeBSD and Windows: UTF-8 and ISO-8859-1 locales on Linux and FreeBSD, and the cp1252 ANSI code page on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:09:05 2011
From: report at bugs.python.org (brendel)
Date: Sat, 17 Dec 2011 17:09:05 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324141745.91.0.85783112134.issue11231@psf.upfronthosting.co.za>


brendel <brice.berna at gmail.com> added the comment:

Here is a patch for the docstring of bytes and bytesarray.

----------
nosy: +brendel
Added file: http://bugs.python.org/file23989/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:17:58 2011
From: report at bugs.python.org (brendel)
Date: Sat, 17 Dec 2011 17:17:58 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324142278.03.0.827324890086.issue11231@psf.upfronthosting.co.za>


Changes by brendel <brice.berna at gmail.com>:


Removed file: http://bugs.python.org/file23989/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:20:56 2011
From: report at bugs.python.org (brendel)
Date: Sat, 17 Dec 2011 17:20:56 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324142456.3.0.482433546597.issue11231@psf.upfronthosting.co.za>


Changes by brendel <brice.berna at gmail.com>:


Added file: http://bugs.python.org/file23990/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:21:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Dec 2011 17:21:27 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324142487.52.0.649218135839.issue13610@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>>> 999if 888else 888
  File "<eta last command>", line 1
    999if 888else 888
             ^
SyntaxError: invalid token

This might be because 888e5 is a valid expression, so the 'e' is parsed as part of the number rather than a separate token.

>>> 999 if 888.else 888
  File "<stdin>", line 1
    999 if 888.else 888
               ^
SyntaxError: invalid token
>>> 999 if 888jelse 888
999

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:34:49 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:34:49 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
Message-ID: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>


New submission from Boris FELD <lothiraldan at gmail.com>:

Hello everyone, I juste tried to launch the stringbench on python3.2 and python3.3 dev versions and some unicode tests run slower in python3.3 than in python3.2.

I cc the two raw output of both runs. I also extracted most interesting data (all the tests with more than 20% of performance regression):
- ("A"*1000).find("B") (*1000): -30.379747%
- "Hello\t   \t".rstrip() (*1000): -33.333333%
- "this\nis\na\ntest\n".rsplit("\n") (*1000): -23.437500%
- "\nHello!\n".strip() (*1000): -33.333333%
- dna.split("ACTAT") (*10): -21.066667%
- "Andrew".endswith("w") (*1000): -23.529412%
- "...text.with.2000.lines...replace("\n", " ") (*10): -37.668161%
- "\t   \tHello".rstrip() (*1000): -33.333333%
- ("A"*1000).rpartition("A") (*1000): -21.212121%
- ("Here are some words. "*2).split() (*1000): -22.105263%
- "Hello!\n".rstrip() (*1000): -35.714286%
- "B" in "A"*1000 (*1000): -32.089552%
- "Hello!\n".strip() (*1000): -35.714286%
- "\nHello!".strip() (*1000): -28.571429%
- "this\nis\na\ntest\n".split("\n") (*1000): -23.437500%
- "Andrew".startswith("A") (*1000): -20.588235%
- "\nHello!".rstrip() (*1000): -35.714286%
- "Andrew".endswith("Andrew") (*1000): -22.857143%
- "Andrew".endswith("Anders") (*1000): -23.529412%
- "The %(k1)s is %(k2)s the %(k3)s."%{"k1":"x","k2":"y","k3":"z",} (*1000): -49.411765%
- "Andrew".startswith("Anders") (*1000): -23.529412%
- "this--is--a--test--of--the--emergency--broadcast--system".split("--") (*1000): -22.429907%
- "Andrew"+"Dalke" (*1000): -23.076923%

----------
assignee: collinwinter
components: Benchmarks
files: stringbench_log_cpython3.2
messages: 149681
nosy: Boris.FELD, collinwinter
priority: normal
severity: normal
status: open
title: Unicode performance regression in python3.3 vs python3.2
type: performance
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23991/stringbench_log_cpython3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:35:12 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:35:12 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324143312.48.0.71010942597.issue13621@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file23992/stringbench_log_cpython3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:35:42 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:35:42 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324143342.97.0.0854873426466.issue13621@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file23993/stringbench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:39:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 17:39:40 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324143580.95.0.990262270291.issue13621@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: collinwinter -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:41:23 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 17 Dec 2011 17:41:23 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324143683.47.0.698162180627.issue13621@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks, this is a known issue. I'm not too worried, since they are fairly artificial. In the cases I've looked at, I don't think anything can be done about that.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:43:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 17:43:39 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324143819.41.0.0460894888765.issue13621@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:44:58 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:44:58 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324143898.89.0.458993451244.issue13621@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Removed file: http://bugs.python.org/file23993/stringbench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:45:19 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:45:19 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324143919.84.0.537415001972.issue13621@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file23994/compare.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:53:50 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:53:50 +0000
Subject: [issue13622] Bytes performance regression in python3.3 vs python3.2
Message-ID: <1324144430.24.0.0465660737169.issue13622@psf.upfronthosting.co.za>


New submission from Boris FELD <lothiraldan at gmail.com>:

Hello everyone, I juste tried to launch the stringbench on python3.2 and python3.3 dev versions and some bytes tests run slower in python3.3 than in python3.2.

I cc the two raw output of both runs. I also extracted most interesting data (all the tests with more than 20% of performance regression):
- (b"A"*1000).find(b"B") (*1000): -30.379747%
- b"Hello\t   \t".rstrip() (*1000): -33.333333%
- b"this\nis\na\ntest\n".rsplit(b"\n") (*1000): -23.437500%
- b"\nHello!\n".strip() (*1000): -33.333333%
- dna.split(b"ACTAT") (*10): -21.066667%
- b"Andrew".endswith(b"w") (*1000): -23.529412%
- b"...text.with.2000.lines...replace(b"\n", b" ") (*10): -37.668161%
- b"\t   \tHello".rstrip() (*1000): -33.333333%
- (b"A"*1000).rpartition(b"A") (*1000): -21.212121%
- (b"Here are some words. "*2).split() (*1000): -22.105263%
- b"this\nis\na\ntest\n".split(b"\n") (*1000): -23.437500%
- b"Hello!\n".rstrip() (*1000): -35.714286%
- b"B" in b"A"*1000 (*1000): -32.089552%
- b"Hello!\n".strip() (*1000): -35.714286%
- b"\nHello!".strip() (*1000): -28.571429%
- b"Andrew".startswith(b"A") (*1000): -20.588235%
- b"\nHello!".rstrip() (*1000): -35.714286%
- b"Andrew".endswith(b"Andrew") (*1000): -22.857143%
- b"Andrew".endswith(b"Anders") (*1000): -23.529412%
- b"Andrew".startswith(b"Anders") (*1000): -23.529412%
- b"this--is--a--test--of--the--emergency--broadcast--system".split(b"--") (*1000): -22.429907%
- b"Andrew"+b"Dalke" (*1000): -23.076923%

Hope it help

----------
assignee: collinwinter
components: Benchmarks
files: stringbench_log_cpython3.2
messages: 149683
nosy: Boris.FELD, collinwinter
priority: normal
severity: normal
status: open
title: Bytes performance regression in python3.3 vs python3.2
type: performance
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23995/stringbench_log_cpython3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13622>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:54:06 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:54:06 +0000
Subject: [issue13622] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324144430.24.0.0465660737169.issue13622@psf.upfronthosting.co.za>
Message-ID: <1324144446.04.0.683879040864.issue13622@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file23996/stringbench_log_cpython3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13622>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:54:16 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:54:16 +0000
Subject: [issue13622] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324144430.24.0.0465660737169.issue13622@psf.upfronthosting.co.za>
Message-ID: <1324144456.25.0.758123859999.issue13622@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file23997/compare.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13622>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:58:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 17:58:09 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324144689.53.0.0631278277453.issue13621@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Sorted and grouped results. "replace", "find" and "concat" should be easy to fix, "format" is a little bit more complex, "strip" and "split" depends on "find" performance and require to scan the substring to ensure that the result is canonical (except if inputs are all ASCII, which is the case in these examples).

replace:

- "...text.with.2000.lines...replace("\n", " ") (*10): -37.668161%
- "...text.with.2000.lines...replace("\n", " ") (*10): -37.668161%

find:

- ("A"*1000).find("B") (*1000): -30.379747%
- "Andrew"+"Dalke" (*1000): -23.076923%- ("A"*1000).find("B") (*1000): -30.379747%

- "Andrew".startswith("A") (*1000): -20.588235%
- "Andrew".startswith("Anders") (*1000): -23.529412%
- "Andrew".startswith("A") (*1000): -20.588235%
- "Andrew".startswith("Anders") (*1000): -23.529412%

- "Andrew".endswith("w") (*1000): -23.529412%
- "Andrew".endswith("Andrew") (*1000): -22.857143%
- "Andrew".endswith("Anders") (*1000): -23.529412%
- "Andrew".endswith("w") (*1000): -23.529412%
- "Andrew".endswith("Andrew") (*1000): -22.857143%
- "Andrew".endswith("Anders") (*1000): -23.529412%

- "B" in "A"*1000 (*1000): -32.089552%
- "B" in "A"*1000 (*1000): -32.089552%

concat:

- "Andrew"+"Dalke" (*1000): -23.076923%

format:

- "The %(k1)s is %(k2)s the %(k3)s."%{"k1":"x","k2":"y","k3":"z",} (*1000): -49.411765%
- "The %(k1)s is %(k2)s the %(k3)s."%{"k1":"x","k2":"y","k3":"z",} (*1000): -49.411765%

strip:

- "\nHello!\n".strip() (*1000): -33.333333%
- "Hello!\n".strip() (*1000): -35.714286%
- "\nHello!".strip() (*1000): -28.571429%
- "\nHello!\n".strip() (*1000): -33.333333%
- "Hello!\n".strip() (*1000): -35.714286%
- "\nHello!".strip() (*1000): -28.571429%

- "Hello\t   \t".rstrip() (*1000): -33.333333%
- "\t   \tHello".rstrip() (*1000): -33.333333%
- "Hello!\n".rstrip() (*1000): -35.714286%
- "\nHello!".rstrip() (*1000): -35.714286%
- "Hello\t   \t".rstrip() (*1000): -33.333333%
- "\t   \tHello".rstrip() (*1000): -33.333333%
- "Hello!\n".rstrip() (*1000): -35.714286%
- "\nHello!".rstrip() (*1000): -35.714286%

split:

- dna.split("ACTAT") (*10): -21.066667%
- ("Here are some words. "*2).split() (*1000): -22.105263%
- "this\nis\na\ntest\n".split("\n") (*1000): -23.437500%
- "this--is--a--test--of--the--emergency--broadcast--system".split("--") (*1000): -22.429907%
- dna.split("ACTAT") (*10): -21.066667%
- ("Here are some words. "*2).split() (*1000): -22.105263%
- "this\nis\na\ntest\n".split("\n") (*1000): -23.437500%
- "this--is--a--test--of--the--emergency--broadcast--system".split("--") (*1000): -22.429907%

- "this\nis\na\ntest\n".rsplit("\n") (*1000): -23.437500%
- "this\nis\na\ntest\n".rsplit("\n") (*1000): -23.437500%

- ("A"*1000).rpartition("A") (*1000): -21.212121%
- ("A"*1000).rpartition("A") (*1000): -21.212121%

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:07:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:07:11 +0000
Subject: [issue13622] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324144430.24.0.0465660737169.issue13622@psf.upfronthosting.co.za>
Message-ID: <1324145231.49.0.599063292197.issue13622@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Sorted and grouped results. "replace", "find" and "concat" should be easy to fix, "strip" and "split" depend on "find" performance.


replace:

- b"...text.with.2000.lines...replace(b"\n", b" ") (*10): -37.668161%

find:

- (b"A"*1000).find(b"B") (*1000): -30.379747%

- b"Andrew".startswith(b"A") (*1000): -20.588235%
- b"Andrew".startswith(b"Anders") (*1000): -23.529412%

- b"Andrew".endswith(b"w") (*1000): -23.529412%
- b"Andrew".endswith(b"Andrew") (*1000): -22.857143%
- b"Andrew".endswith(b"Anders") (*1000): -23.529412%

- b"B" in b"A"*1000 (*1000): -32.089552%

concat:

- b"Andrew"+b"Dalke" (*1000): -23.076923%

strip:

- b"\nHello!\n".strip() (*1000): -33.333333%
- b"Hello!\n".strip() (*1000): -35.714286%
- b"\nHello!".strip() (*1000): -28.571429%

- b"Hello\t   \t".rstrip() (*1000): -33.333333%
- b"\t   \tHello".rstrip() (*1000): -33.333333%
- b"Hello!\n".rstrip() (*1000): -35.714286%
- b"\nHello!".rstrip() (*1000): -35.714286%

split:

- dna.split(b"ACTAT") (*10): -21.066667%
- (b"Here are some words. "*2).split() (*1000): -22.105263%
- b"this\nis\na\ntest\n".split(b"\n") (*1000): -23.437500%
- b"this--is--a--test--of--the--emergency--broadcast--system".split(b"--") (*1000): -22.429907%

- b"this\nis\na\ntest\n".rsplit(b"\n") (*1000): -23.437500%

- (b"A"*1000).rpartition(b"A") (*1000): -21.212121%

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13622>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:07:26 2011
From: report at bugs.python.org (misdre)
Date: Sat, 17 Dec 2011 18:07:26 +0000
Subject: [issue13561] os.listdir documentation should mention surrogateescape
In-Reply-To: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>
Message-ID: <1324145246.02.0.0221603578014.issue13561@psf.upfronthosting.co.za>


misdre <misdre+python at gmail.com> added the comment:

Added a small patch to mention surrogateescape and PEP 383.

----------
keywords: +patch
nosy: +misdre
Added file: http://bugs.python.org/file23998/listdir-pep383.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13561>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:08:09 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:08:09 +0000
Subject: [issue13622] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324144430.24.0.0465660737169.issue13622@psf.upfronthosting.co.za>
Message-ID: <1324145289.99.0.179710937632.issue13622@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

Forgot to describe my environment:
Mac OS X 10.6.8
GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
CPython3.3 revision ea421c534305
CPython3.2 revision 0b86da9d6964

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13622>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:08:25 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:08:25 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324145305.65.0.138041799248.issue13621@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

Forgot to describe my environment:
Mac OS X 10.6.8
GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
CPython3.3 revision ea421c534305
CPython3.2 revision 0b86da9d6964

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:22:50 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:22:50 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
Message-ID: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>


New submission from Boris FELD <lothiraldan at gmail.com>:

Hello everyone, I juste tried to launch the stringbench on python3.2 and python3.3 dev versions and some bytes tests run slower in python3.3 than in python3.2.

I cc the two raw output of both runs. I also extracted most interesting data (all the tests with more than 20% of performance regression):
- (b"A"*1000).rfind(b"A") (*1000): -70.103093%
- (b"A"*1000).find(b"B") (*1000): -48.372093%
- (b"A"*1000).rindex(b"A") (*1000): -68.888889%
- s=b"ABC"*33; (s+b"E"+(b"D"+s)*500).rfind(s+b"E") (*100): -28.982301%
- (b"C"+b"AB"*300).rfind(b"CA") (*1000): -29.565217%
- (b"AB"*1000).index(b"AB") (*1000): -68.539326%
- b"Andrew".endswith(b"w") (*1000): -21.212121%
- (b"A"*1000).index(b"A") (*1000): -71.111111%
- (b"BC"+b"AB"*300).rfind(b"BC") (*1000): -42.788462%
- b"Andrew".startswith(b"Andrew") (*1000): -20.588235%
- (b"AB"*1000).find(b"AB") (*1000): -69.318182%
- (b"AB"*1000).rfind(b"AB") (*1000): -69.791667%
- (b"A"*1000).rfind(b"B") (*1000): -37.988827%
- (b"AB"*300+"C").index(b"BC") (*1000): -28.750000%
- b"B" in b"A"*1000 (*1000): -24.479167%
- (b"AB"*300+"CA").find(b"CA") (*1000): -33.673469%
- (b"AB"*1000).rindex(b"AB") (*1000): -67.777778%
- (b"C"+"AB"*300).rindex(b"CA") (*1000): -29.017857%
- (b"AB"*300+"C").find(b"BC") (*1000): -28.451883%
- b"Andrew".startswith(b"A") (*1000): -21.212121%
- b"Andrew".startswith(b"Anders") (*1000): -21.212121%
- (b"A"*1000).partition(b"B") (*1000): -30.656934%
- (b"AB"*1000).rfind(b"CA") (*1000): -20.603015%
- (b"AB"*1000).rfind(b"BC") (*1000): -35.645472%
- (b"A"*1000).find(b"A") (*1000): -70.454545%

My environment is:
Mac OS X 10.6.8
GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
CPython3.3 revision ea421c534305
CPython3.2 revision 0b86da9d6964

----------
assignee: collinwinter
components: Benchmarks
files: stringbench_log_cpython3.2
messages: 149689
nosy: Boris.FELD, collinwinter
priority: normal
severity: normal
status: open
title: Bytes performance regression in python3.3 vs python3.2
type: performance
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23999/stringbench_log_cpython3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:23:24 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:23:24 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324146204.02.0.147870687791.issue13623@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file24000/iobench_log_python3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:23:38 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:23:38 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324146218.06.0.437324558587.issue13623@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file24001/compare.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:25:46 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:25:46 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324146346.4.0.768522548959.issue13623@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Removed file: http://bugs.python.org/file24000/iobench_log_python3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:25:58 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:25:58 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324146358.15.0.573124910276.issue13623@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


Added file: http://bugs.python.org/file24002/stringbench_log_cpython3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:38:21 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 17 Dec 2011 18:38:21 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324147101.14.0.0973647756715.issue13616@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The only way of this thing actually happening is if the GC link list has actually a cycle.

Without a testcase to try to reproduce, it can't be debugged.

David, can you reproduce this consistently, even if it takes a few hours?.

As Amaury pointed out, if you have tons of objects, GC can take a while. And if your memory is paged out to swap, this can actually be VERY slow.

To know if this is actually a infinite loop, when you think it is stuck in the loop, just check current value of "gc" and set a breakpoint for that value in the loop. So GDB will stop again if "gc" gets the same value again and so we are actually in a loop.

In the meantime, check your page-in rate. If you are paging-in furiously, you are not in a loop, you are (mechanically slow) bringing objects back to memory.

Can you tell us how big your python process is (in memory), how much physical RAM you have, and if some other processes are competing for memory?.

If you can confirm that we are actually in an infinite loop... there is little that we can do without some testcase we can reproduce. The key here is that if you can reproduce, we can slowly move forward.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:42:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:42:06 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324147326.26.0.433939224649.issue13623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Grouped results.

find (first):

- (b"A"*1000).find(b"A")    : -70%
- (b"A"*1000).rfind(b"A")   : -70%
- (b"A"*1000).index(b"A")   : -71%
- (b"A"*1000).rindex(b"A")  : -68%

- (b"AB"*1000).index(b"AB") : -68%
- (b"AB"*1000).rindex(b"AB"): -67%
- (b"AB"*1000).find(b"AB")  : -69%
- (b"AB"*1000).rfind(b"AB") : -69%

- b"Andrew".startswith(b"Andrew"): -20%
- b"Andrew".startswith(b"A")     : -21%
- b"Andrew".startswith(b"Anders"): -21%

- b"Andrew".endswith(b"w"): -21%

find (last):

- (b"AB"*300+"CA").find(b"CA")  : -33%
- (b"C"+"AB"*300).rindex(b"CA") : -29%
- (b"AB"*300+"C").find(b"BC")   : -28%
- (b"AB"*300+"C").index(b"BC")  : -28%
- (b"C"+b"AB"*300).rfind(b"CA") : -29%
- (b"BC"+b"AB"*300).rfind(b"BC"): -42%
- s=b"ABC"*33; (s+b"E"+(b"D"+s)*500).rfind(s+b"E"): -28%

find (not found):

- (b"A"*1000).find(b"B")    : -48%
- (b"A"*1000).rfind(b"B")   : -37%
- (b"AB"*1000).rfind(b"CA") : -20%
- (b"AB"*1000).rfind(b"BC") : -35%

others:

- b"B" in b"A"*1000           : -24%
- (b"A"*1000).partition(b"B") : -30%

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:42:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:42:42 +0000
Subject: [issue13622] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324144430.24.0.0465660737169.issue13622@psf.upfronthosting.co.za>
Message-ID: <1324147362.1.0.258913837219.issue13622@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Boris.FELD told me that there was a bug in compare.py: all numbers are related to Unicode (see #13621), not bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13622>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:42:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:42:50 +0000
Subject: [issue13622] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324144430.24.0.0465660737169.issue13622@psf.upfronthosting.co.za>
Message-ID: <1324147370.58.0.626007544257.issue13622@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13622>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:43:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:43:06 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324147386.62.0.90044294649.issue13623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also the issue #13621 for results on Unicode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:43:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:43:19 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324147399.96.0.872727434912.issue13621@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also the issue #13623 for results on bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:49:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:49:12 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
Message-ID: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

iobench benchmarking tool showed that the UTF-8 encoder is slower in Python 3.3 than Python 3.2. The performance depends on the characters of the input string:

 * 8x faster (!) for a string of 50.000 ASCII characters
 * 1.5x slower for a string of 50.000 UCS-1 characters
 * 2.5x slower for a string of 50.000 UCS-2 characters

The bottleneck looks to be the the PyUnicode_READ() macro.

 * Python 3.2: s[i++]
 * Python 3.3: PyUnicode_READ(kind, data, i++)

Because encoding string to UTF-8 is a very common operation, performances do matter. Antoine suggests to have different versions of the function for each Unicode kind (1, 2, 4).

----------
components: Unicode
messages: 149695
nosy: ezio.melotti, haypo, pitrou
priority: normal
severity: normal
status: open
title: UTF-8 encoder performance regression in python3.3
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:56:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:56:22 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324148182.92.0.474715712092.issue13623@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:56:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:56:37 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324148197.28.0.45607730678.issue13621@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 19:58:45 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 17 Dec 2011 18:58:45 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324148325.3.0.38027173925.issue13624@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/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:02:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Dec 2011 19:02:13 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324148533.23.0.438531406436.issue13621@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> collinwinter
components: +Unicode
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:02:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Dec 2011 19:02:28 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324148548.86.0.296107873289.issue13623@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/issue13623>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:13:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 19:13:17 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324149197.78.0.378407605424.issue13621@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Just a note: performance reports shouldn't be assigned to the "benchmarks" category, except if the problem is in the benchmarks themselves.

----------
assignee: collinwinter -> 
components: +Interpreter Core -Benchmarks
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:25:44 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 17 Dec 2011 19:25:44 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324149944.93.0.444322069185.issue13586@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

On Linux using 2.7.1 and 3.2, the Replace dialog does not contain the selected text in the Find field.

The find functionality that copies the selected text was introduced in 868ff0dfabd2 on 2002-11-06. Unfortunately it wasn't added to the Replace Dialog code. The attached patch (against 3.3a0) adds this functionality to Replace Dialog and also removes some non-functional (arguably broken) code.

----------
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file24003/issue13586.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:26:00 2011
From: report at bugs.python.org (=?utf-8?b?SsOpcsOpbXkgQW5nZXI=?=)
Date: Sat, 17 Dec 2011 19:26:00 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1324149960.63.0.249593044999.issue10951@psf.upfronthosting.co.za>


J?r?my Anger <kidanger at gmail.com> added the comment:

I've fixed two more warnings, see my patch. (gcc 4.6.2)

----------
nosy: +kidanger
Added file: http://bugs.python.org/file24004/fix_2warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:37:47 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 17 Dec 2011 19:37:47 +0000
Subject: [issue8231] Unable to run IDLE without write-access to config
	directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1324150667.83.0.434618804942.issue8231@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
components: +IDLE -Library (Lib), Windows
nosy: +serwy
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:50:12 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 17 Dec 2011 19:50:12 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324151412.21.0.479618520532.issue13624@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please provide your exact testing procedure? Standard iobench.py doesn't support testing for separate ASCII, UCS-1 and UCS-2 data, so you must have used some other tool. Exact code, command line parameters, hardware description and timing results would be appreciated.

Looking at the encoder, I think the first thing to change is to reduce the over-allocation for UCS-1 and UCS-2 strings. This may or may not help the run-time, but should reduce memory consumption.

I wonder whether making two passes over the string (one to compute the size, and the other one with an allocated result buffer) could improve the performance.

If there is further special-casing, I'd only special-case UCS-1. I doubt that the _READ() macro really is the bottleneck, and would rather expect that loop unrolling can help. Because of unallowed surrogates, unrolling is not practical for UCS-2.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:53:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Dec 2011 19:53:43 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324151623.7.0.969522156866.issue13610@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1 I'm with Mark, Georg, and Benjamin on this one.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 21:07:44 2011
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sat, 17 Dec 2011 20:07:44 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324152464.87.0.553239202501.issue13610@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

> Ezio Melotti
Good catch.

I'm not complaining. I just find funny to see the number of editors
not "colorizing" this kind of Python valid expressions. (IDLE included)

For me, subject close.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 21:13:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 20:13:54 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324152834.25.0.0676820511742.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Can you please provide your exact testing procedure?

Here you have.

$ cat bench.sh 
echo -n "ASCII: "
./python -m timeit 'x="A"*50000' 'x.encode("utf-8")'
echo -n "UCS-1: "
./python -m timeit 'x="\xe9"*50000' 'x.encode("utf-8")'
echo -n "UCS-2: "
./python -m timeit 'x="\u20ac"*50000' 'x.encode("utf-8")'
echo -n "UCS-4: "
./python -m timeit 'x="\U0010FFFF"*50000' 'x.encode("utf-8")'

Python 3.2:

ASCII: 10000 loops, best of 3: 31.5 usec per loop
UCS-1: 10000 loops, best of 3: 62.2 usec per loop
UCS-2: 10000 loops, best of 3: 91.3 usec per loop
UCS-4: 1000 loops, best of 3: 267 usec per loop

Python 3.3:

ASCII: 100000 loops, best of 3: 3.56 usec per loop
UCS-1: 10000 loops, best of 3: 98.2 usec per loop
UCS-2: 1000 loops, best of 3: 201 usec per loop
UCS-4: 10000 loops, best of 3: 168 usec per loop

Comparaison:

ASCII: Python 3.3 is 8.8x faster
UCS-1: Python 3.3 is 1.6x SLOWER
UCS-2: Python 3.3 is 2.2x SLOWER
UCS-4: Python 3.3 is 1.6x faster

iobench uses more realistic data.

> Standard iobench.py doesn't support testing for separate ASCII,
> UCS-1 and UCS-2 data, so you must have used some other tool.

According to Antoine, iobench is slower because of the UTF-8 encoder.

> hardware description

i7-2600 CPU @ 3.40GHz (8 cores) with 12 GB of RAM.

> I doubt that the _READ() macro really is the bottleneck

It is the only difference between Python 3.2 and 3.3. Or did I miss something? The body of the loop is very small, so each instruction is important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 21:24:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 20:24:44 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324153484.48.0.638466959595.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, Antoine told me that I missed the -s command line argument to timeit:

$ cat bench.sh 
echo -n "ASCII: "
./python -m timeit -s 'x="A"*50000' 'x.encode("utf-8")'
echo -n "UCS-1: "
./python -m timeit -s 'x="\xe9"*50000' 'x.encode("utf-8")'
echo -n "UCS-2: "
./python -m timeit -s 'x="\u20ac"*50000' 'x.encode("utf-8")'
echo -n "UCS-4: "
./python -m timeit -s 'x="\U0010FFFF"*50000' 'x.encode("utf-8")'

Python 3.2:

ASCII: 10000 loops, best of 3: 28.2 usec per loop
UCS-1: 10000 loops, best of 3: 59.1 usec per loop
UCS-2: 10000 loops, best of 3: 88.8 usec per loop
UCS-4: 1000 loops, best of 3: 254 usec per loop

Python 3.3:

ASCII: 1000000 loops, best of 3: 2.01 usec per loop
UCS-1: 10000 loops, best of 3: 95.8 usec per loop
UCS-2: 1000 loops, best of 3: 201 usec per loop
UCS-4: 10000 loops, best of 3: 151 usec per loop

The results look to be similar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 21:51:46 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 17 Dec 2011 20:51:46 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324155106.87.0.447985146147.issue13624@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/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:15:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Dec 2011 21:15:56 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1324156556.8.0.325197300699.issue13610@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'll close this then.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13610>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:19:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 21:19:16 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324156756.32.0.745943145245.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 3.2 (narrow):

ASCII: 10000 loops, best of 3: 28.2 usec per loop
UCS-1: 10000 loops, best of 3: 59.1 usec per loop
UCS-2: 10000 loops, best of 3: 88.8 usec per loop
UCS-4: 1000 loops, best of 3: 254 usec per loop

Python 3.2 (wide):

ASCII: 10000 loops, best of 3: 28.5 usec per loop
UCS-1: 10000 loops, best of 3: 60.8 usec per loop
UCS-2: 10000 loops, best of 3: 114 usec per loop
UCS-4: 10000 loops, best of 3: 129 usec per loop

Python 3.3 (specialized UTF-8 encoder):

ASCII: 100000 loops, best of 3: 2 usec per loop
UCS-1: 10000 loops, best of 3: 45.4 usec per loop
UCS-2: 10000 loops, best of 3: 96.4 usec per loop
UCS-4: 10000 loops, best of 3: 140 usec per loop

Attached patch adds UTF-8 encoder for UCS1, UCS2 and UCS4.

----------
keywords: +patch
Added file: http://bugs.python.org/file24005/utf8_encoder.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:25:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 21:25:34 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324157134.42.0.274965985428.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> 8x faster (!) for a string of 50.000 ASCII characters

Oooh, it's just faster because encoding ASCII to UTF-8 is now O(1). The ASCII data is shared with the UTF-8 data thanks to the PEP 393!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:38:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 21:38:29 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <E1Rc1xb-0001Rf-JD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d7862e855274 by Victor Stinner in branch '3.2':
Issue #10951: Fix a compiler warning in timemodule.c
http://hg.python.org/cpython/rev/d7862e855274

New changeset 49b85dba251d by Victor Stinner in branch 'default':
Issue #10951: Fix compiler warnings in timemodule.c and unicodeobject.c
http://hg.python.org/cpython/rev/49b85dba251d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:53:02 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 21:53:02 +0000
Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux
In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za>
Message-ID: <1324158782.35.0.744618111676.issue5492@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

The problem still exists in trunk with 3.2 and 3.3.

----------
nosy: +Boris.FELD
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5492>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:13:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 22:13:53 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <E1Rc2Vs-0003u3-25@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 46c418d8a480 by Victor Stinner in branch '3.2':
Issue #13530: Document os.lseek() result
http://hg.python.org/cpython/rev/46c418d8a480

New changeset b05caa600c40 by Victor Stinner in branch 'default':
Issue #13530: Document os.lseek() result
http://hg.python.org/cpython/rev/b05caa600c40

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13530>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:14:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 22:14:09 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324160049.92.0.582759507474.issue13530@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/issue13530>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:14:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 22:14:18 +0000
Subject: [issue13530] Docs for os.lseek neglect to mention what it returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324160058.93.0.80948369742.issue13530@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks for the patch J?r?my.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13530>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:15:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Dec 2011 22:15:35 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324160135.72.0.615407982671.issue13555@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch which should fix this. However, I'm unable to test it.

----------
keywords: +patch
Added file: http://bugs.python.org/file24006/pickle_overflow.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:16:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 22:16:58 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <E1Rc2Yr-0004In-0F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset beac7d6c7be4 by Victor Stinner in branch '3.2':
Issue #11231: Fix bytes and bytearray docstrings
http://hg.python.org/cpython/rev/beac7d6c7be4

New changeset dc670add1e28 by Victor Stinner in branch 'default':
Issue #11231: Fix bytes and bytearray docstrings
http://hg.python.org/cpython/rev/dc670add1e28

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:25:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 22:25:29 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324160729.5.0.326221700697.issue13555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think there's a problem here:

+    self->data = realloc(self->data, self->size * sizeof(PyObject *));
+    if (self->data == NULL)
         goto nomemory;

If realloc() fails, the old data pointer is lost and therefore will never get free()ed.

Same for:

+        self->buf = (char *)realloc(self->buf, self->buf_size);

Here:

-        int *marks;
-        s=self->marks_size+20;
-        if (s <= self->num_marks) s=self->num_marks + 1;
+        size_t alloc;
+        Py_ssize_t *marks;
+
+        /* Use the size_t type to check for overflow. */
+        alloc = ((size_t)self->num_marks << 1) + 20;

It seems you are changing the overallocation algorithm (from additive to multiplicative). I'm not sure it should be in the scope of the patch, although multiplicative overallocation is generally better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:31:45 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sat, 17 Dec 2011 22:31:45 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324161105.28.0.857975505912.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Hi,

Here is the patch I propose for this issue. This is my first attempt to contribute to Python, so please don't hit me too hard if I did something wrong. :)

When browsing the source code of complexobject.c, I also noticed that the return values of the _Py_c_quot and _Py_c_pow (which return zero in case of error) weren't documented at 

http://docs.python.org/dev/c-api/complex.html#_Py_c_quot

----------
nosy: +arnaudc
Added file: http://bugs.python.org/file24007/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:46:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Dec 2011 22:46:05 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324161965.84.0.037623907848.issue13555@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

New version.

----------
Added file: http://bugs.python.org/file24008/pickle_overflow-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sat Dec 17 23:47:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 22:47:05 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324162025.27.0.657002744237.issue13522@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a typo in the patch: it's PyErr_Occurred (two r's), not PyErr_Occured.
Otherwise, looks good to me.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 00:05:47 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sat, 17 Dec 2011 23:05:47 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324163147.48.0.303985586938.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

I fixed the typo and the markup.

----------
Added file: http://bugs.python.org/file24009/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 00:33:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 23:33:03 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324164783.53.0.777735680262.issue13623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> (b"A"*1000).find(b"A")    : -70%

This one is a performance regression introduced by #12170. Attached patch checks object type before trying a conversion to size_t instead of catching an exception.

----------
keywords: +patch
Added file: http://bugs.python.org/file24010/bytes_find.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sun Dec 18 00:33:42 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 23:33:42 +0000
Subject: [issue10805] traceback.print_exception throws AttributeError when
	exception is None
In-Reply-To: <1293978231.38.0.946265028499.issue10805@psf.upfronthosting.co.za>
Message-ID: <1324164822.23.0.48130500705.issue10805@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

I add a test to test_traceback.py for this bug. Bug is confirmed on python 3.2 and python3.3. I use 2.x behavior as reference.

I don't know if we should add an assertion in traceback.print_exception or traceback._iter_chain, so I add the test for traceback.print_exception.

----------
keywords: +patch
nosy: +Boris.FELD
Added file: http://bugs.python.org/file24011/new_traceback_test_print_traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10805>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:00:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:00:06 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324166406.08.0.695790721964.issue13623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

bytes_find.patch only works for Python int, not object with the __index__ method. My new patch (bytes_find-2.patch) uses PyNumber_Check() instead of PyLong_Check() to be more generic. It fixes also a different issue: raise the same ValueError than bytes.find(-1) on overflow error.

----------
Added file: http://bugs.python.org/file24012/bytes_find-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:03:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:03:17 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324166597.79.0.552952981868.issue13623@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24012/bytes_find-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:03:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:03:27 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324166607.86.0.288498351485.issue13623@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file24013/bytes_find-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:17:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 00:17:55 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <E1Rc4Ru-0006bm-07@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 75648db1b3f3 by Victor Stinner in branch 'default':
Issue #13623: Fix a performance regression introduced by issue #12170 in
http://hg.python.org/cpython/rev/75648db1b3f3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:17:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 00:17:55 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <E1Rc4Ru-0006bm-0f@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 75648db1b3f3 by Victor Stinner in branch 'default':
Issue #13623: Fix a performance regression introduced by issue #12170 in
http://hg.python.org/cpython/rev/75648db1b3f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:18:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:18:54 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1324167534.18.0.347804745968.issue12170@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New changeset 75648db1b3f3 by Victor Stinner in branch 'default':
http://hg.python.org/cpython/rev/75648db1b3f3
Issue #13623: Fix a performance regression introduced by issue #12170 in bytes.find() and handle correctly OverflowError (raise the same ValueError than the error for -1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:29:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 00:29:12 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <E1Rc4ce-0007Ke-FZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 68cbf6551710 by Antoine Pitrou in branch '3.2':
Issue #13522: document error return values of some float and complex C API functions.
http://hg.python.org/cpython/rev/68cbf6551710

New changeset 1f096611baf4 by Antoine Pitrou in branch 'default':
Issue #13522: document error return values of some float and complex C API functions.
http://hg.python.org/cpython/rev/1f096611baf4

New changeset 059e4d752fbe by Antoine Pitrou in branch '2.7':
Issue #13522: document error return values of some float and complex C API functions.
http://hg.python.org/cpython/rev/059e4d752fbe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:29:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:29:18 +0000
Subject: [issue13623] Bytes performance regression in python3.3 vs python3.2
In-Reply-To: <1324146169.52.0.308981690737.issue13623@psf.upfronthosting.co.za>
Message-ID: <1324168158.69.0.886661295811.issue13623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I checked stringbench: there is no more performance regression (difference of more than 20%).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13623>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:30:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 00:30:09 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324168209.38.0.567769453516.issue13522@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed now. Thank you for the patch!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:46:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:46:36 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324169196.77.0.976411153859.issue13522@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_Py_c_pow() doc is wrong:

+   If :attr:`exp.imag` is not null, or :attr:`exp.real` is negative,
+   this method returns zero and sets :c:data:`errno` to :c:data:`EDOM`.

The function only fails if num=0 and exp.real < 0 or if num=0 and exp.imag != 0.

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:59:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:59:59 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324169999.98.0.690551691801.issue13621@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> "...text.with.2000.lines...replace("\n", " ") (*10): -37.668161%

I also noticed a difference between Python 3.2 and 3.3, but Python 3.3 is 13% *faster* (and not slower). This benchmark is not really representative because stringbench only tests .replace() with ASCII. Replace requires to scan the result to check the next maximum character, except for ASCII. So expect a performance regression... except for ASCII.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:13:14 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sun, 18 Dec 2011 01:13:14 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324170794.82.0.350430525613.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Fixed.

----------
Added file: http://bugs.python.org/file24014/diff_complex_rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:43:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 01:43:40 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <E1Rc5mr-0002u9-49@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c802bfc8acfc by Victor Stinner in branch 'default':
Issue #13621: Optimize str.replace(char1, char2)
http://hg.python.org/cpython/rev/c802bfc8acfc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:47:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 01:47:11 +0000
Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2
In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za>
Message-ID: <1324172831.97.0.124500626891.issue13621@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I also noticed a difference between Python 3.2 and 3.3,
> but Python 3.3 is 13% *faster* (and not slower).

Oops, I misused the timeit module, there is a regression.

> New changeset c802bfc8acfc by Victor Stinner in branch 'default':
> Issue #13621: Optimize str.replace(char1, char2)

./python -m timeit -s 'f=open("/tmp/README"); t=f.read(); f.close(); t.encode("ascii")' 't.replace("\n", " ")'

Python 3.2: 6.44 usec
Python 3.3 before: 11.6 usec
Python 3.3 after: 2.77 usec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13621>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:50:31 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sun, 18 Dec 2011 01:50:31 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324173031.18.0.908892658186.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Previous patch was also wrong, sorry!

----------
keywords: +patch
Added file: http://bugs.python.org/file24015/complex.rst-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:54:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 01:54:28 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <E1Rc5xL-0003WK-By@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 67a4e8fe650e by Victor Stinner in branch 'default':
Issue #13522: Fix _Py_co_pow() documentation
http://hg.python.org/cpython/rev/67a4e8fe650e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:54:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 01:54:48 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324173288.57.0.0877122305008.issue13522@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/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 03:19:03 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Sun, 18 Dec 2011 02:19:03 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324174743.64.0.691874184582.issue13586@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

To check on 3.2 I installed a fresh Python 3.2.1.1 on Win7 x86 32bit and it has the same problem.
So this issues is valid on 2.7.2.1 and 3.2.1.1
I --dry-run Roger patch on both 2.7 and 3.2 with no errors or warnings messages and after patching it fixes the issue on both versions.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sun Dec 18 04:01:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 18 Dec 2011 03:01:51 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324177311.64.0.633614644181.issue13586@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am running 3.2.2 on 64-bit Win7Pro, which should not make a difference. So why did ^H work right for me yesterday and not for Marco today.

Retrying with fresh IDLEs I discovered the following: selections do not initially appear in the find part of a Replace box (^H). But after selecting and opening a Find box (^F) with something selected, the same text appears in Replace boxes regardless of the actual selection, even if there is no selection -- until another Find box is opened.

So I was fooled yesterday because I tried ^F first to see what the 'correct' behavior was and then did ^H with the same selection. And I did the same in both Shell and Edit windows. When testing, order matters ;-).

I discovered something else I am not sure is what we want. Clicking Find in a Replace box leaves the box open so one can Find again. Clicking Find in a Find box closes it. So you need ^F and Find to re-search.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sun Dec 18 04:51:53 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Sun, 18 Dec 2011 03:51:53 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
In-Reply-To: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>
Message-ID: <1324180313.35.0.715338221634.issue13506@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

I test Roger patch on 2.7.2.1 and 3.2.1.1 fresh installs on Win7 Pro 32bit and I confirm it is fixing the issue and it also keeps the existing correct behavior.

-----
Note:
-----
I had to apply the patch with GNU patch: Tortoise is not patching my local files (PyShell.py 2.7 and 3.2), probably because my files were not the same then the patch was diff against; both of mine are release install not SVN. Tortoise AFAIK will accept only exact patch where GNU try to use same "smart" matching.
In fact GNU patch succeeded with messages:

patching file PyShell.py
Hunk #1 succeeded at 372 with fuzz 2 (offset 7 lines).
Hunk #2 succeeded at 410 (offset 7 lines).
Hunk #3 succeeded at 438 (offset 7 lines).
Hunk #4 succeeded at 487 with fuzz 2 (offset 3 lines).
Hunk #5 succeeded at 837 (offset 2 lines).
Hunk #6 succeeded at 987 (offset 2 lines).
Hunk #7 succeeded at 1190 (offset 2 lines).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13506>
_______________________________________

From report at bugs.python.org  Sun Dec 18 05:07:13 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Sun, 18 Dec 2011 04:07:13 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324181233.0.0.320956219964.issue13586@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

To follow on Terry thought, I think find dialog box should stay open when 'Find' button is pressed, since there is a 'close' button to close it.
That would also be a more accepted behavior similar to all the other editors I know.

And on silly UI design notes:
The 'close' button should be at the bottom instead of the top (and have a capital C)
ctrl+f 'Find' button should say 'Find Next' like most other editors and also since that is what it does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sun Dec 18 05:39:43 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 18 Dec 2011 04:39:43 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324183183.95.0.905617253546.issue13586@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


Added file: http://bugs.python.org/file24016/find_keep_open.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Sun Dec 18 08:26:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Dec 2011 07:26:45 +0000
Subject: [issue11647] function decorated with a context manager can only be
	invoked once
In-Reply-To: <1300845878.3.0.475491224846.issue11647@psf.upfronthosting.co.za>
Message-ID: <1324193205.38.0.430559790449.issue11647@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm prototyping a public version of the recreation API as "ContextDecorator.refresh_cm()" in contextlib2:

http://contextlib2.readthedocs.org/en/latest/index.html#contextlib2.ContextDecorator.refresh_cm

----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11647>
_______________________________________

From report at bugs.python.org  Sun Dec 18 10:28:33 2011
From: report at bugs.python.org (holger krekel)
Date: Sun, 18 Dec 2011 09:28:33 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1324200513.42.0.495672079785.issue7897@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/issue7897>
_______________________________________

From report at bugs.python.org  Sun Dec 18 10:39:05 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 09:39:05 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
Message-ID: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>


New submission from Ya?ar Arabac? <yasar11732 at gmail.com>:

Even though same code works fine under Python 2.7(r27:82500, Aug 07 2010, 16:54:59) and Python 2.6.6 (r266:84292, Jun 12 2011, 20:37:17), I get following error using multiprocessing.reduction module no matter what I try. Complete code example that gives this error is also attached.

Traceback (most recent call last):
File "/usr/lib/python2.7/multiprocessing/reduction.py", line 127, in _serve
send_handle(conn, handle_wanted, destination_pid)
File "/usr/lib/python2.7/multiprocessing/reduction.py", line 80, in send_handle
_multiprocessing.sendfd(conn.fileno(), handle)
OSError: [Errno 9] Bad file descriptor

----------
components: IO
files: multiprocesssockserv.py
messages: 149739
nosy: Ya?ar.Arabac?
priority: normal
severity: normal
status: open
title: multiprocessing.reduction gives OSError: [Errno 9] in 2.7.2
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24017/multiprocesssockserv.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 10:45:24 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 09:45:24 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324201524.38.0.967297539256.issue13625@psf.upfronthosting.co.za>


Ya?ar Arabac? <yasar11732 at gmail.com> added the comment:

I forgot to mention that I use

Python 2.7.2 (default, Nov 21 2011, 17:24:32) 
[GCC 4.6.2] on linux2

Linux yasar-laptop 3.1.4-1-ARCH #1 SMP PREEMPT Tue Nov 29 09:08:04 UTC 2011 i686 Intel(R) Pentium(R) M processor 1.86GHz GenuineIntel GNU/Linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 10:53:26 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 09:53:26 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1324202006.34.0.431663043675.issue8684@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

This broken the "Fedora without thread buildbot", since sched now requires the threading module:
http://www.python.org/dev/buildbot/all/builders/AMD64 Fedora without threads 3.x/builds/1250/steps/test/logs/stdio

----------
nosy: +neologix
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Sun Dec 18 12:13:33 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 18 Dec 2011 11:13:33 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324206813.34.0.926519705247.issue13555@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/issue13555>
_______________________________________

From report at bugs.python.org  Sun Dec 18 12:29:34 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 18 Dec 2011 11:29:34 +0000
Subject: [issue13575] old style classes still alive
In-Reply-To: <1323550659.7.0.785971731724.issue13575@psf.upfronthosting.co.za>
Message-ID: <1324207774.89.0.705334284611.issue13575@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> Is mro_internal's second call to type_mro_modified still needed?

I was about to remove it, however I'm not enough confident on this.
I have to understand how "tp_mro" and "tp_bases" interact in Python 3 (and the C extensions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13575>
_______________________________________

From report at bugs.python.org  Sun Dec 18 12:32:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 11:32:15 +0000
Subject: [issue13522] Document error return values for PyFloat_* and
	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <E1RcEvR-0004Wx-M4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset edc981ce8748 by Victor Stinner in branch '3.2':
Issue #13522: Fix _Py_co_pow() documentation
http://hg.python.org/cpython/rev/edc981ce8748

New changeset 2863470caebb by Victor Stinner in branch '2.7':
Issue #13522: Fix _Py_co_pow() documentation
http://hg.python.org/cpython/rev/2863470caebb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13522>
_______________________________________

From report at bugs.python.org  Sun Dec 18 12:37:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 11:37:04 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324208224.11.0.332296597364.issue13625@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Two patches have recently modified this part of the code:
http://hg.python.org/cpython/rev/d4d9a3e71897
http://hg.python.org/cpython/rev/cd15473a9de2

I'm unable to reproduce the problem on Linux 3.1.0 x86 with branch 2.7 (for those who would like to try, you just need to connect to port 9090/tcp, e.g. with netcat). Also, none of the buildbots complains, so this is rather surprising.

Ya?ar, could you test to find out which patch introduced the problem ?
Also, could you provide the result of:
$ strace -f -e network,dup,dup2,close ./python ~/multiprocesssockserv.py

when you run your test?

Do you get the error upon the first connection?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 13:02:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 12:02:16 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1324209736.5.0.895749858366.issue11867@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

There was a recent buildbot failure on test_lock_conflict() because of a race.
Looking at your patch, I must be missing something, but why not simply use a multiprocessing condition to signal when the parent process has acquired the lock?
Otherwise you could simply use a pipe or a socketpair, it would be much simpler.
Also, there's a race: if the parent process calls connect() before the child calls listen(), he'll get ECONNREFUSED.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Sun Dec 18 13:11:24 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 12:11:24 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324210284.24.0.508182564528.issue13625@psf.upfronthosting.co.za>


Ya?ar Arabac? <yasar11732 at gmail.com> added the comment:

I would love to test which patch introduced the problem, but I am not sure how should I do that. (Get the python source, change it and recompile?). I am also adding output of strace here.

----------
Added file: http://bugs.python.org/file24018/output2.7.2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 13:12:06 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 12:12:06 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324210326.85.0.652446784007.issue13625@psf.upfronthosting.co.za>


Changes by Ya?ar Arabac? <yasar11732 at gmail.com>:


Added file: http://bugs.python.org/file24019/output-2.6.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 13:12:21 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 12:12:21 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324210341.45.0.29916887675.issue13625@psf.upfronthosting.co.za>


Changes by Ya?ar Arabac? <yasar11732 at gmail.com>:


Added file: http://bugs.python.org/file24020/output-3.2.2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 13:21:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 12:21:07 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324210867.77.0.426140846896.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch to fix also the size of the small buffer on the stack, as suggested by Antoine.

----------
Added file: http://bugs.python.org/file24021/utf8_encoder-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 13:57:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 12:57:14 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324213034.44.0.536908452284.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

utf8_encoder_prescan.patch: precompute the size of the output to avoid a PyBytes_Resize() at exit. It is much slower:

ASCII: 100000 loops, best of 3: 2.06 usec per loop
UCS-1: 10000 loops, best of 3: 123 usec per loop
UCS-2: 10000 loops, best of 3: 171 usec per loop
UCS-4: 1000 loops, best of 3: 254 usec per loop

----------
Added file: http://bugs.python.org/file24022/utf8_encoder_prescan.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 13:57:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 12:57:20 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324213040.66.0.756808131382.issue13624@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file24005/utf8_encoder.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:07:07 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 13:07:07 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
Message-ID: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>


New submission from naif <naif at globaleaks.org>:

Python SSL doesn't support DH ciphers in in all version tested.

This is a serious security issue because it's not possible to use as a server or client Perfect Forward Secrecy [1] security provided by DHE and ECDH ciphers .

In order to enable DH ciphers the SSL implementation the in the file Modules/_ssl.c, it must issue a DH_generate_parameters() if a cipher is DH.

For example PHP handling of DH ciphers, look php-5.3.8/ext/openssl/openssl.c : 

#if !defined(NO_DH)
                        case OPENSSL_KEYTYPE_DH:
                                {
                                        DH *dhpar = DH_generate_parameters(req->priv_key_bits, 2, NULL, NULL);
                                        int codes = 0;

                                        if (dhpar) {
                                                DH_set_method(dhpar, DH_get_default_method());
                                                if (DH_check(dhpar, &codes) && codes == 0 && DH_generate_key(dhpar)) {
                                                        if (EVP_PKEY_assign_DH(req->priv_key, dhpar)) {
                                                                return_val = req->priv_key;
                                                        }
                                                } else {
                                                        DH_free(dhpar);
                                                }
                                        }
                                }
                                break;
#endif
                        default:


An important security fix, to support and enable by default DH ciphers has to be done.

[1] http://en.wikipedia.org/wiki/Perfect_forward_secrecy

----------
components: Library (Lib)
messages: 149749
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support DH ciphers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:07:39 2011
From: report at bugs.python.org (Boris FELD)
Date: Sun, 18 Dec 2011 13:07:39 +0000
Subject: [issue8906] Document TestCase attributes in class docstring
In-Reply-To: <1275741006.84.0.66027792452.issue8906@psf.upfronthosting.co.za>
Message-ID: <1324213659.26.0.939751409921.issue8906@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

Add a patch for this issue, move attributes comments in TestCase docstring.

I think it should be a good idea too to add their in unittest doc.

----------
keywords: +patch
nosy: +Boris.FELD
Added file: http://bugs.python.org/file24024/unittest_docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8906>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:08:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 13:08:04 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324213684.29.0.0557140896289.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 3 to fix compiler warnings (avoid variables used for the error handler, unneeded for UCS-1).

----------
Added file: http://bugs.python.org/file24023/utf8_encoder-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:24:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 13:24:02 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <E1RcGfc-0003bN-8H@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fbd797fc3809 by Victor Stinner in branch 'default':
Issue #13624: Write a specialized UTF-8 encoder to allow more optimization
http://hg.python.org/cpython/rev/fbd797fc3809

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:25:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 13:25:34 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324214734.89.0.070398277418.issue13624@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/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:27:09 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 13:27:09 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324214829.81.0.151232439707.issue13625@psf.upfronthosting.co.za>


Ya?ar Arabac? <yasar11732 at gmail.com> added the comment:

Ok, I figured how to test for those patches. I just tested my code against those versions, and suprisingly I didn't get any errors. I am adding output of three different versions now. Each filename corresponds to regarded version.

----------
Added file: http://bugs.python.org/file24025/cd15473a9de2-output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:27:28 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 13:27:28 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324214848.48.0.99939675796.issue13625@psf.upfronthosting.co.za>


Changes by Ya?ar Arabac? <yasar11732 at gmail.com>:


Added file: http://bugs.python.org/file24026/d4d9a3e71897-output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:27:47 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 13:27:47 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324214867.13.0.0428931200976.issue13625@psf.upfronthosting.co.za>


Changes by Ya?ar Arabac? <yasar11732 at gmail.com>:


Added file: http://bugs.python.org/file24027/9f4d72da69a8-output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:38:59 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 13:38:59 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
Message-ID: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>


New submission from naif <naif at globaleaks.org>:

Python SSL doesn't support Elliptic Curve ciphers in in all version tested.

This is a serious performance issue because it's not possible to use as a server or as client the performance improvement provided by ECC based ciphers.
Nowdays ECC are supported by all latests browsers.

ECC provide a strong performance improvements (even x3) also when used with Perfect Forward Secrecy enabled ciphers like described on:
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

In order to enable ECC ciphers (and eventually ECC keys) the SSL implementation the in the file Modules/_ssl.c must be modified.

For example apache had several modifications to support ECC on their SSL (openssl based) stack:
https://issues.apache.org/bugzilla/show_bug.cgi?id=40132
https://build.opensuse.org/package/view_file?file=httpd-ssl-ecc-ecdh.patch&package=apache2&project=home%3Aelvigia%3Atls1.2&rev=2

So Python SSL module should introduce similar modifications to fully support Elliptic Curve ciphers for SSL in order to:

- Provide performance improvements
- Provide cryptography security improvements
- Allow writing of applications compliant with NSA Suite-B standard

----------
components: Library (Lib)
messages: 149755
nosy: naif
priority: normal
severity: normal
status: open
title: Python  SSL stack doesn't support Elliptic Curve ciphers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:21:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 14:21:01 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324218061.59.0.204481734394.issue13625@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Looking at the strace output:
Successful test:
sendmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"\267", 1}], msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 1

The FD sent is 7 ({7} field), which makes sense.

Unsuccessful test:
sendmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {263}}, msg_flags=0}, 0) = -1 EBADF (Bad file descriptor)

See the FD sent is 263?
263 == 0x107, which means that the lower bit of the second byte corresponding the FD hasn't been set: this is exactly the bug fixed by 
http://hg.python.org/cpython/rev/d4d9a3e71897 (see http://bugs.python.org/msg142627).
So this should definitely be fixed in current 2.7.

If you confirm it is fixed, then we can close this bug report.

Now, you might wonder why this worked with 2.6.6 and 2.7.
I think it's mere luck: if we're lucky and CMSG_DATA(cmsg) refers to a memory location which happens to be zero-filled, it'll work. If not, it'll break.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:22:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 14:22:10 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1324218130.95.0.816609152062.issue13555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> New version.

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:26:00 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 14:26:00 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324218360.12.0.300079352164.issue13627@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Other example for DH and ECC from:
https://github.com/bumptech/stud/blob/master/stud.c

#ifndef OPENSSL_NO_DH
static int init_dh(SSL_CTX *ctx, const char *cert) {
    DH *dh;
    BIO *bio;

    assert(cert);

    bio = BIO_new_file(cert, "r");
    if (!bio) {
      ERR_print_errors_fp(stderr);
      return -1;
    }

    dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
    BIO_free(bio);
    if (!dh) {
        ERR("{core} Note: no DH parameters found in %s\n", cert);
        return -1;
    }

    LOG("{core} Using DH parameters from %s\n", cert);
    SSL_CTX_set_tmp_dh(ctx, dh);
    LOG("{core} DH initialized with %d bit key\n", 8*DH_size(dh));
    DH_free(dh);

#ifdef NID_X9_62_prime256v1
    EC_KEY *ecdh = NULL;
    ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
    SSL_CTX_set_tmp_ecdh(ctx,ecdh);
    EC_KEY_free(ecdh);
    LOG("{core} ECDH Initialized with NIST P-256\n");
#endif

    return 0;
}
#endif /* OPENSSL_NO_DH */



#ifndef OPENSSL_NO_DH
    init_dh(ctx, OPTIONS.CERT_FILE);
#endif /* OPENSSL_NO_DH */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:26:03 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 14:26:03 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324218363.16.0.826397883469.issue13626@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Other example for DH and ECC from:
https://github.com/bumptech/stud/blob/master/stud.c

#ifndef OPENSSL_NO_DH
static int init_dh(SSL_CTX *ctx, const char *cert) {
    DH *dh;
    BIO *bio;

    assert(cert);

    bio = BIO_new_file(cert, "r");
    if (!bio) {
      ERR_print_errors_fp(stderr);
      return -1;
    }

    dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
    BIO_free(bio);
    if (!dh) {
        ERR("{core} Note: no DH parameters found in %s\n", cert);
        return -1;
    }

    LOG("{core} Using DH parameters from %s\n", cert);
    SSL_CTX_set_tmp_dh(ctx, dh);
    LOG("{core} DH initialized with %d bit key\n", 8*DH_size(dh));
    DH_free(dh);

#ifdef NID_X9_62_prime256v1
    EC_KEY *ecdh = NULL;
    ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
    SSL_CTX_set_tmp_ecdh(ctx,ecdh);
    EC_KEY_free(ecdh);
    LOG("{core} ECDH Initialized with NIST P-256\n");
#endif

    return 0;
}
#endif /* OPENSSL_NO_DH */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:31:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 14:31:17 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324218677.72.0.855835270052.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's not obvious to me which APIs should be used to provide such support. Python mostly uses high-level OpenSSL APIs, and lets OpenSSL load certificates.

Do you want to try writing a patch? General instructions on how to contribute can be found at http://docs.python.org/devguide/

----------
nosy: +pitrou
stage:  -> needs patch
type:  -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:51:43 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 14:51:43 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324219903.08.0.2474310331.issue13627@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Have a look also at DH related ticket: http://bugs.python.org/issue13626

There is a code example on how PHP manage the DH parameter setup with high level OpenSSL.

The code must check if the ciphers is EC or DH and in that case setup appropriate parameters by generating random data for DH operations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:52:51 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 14:52:51 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324219971.87.0.244708577395.issue13625@psf.upfronthosting.co.za>


Ya?ar Arabac? <yasar11732 at gmail.com> added the comment:

Appereantly my distribution's build used this http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tar.xz, and that version was bugged. But I tried building this http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2 and that build worked successfully. I am just asking this to be sure: latter is supposed to be latest version of 2.7, right? If so, I can confirm this bug is fixed on the latest 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:06:48 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 18 Dec 2011 15:06:48 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324220808.14.0.92906767283.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

New patch with test

----------
Added file: http://bugs.python.org/file24028/issue7502.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:08:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 15:08:11 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324220891.97.0.287621775078.issue13625@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> But I tried building this
> http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2 and that
> build worked successfully.

This is 2.7, which is more than a year old.
The most recent 2.7 version is http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tar.bz2
However, the two patches above have been committed after this release, so I'd like to make sure that this works with the current 2.7 branch.
You can get it from there:
http://hg.python.org/cpython/archive/2.7.tar.bz2 (or with mercurial).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:10:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 15:10:53 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs waiting for connection
	close after a redirect
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <E1RcIMu-000230-2t@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 038616802b65 by Charles-Fran?ois Natali in branch '2.7':
Issue #8035: urllib: Fix a bug where the client could remain stuck after a
http://hg.python.org/cpython/rev/038616802b65

New changeset a420b27a86d9 by Charles-Fran?ois Natali in branch '3.2':
Issue #8035: urllib: Fix a bug where the client could remain stuck after a
http://hg.python.org/cpython/rev/a420b27a86d9

New changeset 764234983120 by Charles-Fran?ois Natali in branch 'default':
Issue #8035: urllib: Fix a bug where the client could remain stuck after a
http://hg.python.org/cpython/rev/764234983120

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:11:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 15:11:20 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324221080.03.0.335631400099.issue13626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The ssl module doesn't directly handle keys, it just gives a PEM file to OpenSSL's ssl functions. So I don't understand what should be done precisely here, or even if something has to be done at all.

----------
nosy: +pitrou
type:  -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:25:23 2011
From: report at bugs.python.org (=?utf-8?b?WWHFn2FyIEFyYWJhY8Sx?=)
Date: Sun, 18 Dec 2011 15:25:23 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324221923.21.0.0531604609906.issue13625@psf.upfronthosting.co.za>


Ya?ar Arabac? <yasar11732 at gmail.com> added the comment:

Current 2.7 branch is ok. This bug report can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:41:27 2011
From: report at bugs.python.org (zup)
Date: Sun, 18 Dec 2011 15:41:27 +0000
Subject: [issue13553] Tkinter doesn't set proper application name
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1324222887.25.0.185665424483.issue13553@psf.upfronthosting.co.za>


zup <hripoche at gmail.com> added the comment:

The link below suggests that the problem with method 'iconname'
may be due to the method not working at the window manager level:

http://www.pythonware.com/library/tkinter/introduction/x9905-icon-methods.htm

summary:

iconname

iconname(newName=None), iconname(). Set (get) the icon name to use when this window is iconified. This method are ignored by some window managers (including Windows).

----------
nosy: +zup

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13553>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:46:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 15:46:00 +0000
Subject: [issue13625] multiprocessing.reduction gives OSError: [Errno 9] in
	2.7.2
In-Reply-To: <1324201145.68.0.054979576594.issue13625@psf.upfronthosting.co.za>
Message-ID: <1324223160.88.0.251053322857.issue13625@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Alright, thanks!

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13625>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:46:43 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 15:46:43 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324223203.37.0.920691023639.issue13626@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Please look at how PHP implement the feature.
It doesn't use any PEM or any Key File, but just initiatlize the DH parameters.

Stud instead, ask the user to generate "offline" the DH parameters and save it into the PEM file.

I think that the PHP approach it's better than the STUD one:
It does not require any file or key to generate DH parameters.

This is the way to have supported ciphers such as DHE-RSA-AES256-SHA (
http://www.openssl.org/docs/apps/ciphers.html ) that now cannot be used because the Python SSL binding doesn't initialize the DH parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:01:06 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 18 Dec 2011 16:01:06 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324224066.24.0.169558041718.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

New patch to add __hash__ and __eq__ to DocTest

----------
Added file: http://bugs.python.org/file24029/issue7502.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:04:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 16:04:53 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324224293.51.0.798701813112.issue13626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well the OpenSSL docs say ?DH_generate_parameters() may run for several hours before finding a suitable prime?, which sounds like a good reason not to do it every time your program is run.

Anyway, SSL_CTX_set_tmp_dh() should allow us to set DH parameters on a SSL context, PEM_read_DHparams() to read them from a PEM file, and OpenSSL's source tree has a couple of PEM files with "strong" DH parameters for various key sizes.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:06:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 16:06:27 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1324224387.97.0.601944844769.issue11870@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Victor, could you try the patch attached?

----------
Added file: http://bugs.python.org/file24030/threading_reinit_lock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:13:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 16:13:01 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs waiting for connection
	close after a redirect
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <1324224781.67.0.452700103449.issue8035@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Alright, should be fixed now.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:18:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 16:18:35 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324225115.68.0.613476255742.issue7502@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The definition of __eq__ is wrong: it shouldn't compare the hashes since the hash() function isn't injective. For example, 0 and "" have equal hashes, yet they are unequal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:29:06 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 18 Dec 2011 16:29:06 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324225746.19.0.185786230179.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

Update patch to not use hash in __eq__

----------
Added file: http://bugs.python.org/file24031/issue7502.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:31:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 16:31:27 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324225887.41.0.157920268197.issue7502@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Something I forgot: you should also test the "!=" operator in the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:31:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 16:31:28 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
Message-ID: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If Python is compiled with gcc -O3, gdb is unable to get the f argument of PyEval_EvalFrameEx(). It is possible to retrieve "f" from the caller, PyEval_EvalCodeEx().

Attached patch tries to implement this idea and enable more test_gdb tests on optimized Python.

The patch has a problem because some tests fails if Python is not optimized (Python compiled in debug mode).

--

The patch fix other minor bugs in libpython.py related to optimized Python.

----------
files: gdb.patch
keywords: patch
messages: 149778
nosy: haypo
priority: normal
severity: normal
status: open
title: python-gdb.py: patch to improve support of optimized Python
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24032/gdb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13628>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:32:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 16:32:12 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324225932.36.0.218373310434.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so you are talking specifically about ECDH? Or is there something to be done for generic EC support?

OpenSSL has a SSL_CTX_set_tmp_dh() function (macro, actually), but it's undocumented. Best bet is probably to follow ssl/ssltest.c (OpenSSL source tree), lines 825 and following, under "#ifndef OPENSSL_NO_ECDH".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:37:58 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 18 Dec 2011 16:37:58 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324226278.31.0.539120584384.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

Add test for "!="

----------
Added file: http://bugs.python.org/file24033/issue7502.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:43:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 16:43:11 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1324226591.53.0.288761467243.issue12231@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Already fixed in #12626.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> run test cases based on a glob filter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12231>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:59:47 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 16:59:47 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324227587.42.0.66399112386.issue13627@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

This is how the Stud software enable also the use of ECC in OpenSSL TLS
https://github.com/bumptech/stud/pull/61

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Sun Dec 18 18:05:46 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sun, 18 Dec 2011 17:05:46 +0000
Subject: [issue13617] Reject embedded null characters in wchar* strings
In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za>
Message-ID: <1324227946.35.0.286680161919.issue13617@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Here is a patch for the documentation. 

I added warnings for, PyUnicode_AsWideChar*, PyUnicode_EncodeFSDefault and PyUnicode_AsUnicode*, since they're all concerned by this issue.

----------
nosy: +arnaudc
Added file: http://bugs.python.org/file24034/doc_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13617>
_______________________________________

From report at bugs.python.org  Sun Dec 18 18:59:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 17:59:32 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <E1RcKpf-0005yH-Bd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 775319cebaa3 by Charles-Fran?ois Natali in branch '2.7':
Issue #11870: threading: Properly reinitialize threads internal locks and
http://hg.python.org/cpython/rev/775319cebaa3

New changeset de962ec0faaa by Charles-Fran?ois Natali in branch '3.2':
Issue #11870: threading: Properly reinitialize threads internal locks and
http://hg.python.org/cpython/rev/de962ec0faaa

New changeset cec0d77d01c4 by Charles-Fran?ois Natali in branch 'default':
Issue #11870: threading: Properly reinitialize threads internal locks and
http://hg.python.org/cpython/rev/cec0d77d01c4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:01:58 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 18 Dec 2011 18:01:58 +0000
Subject: [issue13521] Make dict.setdefault() atomic
In-Reply-To: <1322872228.97.0.525171057572.issue13521@psf.upfronthosting.co.za>
Message-ID: <1324231318.08.0.806095370816.issue13521@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Patch for 2.7.

----------
Added file: http://bugs.python.org/file24035/13521_27_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13521>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:07:53 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 18 Dec 2011 18:07:53 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324231673.9.0.299680049707.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

Add also __eq__ to Example and add __ne__ method.

----------
Added file: http://bugs.python.org/file24036/issue7502.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:09:32 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sun, 18 Dec 2011 18:09:32 +0000
Subject: [issue13617] Reject embedded null characters in wchar* strings
In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za>
Message-ID: <1324231772.15.0.287275146334.issue13617@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

I removed the hints "using wcslen on the result of PyUnicode_AsWideChar*", since the resulting wchar_t strings may not be null-terminated

----------
Added file: http://bugs.python.org/file24037/doc_unicode-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13617>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:13:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Dec 2011 18:13:47 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1324232027.31.0.0672708049418.issue11870@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Should be fixed now.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11870>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:21:22 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 18 Dec 2011 18:21:22 +0000
Subject: [issue13629] _PyParser_TokenNames does not match up with the token.h
	numbers
Message-ID: <1324232482.43.0.0474353637736.issue13629@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

When making the changes to remove backticks in eb2f70fdbf32, the _PyParser_TokenNames table was incorrectly updated.  Now the indexes into _PyParser_TokenNames don't match the token numbers.  This can be seen in the output of 'python -d':

   $ echo '2 << 1' | ./python -d | grep Token
   ...
   Token NUMBER/'2' ... It's a token we know
   Token RIGHTSHIFT/'<<' ... It's a token we know
   Token NUMBER/'1' ... It's a token we know
   Token NEWLINE/'' ... It's a token we know
   Token NEWLINE/'' ... It's a token we know
   Token ENDMARKER/'' ... It's a token we know

The fix is trivial.  Patch attached.

----------
components: Interpreter Core
files: parser-debug-output.patch
keywords: easy, patch
messages: 149789
nosy: meador.inge
priority: low
severity: normal
stage: patch review
status: open
title: _PyParser_TokenNames does not match up with the token.h numbers
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24038/parser-debug-output.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13629>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:25:27 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 18 Dec 2011 18:25:27 +0000
Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux
In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za>
Message-ID: <1324232727.51.0.0625005278556.issue5492@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

You can trigger this error every time if you change ".after(2*self.poll_interval, self.close2)" to ".after(1, self.close2)" in PyShell.py

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5492>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:35:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 18:35:22 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <E1RcLWu-0002Hz-Fs@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c478734ded4b by Antoine Pitrou in branch '3.2':
Issue #7502: Fix equality comparison for DocTestCase instances.
http://hg.python.org/cpython/rev/c478734ded4b

New changeset b8cb6f1e4981 by Antoine Pitrou in branch 'default':
Issue #7502: Fix equality comparison for DocTestCase instances.
http://hg.python.org/cpython/rev/b8cb6f1e4981

New changeset 64d670a8b183 by Antoine Pitrou in branch '2.7':
Issue #7502: Fix equality comparison for DocTestCase instances.
http://hg.python.org/cpython/rev/64d670a8b183

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:35:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 18:35:41 +0000
Subject: [issue13617] Reject embedded null characters in wchar* strings
In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za>
Message-ID: <E1RcLTr-00020n-FS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fa5c8cf29963 by Victor Stinner in branch '3.2':
Issue #13617: Document that the result of the conversion of a Unicode object to
http://hg.python.org/cpython/rev/fa5c8cf29963

New changeset f30ac7729f2b by Victor Stinner in branch 'default':
Issue #13617: Document that the result of the conversion of a Unicode object to
http://hg.python.org/cpython/rev/f30ac7729f2b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13617>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:37:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 18:37:12 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324233432.01.0.784773604387.issue7502@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch now committed to all 3 branches. Thanks for contributing!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:44:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 18:44:17 +0000
Subject: [issue13617] Reject embedded null characters in wchar* strings
In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za>
Message-ID: <E1RcLcX-0002dj-VA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1c4d9534263e by Victor Stinner in branch '2.7':
Issue #13617: Document that the result PyUnicode_AsUnicode() and
http://hg.python.org/cpython/rev/1c4d9534263e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13617>
_______________________________________

From report at bugs.python.org  Sun Dec 18 20:01:43 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 18 Dec 2011 19:01:43 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324234903.97.0.0355734972919.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

Patch to add __hash__ to prevent warnings in 2.7

----------
Added file: http://bugs.python.org/file24039/issue7502-hash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 20:14:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 19:14:25 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
In-Reply-To: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>
Message-ID: <1324235665.46.0.690644067335.issue13628@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13628>
_______________________________________

From report at bugs.python.org  Sun Dec 18 20:17:33 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 18 Dec 2011 19:17:33 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1324235853.03.0.724790730625.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

Add test for __hash__

----------
Added file: http://bugs.python.org/file24040/issue7502-hash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 20:28:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 19:28:46 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <E1RcMI1-0005y9-AM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6a95820b9607 by Antoine Pitrou in branch '2.7':
Followup to #7502: add __hash__ method and tests.
http://hg.python.org/cpython/rev/6a95820b9607

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Dec 18 20:41:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Dec 2011 19:41:24 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324157134.42.0.274965985428.issue13624@psf.upfronthosting.co.za>
Message-ID: <4EEE3F75.30206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Oooh, it's just faster because encoding ASCII to UTF-8 is now O(1)

It's actually still O(n): the UTF-8 data still need to be copied into a
bytes object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 20:45:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 19:45:56 +0000
Subject: [issue13624] UTF-8 encoder performance regression in python3.3
In-Reply-To: <1324147751.99.0.957308589374.issue13624@psf.upfronthosting.co.za>
Message-ID: <1324237556.57.0.483147980118.issue13624@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It's actually still O(n): the UTF-8 data still need to be copied
> into a bytes object.

Hum, correct, but a memory copy is much faster than having to decode UTF-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13624>
_______________________________________

From report at bugs.python.org  Sun Dec 18 20:54:15 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Dec 2011 19:54:15 +0000
Subject: [issue13629] _PyParser_TokenNames does not match up with the token.h
	numbers
In-Reply-To: <1324232482.43.0.0474353637736.issue13629@psf.upfronthosting.co.za>
Message-ID: <1324238055.64.0.51703484518.issue13629@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Is there a reason not to renumber token.h?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13629>
_______________________________________

From report at bugs.python.org  Sun Dec 18 21:12:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 20:12:32 +0000
Subject: [issue13617] Reject embedded null characters in wchar* strings
In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za>
Message-ID: <1324239152.93.0.746985922528.issue13617@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

embedded_nul-2.patch: a more complete patch check also null byte in functions calling PyUnicode_EncodeFSDefault().

----------
Added file: http://bugs.python.org/file24041/embedded_nul-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13617>
_______________________________________

From report at bugs.python.org  Sun Dec 18 22:26:56 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 18 Dec 2011 21:26:56 +0000
Subject: [issue11813] inspect.getattr_static doesn't get module attributes
In-Reply-To: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>
Message-ID: <1324243616.03.0.309017377533.issue11813@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'd like to commit this patch. What's your real name Trundle, for the NEWS entry?

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11813>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:12:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 22:12:37 +0000
Subject: [issue11813] inspect.getattr_static doesn't get module attributes
In-Reply-To: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>
Message-ID: <E1RcOt2-0003bf-Ch@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 56731ccf2e86 by Michael Foord in branch '3.2':
Fix inspect.getattr_static to work on modules (again).
http://hg.python.org/cpython/rev/56731ccf2e86

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11813>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:35:51 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 18 Dec 2011 22:35:51 +0000
Subject: [issue11807] Documentation of add_subparsers lacks information about
	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1324247751.34.0.866460550027.issue11807@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Fixed patch.

----------
Added file: http://bugs.python.org/file24042/11807_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11807>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:26:49 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 00:26:49 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
In-Reply-To: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>
Message-ID: <1324254409.8.0.918828557233.issue13628@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
components: +Demos and Tools
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13628>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:28:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2011 00:28:53 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324254533.14.0.92549722271.issue5689@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There is failure on a XP buildbot. I don't know if it is a sporadic issue or not.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3921/steps/test/logs/stdio

======================================================================
ERROR: test_append_lzma (test.test_tarfile.AppendTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_tarfile.py", line 1539, in test_append_lzma
    self._create_testtar("w:xz")
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_tarfile.py", line 1486, in _create_testtar
    with tarfile.open(self.tarname, mode) as tar:
  File "D:\Buildslave\3.x.moore-windows\build\lib\tarfile.py", line 1721, in open
    return func(name, filemode, fileobj, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\tarfile.py", line 1826, in xzopen
    mode=mode, fileobj=fileobj, preset=preset)
  File "D:\Buildslave\3.x.moore-windows\build\lib\lzma.py", line 117, in __init__
    preset=preset, filters=filters)
MemoryError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:29:47 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 00:29:47 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
In-Reply-To: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>
Message-ID: <1324254587.61.0.843258093365.issue13628@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13628>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:43:26 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 19 Dec 2011 00:43:26 +0000
Subject: [issue11178] Running tests inside a package by module name fails
In-Reply-To: <1297369148.53.0.82343889297.issue11178@psf.upfronthosting.co.za>
Message-ID: <1324255406.12.0.445598796776.issue11178@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

No longer reproducable on CPython. Unfortunately still an issue with unittest2.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11178>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:53:09 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 00:53:09 +0000
Subject: [issue13629] _PyParser_TokenNames does not match up with the token.h
	numbers
In-Reply-To: <1324232482.43.0.0474353637736.issue13629@psf.upfronthosting.co.za>
Message-ID: <1324255989.7.0.533302860937.issue13629@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Is there a reason not to renumber token.h?

I thought about that, but at the time I wasn't sure whether or not that
would break anything.  I went with the current patch because it is lower
risk.

On the other hand, proper clients of token.h should only be using the macros and should have no knowledge of the numeric codes.  If they do use the numeric codes directly somehow, then that is their issue.  So, I guess it is OK to renumber token.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13629>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:16:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Dec 2011 01:16:07 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
In-Reply-To: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>
Message-ID: <1324257367.66.0.400677682952.issue13628@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/issue13628>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:27:07 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 19 Dec 2011 01:27:07 +0000
Subject: [issue11764] inspect.getattr_static code execution w/ class body as
	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1324258027.19.0.884821448644.issue11764@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11764>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:28:20 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 19 Dec 2011 01:28:20 +0000
Subject: [issue11829] inspect.getattr_static code execution with
	meta-metaclasses
In-Reply-To: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>
Message-ID: <1324258100.54.0.904342689058.issue11829@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Andreas, is this still needed and valid?

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11829>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:54:52 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Dec 2011 01:54:52 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324259692.17.0.660030091368.issue13626@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/issue13626>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:56:38 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Dec 2011 01:56:38 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324259798.19.0.0854718765436.issue13627@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/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 03:13:50 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Mon, 19 Dec 2011 02:13:50 +0000
Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box
	is open
Message-ID: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za>


New submission from Marco Scataglini <atlantide at gmx.com>:

Found text does not show at all highlighted on some text colors (like green and orange) when using the find button in the replace dialog box when box is open/visible.

Then when dialog box is closed it will highlight the found text in black on gray like 'selected' and not in white on black 'found' highlighting color scheme.

Using F3, to find text, highlights in black on gray like 'selected' and not in white on black 'found' highlighting color scheme

Also using CTRL+f to find text seems to follow the same improper behavior, just less noticeable since as soon as find button is pressed, the dialog box is closed and the found text is shown, but if the dialog box would not close the text would not be shown with any highlighting at all ('found' nor 'selected' highlighting).

To test the last behavior I used the find_keep_open.patch to prevent CTRL+f Find Dialog box to close after pressing find button.(issue13586)

Note: 
Color scheme highlighting setting can be seen in IDLE Preferences pane under the Highlighting tab by going to Options/Configure IDLE...

----------
components: IDLE
messages: 149811
nosy: marco
priority: normal
severity: normal
status: open
title: IDLE: Find(ed) text is not highlighted while dialog box is open
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13630>
_______________________________________

From report at bugs.python.org  Mon Dec 19 03:18:31 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Mon, 19 Dec 2011 02:18:31 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1324261111.54.0.840398855476.issue13586@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

Thank you Roger
find_keep_open.patch works, but now that brings me to issue13630 that I thought was existing, and now this confirms it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:06:37 2011
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Mon, 19 Dec 2011 04:06:37 +0000
Subject: [issue13631] readline fails to parse some forms of .editrc under
	editline (libedit) emulation on Mac OS X
Message-ID: <1324267597.43.0.334578978638.issue13631@psf.upfronthosting.co.za>


New submission from Zvezdan Petkovic <zvezdan at zope.com>:

Problem
=======

The changes in r87356 for py3k and r87358 for python-2.7 described in issue 9907 have broken parsing of the initialization file .editrc under editline emulation of readline on Mac OS X.

Background
==========

Both readline and editline allow settings customized per program.
For example, .inputrc file for readline::

    $if Python
        set editing-mode vi
    $endif

will be applied only to Python processes.

Similarly, .editrc file for editline::

    python:bind -v
    python:bind ^I rl_complete

will be applied only to Python processes on Mac OS X.

This works fine on python-2.6.

It's broken on 2.7 and 3.2 and later because the change in issue 9907 moved the rl_initialize() call towards the beginning of the setup function.

Solution
========

The rl_readline_name variable must be set to "python" **before** the call to rl_initialize().  Attached are patches for 2.7 and 3.2.

----------
assignee: ronaldoussoren
components: Macintosh
files: readline-2.7.patch
keywords: patch
messages: 149813
nosy: ronaldoussoren, zvezdan
priority: normal
severity: normal
status: open
title: readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24043/readline-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13631>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:07:23 2011
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Mon, 19 Dec 2011 04:07:23 +0000
Subject: [issue13631] readline fails to parse some forms of .editrc under
	editline (libedit) emulation on Mac OS X
In-Reply-To: <1324267597.43.0.334578978638.issue13631@psf.upfronthosting.co.za>
Message-ID: <1324267643.4.0.0505985912867.issue13631@psf.upfronthosting.co.za>


Changes by Zvezdan Petkovic <zvezdan at zope.com>:


Added file: http://bugs.python.org/file24044/readline-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13631>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:13:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2011 04:13:35 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1324268015.74.0.389191563129.issue11867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Probably because I'm a threading/multiprocessing neophyte :)  (Though I just learned a bunch about programming with threads recently...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:51:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 04:51:23 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324270283.73.0.22714523648.issue2134@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The proposed documentation text seems too complicated and language expert speaky to me.  We should try to link to standard definitions when possible to reduce the text here.  For example, I believe the "Operators" and "Delimiters" tokens in the "Lexical Analysis" section of the docs (http://docs.python.org/dev/reference/lexical_analysis.html#operators) are exactly what we are trying to describe when referencing "literal tokens" and "affected tokens".

I like Nick's idea to introduce a new attribute for the exact type, while keeping the tuple structure itself backwards compatible.  Attached is a patch for 3.3 that updates the docs, adds exact_type, adds new unit tests, and adds a new CLI option for displaying token names using the exact type.

An example of the new CLI option is:

$ echo '1+2**4' | ./python -m tokenize
1,0-1,1:            NUMBER         '1'            
1,1-1,2:            OP             '+'            
1,2-1,3:            NUMBER         '2'            
1,3-1,5:            OP             '**'           
1,5-1,6:            NUMBER         '4'            
1,6-1,7:            NEWLINE        '\n'           
2,0-2,0:            ENDMARKER      ''             
$ echo '1+2**4' | ./python -m tokenize -e
1,0-1,1:            NUMBER         '1'            
1,1-1,2:            PLUS           '+'            
1,2-1,3:            NUMBER         '2'            
1,3-1,5:            DOUBLESTAR     '**'           
1,5-1,6:            NUMBER         '4'            
1,6-1,7:            NEWLINE        '\n'           
2,0-2,0:            ENDMARKER      ''

----------
Added file: http://bugs.python.org/file24045/tokenize-exact-type-v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:07:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 05:07:36 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <E1RcVRX-00009Z-Kl@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 88aacd3541ae by Ezio Melotti in branch '2.7':
#13387: rephrase unclear sentence.
http://hg.python.org/cpython/rev/88aacd3541ae

New changeset eccb4795767b by Ezio Melotti in branch '3.2':
#13387: rephrase unclear sentence.
http://hg.python.org/cpython/rev/eccb4795767b

New changeset 064854cef999 by Ezio Melotti in branch 'default':
#13387: merge with 3.2.
http://hg.python.org/cpython/rev/064854cef999

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:08:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Dec 2011 05:08:15 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1324271295.38.0.954489998819.issue13387@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:18:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 05:18:12 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <E1RcVbM-0001F8-AT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 978f45013c34 by Ezio Melotti in branch '2.7':
#3932: suggest passing unicode to HTMLParser.feed().
http://hg.python.org/cpython/rev/978f45013c34

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:20:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Dec 2011 05:20:04 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1324272004.96.0.408461583511.issue3932@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:28:50 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 19 Dec 2011 05:28:50 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324272530.5.0.686222759957.issue13607@psf.upfronthosting.co.za>


Changes by Ron Adam <ron3200 at gmail.com>:


Removed file: http://bugs.python.org/file23969/f_why.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:30:01 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 05:30:01 +0000
Subject: [issue13632] Update token documentation to reflect actual token types
Message-ID: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

The current token documentation is out of date with respect to the currently available token types:

Python 3.3.0a0 (default:766136049b44+, Dec 18 2011, 21:54:42) 
[GCC 4.6.2 20111027 (Red Hat 4.6.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import token
>>> token.BACKQUOTE
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'BACKQUOTE'
>>> token.RARROW
51
>>> token.ELLIPSIS
52

The attached patch fixes this.  OK?

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: token-docs-v0.patch
keywords: easy, patch
messages: 149818
nosy: docs at python, georg.brandl, meador.inge
priority: low
severity: normal
stage: patch review
status: open
title: Update token documentation to reflect actual token types
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24046/token-docs-v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13632>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:41:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 05:41:14 +0000
Subject: [issue13576] Handling of broken condcoms in HTMLParser
In-Reply-To: <1323568714.45.0.610853679425.issue13576@psf.upfronthosting.co.za>
Message-ID: <E1RcVtT-0003WB-Fi@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9c60fd12664f by Ezio Melotti in branch '2.7':
#13576: add tests about the handling of (possibly broken) condcoms.
http://hg.python.org/cpython/rev/9c60fd12664f

New changeset 4ddbb756b602 by Ezio Melotti in branch '3.2':
#13576: add tests about the handling of (possibly broken) condcoms.
http://hg.python.org/cpython/rev/4ddbb756b602

New changeset 6452edbc5f12 by Ezio Melotti in branch 'default':
#13576: merge with 3.2.
http://hg.python.org/cpython/rev/6452edbc5f12

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13576>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:46:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Dec 2011 05:46:34 +0000
Subject: [issue13576] Handling of broken condcoms in HTMLParser
In-Reply-To: <1323568714.45.0.610853679425.issue13576@psf.upfronthosting.co.za>
Message-ID: <1324273594.4.0.882741825158.issue13576@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13576>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:56:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 19 Dec 2011 05:56:17 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324274177.78.0.934794407983.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Meador's patch looks good to me. The docs change for 2.7 and 3.2 would be similar, just with text like "Specific tokens can be distinguished by checking the ``string`` attribute of OP tokens for a match with the expected character sequence." replacing the reference to the new "exact_type" attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:04:29 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 19 Dec 2011 06:04:29 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324274669.52.0.447188328881.issue13607@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

New diff file.

The main difference is I moved the saved why value to the tstate object instead of the frame object as why_exit.

I'm not seeing the time savings now for some reason.  Maybe the previous increase was a case of coincidental noise. (?)  Still looking for other reasons though.  ;-)

Moving the generator code from the eval loop to the generator object may still be a good thing to do.

----------
Added file: http://bugs.python.org/file24047/f_why1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:55:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Dec 2011 06:55:57 +0000
Subject: [issue13633] Handling of hex character references in
	HTMLParser.handle_charref
Message-ID: <1324277757.56.0.0733657691883.issue13633@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The doc for handle_charref and handle_entityref say:
"""
HTMLParser.handle_charref(name)
    This method is called to process a character reference of the form "&#ref;". It is intended to be overridden by a derived class; the base class implementation does nothing.

HTMLParser.handle_entityref(name)
    This method is called to process a general entity reference of the form "&name;" where name is an general entity reference. It is intended to be overridden by a derived class; the base class implementation does nothing.
"""

The doc doesn't mention hex references, like "&#x3E;", and apparently they are passed to handle_charref without the '&#' but with the leading 'x':

>>> from HTMLParser import HTMLParser
>>> class MyParser(HTMLParser):
...   def handle_charref(self, data):
...     print data
... 
>>> MyParser().feed('&gt; &#62; &#x3E;')
62
x3E

I've seen code in the wild doing unichr(int(data)) in handle_charref (once they figured out that '62' is passed) and then fail when an hex entity is found.  Passing 'x3E' doesn't seem too useful because the user has to first check if there's a leading 'x', if there is remove it, then convert the hex string to int, and finally use unichr() to get the char, otherwise just convert to int and use unichr().

There 3 different possible solutions:
1) just document the behavior;
2) normalize the hex value before passing them to handle_charref and document it;
3) add a new handle_entity method that is called with the character represented by the entity (named, decimal, or hex);

The first solution alone doesn't solve much, but the doc should be clearer regardless of the decision we take.
The second one is better, but if it's implemented there won't be any way to know if the entity had a decimal or hex value anymore (does anyone care?).  The normalization should also convert the hex string to int and then convert it back to str to be consistent with decimal entities.
The third one might be better, but doesn't solve the issue on 2.7/3.2.  People don't care about entities and just want the equivalent char, so having a method that converts them already sounds like a useful feature to me.

----------
assignee: ezio.melotti
components: Library (Lib)
messages: 149822
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
stage: test needed
status: open
title: Handling of hex character references in HTMLParser.handle_charref
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13633>
_______________________________________

From report at bugs.python.org  Mon Dec 19 09:07:34 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Dec 2011 08:07:34 +0000
Subject: [issue13631] readline fails to parse some forms of .editrc under
	editline (libedit) emulation on Mac OS X
In-Reply-To: <1324267597.43.0.334578978638.issue13631@psf.upfronthosting.co.za>
Message-ID: <1324282054.87.0.755557717266.issue13631@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13631>
_______________________________________

From report at bugs.python.org  Mon Dec 19 10:08:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 19 Dec 2011 09:08:10 +0000
Subject: [issue13550] Rewrite logging hack of the threading module
In-Reply-To: <1323297626.55.0.00727033353184.issue13550@psf.upfronthosting.co.za>
Message-ID: <1324285690.73.0.320286243732.issue13550@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm personally +1 on removing the verbose thing altogether:
- it's ugly
- I doubt it's really useful (I mean, printing to stderr - which is often line buffered or unbuffered - upon every action will probably change the timing)
- it also brings some problems on its own, e.g. #4188

So unless there's a good reason behind it, I think we could let it go.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13550>
_______________________________________

From report at bugs.python.org  Mon Dec 19 10:16:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 19 Dec 2011 09:16:54 +0000
Subject: [issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64
	Snow Leopard 02 03.x"
In-Reply-To: <1323435539.17.0.162534043929.issue13565@psf.upfronthosting.co.za>
Message-ID: <1324286214.6.0.994753300421.issue13565@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I think this could be due to the multiprocessing manager's server socket backlog value, which is a little too low: by default, it's set to 5, and the tests launch up to 3 threads and 3 processes in parallel, so if we're unlucky with the scheduling, we could get some ECONNREFUSED.
Unless otherwise specified, the server uses Unix domain sockets: on Linux, when the server's socket backlog is full, connect() blocks, which could explain why it doesn't happen on Linux. It would be nice to check the behavior in case of socket backlog full on affected OSes (for example OS X or FreeBSD).

Here's a run on Linux:
"""
$ ./python ~/test_backlog.py 
0
1
2
3
4
[blocks]
"""

If we get ECONNREFUSED on OS X or FreeBSD, then there's a chance it's the culprit. If not, well, no idea what's going on :-)

----------
nosy: +neologix
Added file: http://bugs.python.org/file24048/test_backlog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13565>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:03:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 19 Dec 2011 10:03:15 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1324268015.74.0.389191563129.issue11867@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0yO_xFMBGZ7YNJtAs_2VQ8u5=HbCBfgQ_7DxcnSXKY8w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Probably because I'm a threading/multiprocessing neophyte :)

That's a very good reason :-)

Here's a version using two multiprocessing events. Note that I use
timeouts for wait() just to avoid being stuck if something goes wrong:
the test now runs in a dozen ms.

By the way, next time you need a duplex communication between two
processes, you can use socketpair(), which returns a pair of connected
sockets.

----------
Added file: http://bugs.python.org/file24049/test_mailbox_evt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -17,6 +17,10 @@
     import fcntl
 except ImportError:
     pass
+try:
+    import multiprocessing
+except ImportError:
+    multiprocessing = None
 
 
 class TestBase(unittest.TestCase):
@@ -993,28 +997,36 @@
             self.assertEqual(contents, f.read())
         self._box = self._factory(self._path)
 
+    @unittest.skipUnless(hasattr(os, 'fork'), "Test needs fork().")
+    @unittest.skipUnless(multiprocessing, "Test needs multiprocessing.")
     def test_lock_conflict(self):
-        # Fork off a subprocess that will lock the file for 2 seconds,
-        # unlock it, and then exit.
-        if not hasattr(os, 'fork'):
-            return
+        # Fork off a child process that will lock the mailbox temporarily,
+        # unlock it and exit.
+        ready = multiprocessing.Event()
+        done = multiprocessing.Event()
+
         pid = os.fork()
         if pid == 0:
-            # In the child, lock the mailbox.
+            # child
             try:
+                # lock the mailbox, and signal the parent it can proceed
                 self._box.lock()
-                time.sleep(2)
+                ready.set()
+
+                # wait until the parent is done, and unlock the mailbox
+                done.wait(5)
                 self._box.unlock()
             finally:
                 os._exit(0)
 
-        # In the parent, sleep a bit to give the child time to acquire
-        # the lock.
-        time.sleep(0.5)
+        # In the parent, wait until the child signals it locked the mailbox.
+        ready.wait(5)
         try:
             self.assertRaises(mailbox.ExternalClashError,
                               self._box.lock)
         finally:
+            # Signal the child it can now release the lock and exit.
+            done.set()
             # Wait for child to exit.  Locking should now succeed.
             exited_pid, status = os.waitpid(pid, 0)
 

From report at bugs.python.org  Mon Dec 19 11:09:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 10:09:27 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324289367.17.0.419252611213.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch adding a set_ecdh_curve() method on SSL contexts, and a ssl.OP_SINGLE_ECDH_USE option flag. This is enough to enable ECDH with compatible clients (I've tested with Firefox and openssl s_client).

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24050/ecdh.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:26:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 10:26:21 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1324290381.6.0.881824805352.issue11867@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Charles-Fran?ois's patch looks good to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:32:34 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:32:34 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324290754.24.0.917273225252.issue13627@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

So, with this patch it should be possible to strictly enable ciphers such as:
ECDHE-RSA-AES256-SHA   SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256) Mac=SHA1
ECDH-RSA-AES256-SHA    SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1

Which ciphers did you negotiated succesfully?


While with the implementation of http://bugs.python.org/issue13627 (DH/DHE ciphers) we should be able to negotiate:
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA       EDH-RSA-DES-CBC3-SHA (SSLv3)
 TLS_DHE_DSS_WITH_DES_CBC_SHA            EDH-DSS-CBC-SHA (TLSv1)
 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       EDH-DSS-DES-CBC3-SHA (TLSv1)
 TLS_DHE_RSA_WITH_DES_CBC_SHA            EDH-RSA-DES-CBC-SHA (TLSv1)
 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       EDH-RSA-DES-CBC3-SHA (TLSv1)
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE-DSS-AES128-SHA
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE-DSS-AES256-SHA
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE-RSA-AES128-SHA
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE-RSA-AES256-SHA

Do you expect it would be a difficult step to handle also the DH/DHE (non ECC) negotiation?

Additionally it would be imho very important if the Python language would provide a "default ciphers setup" that look at maximum compatibility, performance and security.

If it sounds fine for you, i would open another ticket to create a default cipherlist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:37:57 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:37:57 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324291077.57.0.776829405415.issue13626@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Wow, i saw your patch for ECC SSL ciphers on http://bugs.python.org/issue13627 .

Do you think we can use the same method/concept as ssl.OP_SINGLE_ECDH_USE but ssl.OP_SINGLE_DH_USE for DH?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:39:59 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:39:59 +0000
Subject: [issue13634] Python SSL stack doesn't support Compression
	configuration
Message-ID: <1324291199.34.0.550922917675.issue13634@psf.upfronthosting.co.za>


New submission from naif <naif at globaleaks.org>:

TLSv1 support compression with gzip/deflate that can provide for a lot of protocols a great improvement (just think about SIP/TLS or IMAP) in terms of bandwidth.

Currenly Python SSL stack based on OpenSSL doesn't allow the configuration (enabling/disabling/forcing) of TLS compression.

This ticket is about suggesting to implement TLS compression configuration of OpenSSL as described on:
http://blog.dave.cridland.net/?p=73

----------
components: Library (Lib)
messages: 149830
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support Compression configuration
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13634>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:44:03 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:44:03 +0000
Subject: [issue13635] Python SSL stack doesn't support ordering of Ciphers
Message-ID: <1324291443.18.0.0191846315359.issue13635@psf.upfronthosting.co.za>


New submission from naif <naif at globaleaks.org>:

The list of Ciphers for Python SSL binding for OpenSSL cannot be ordered in a specific list of preference.

This is a requirement for strict security environment where the ordered cipher list it's very important.

Apache support the ordering of ciphers trough the configuration of SSLHonorCipherOrder:
http://www.carbonwind.net/blog/post/Setting-the-preferred-cipher-suite-on-Apache-22x.aspx

Also Internet Explorer 7 support Ciphers order configuration:
https://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx?Redirected=true

Not having the ordered cipher list doesn't allow Python SSL stack configuration to be compliant with high security environment, de-facto representing a security vulnerability.

We suggest to fix the issue of lacking that feature.

----------
components: Library (Lib)
messages: 149831
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support ordering of Ciphers
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13635>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:44:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 10:44:54 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324290754.24.0.917273225252.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324291455.3588.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So, with this patch it should be possible to strictly enable ciphers such as:
> ECDHE-RSA-AES256-SHA   SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256) Mac=SHA1
> ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256) Mac=SHA1
> ECDH-RSA-AES256-SHA    SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
> ECDH-ECDSA-AES256-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
> 
> Which ciphers did you negotiated succesfully?

I didn't try to negotiate a specific cipher, I just saw that the
selected cipher was ECDHE-RSA-AES256-SHA (using a standard self-signed
certificate). I suppose other ciphers are accessible as well.

> While with the implementation of http://bugs.python.org/issue13627
> (DH/DHE ciphers) we should be able to negotiate:

You mean issue13626.

> Do you expect it would be a difficult step to handle also the DH/DHE
> (non ECC) negotiation?

No, but that's issue13626 :)

> Additionally it would be imho very important if the Python language
> would provide a "default ciphers setup" that look at maximum
> compatibility, performance and security.

You have the set_ciphers() method which allows you to set a "cipher
string":
http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_ciphers
OpenSSL itself has several generic cipher settings available:
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

For example the following setting gives you only ECDH ciphers with
strong encryption and authentication:

$ openssl ciphers -v 'kEECDH:!NULL:!aNULL'
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1

We are not cryptography experts and I don't think it would be a good
idea to maintain our own list of ciphers.

(furthermore, I don't think "maximum compatibility, performance and
security" are generally compatible with each other)

----------
title: Python  SSL stack doesn't support Elliptic Curve ciphers -> Python SSL stack doesn't support Elliptic Curve ciphers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:45:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 10:45:15 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324291077.57.0.776829405415.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324291478.3588.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Wow, i saw your patch for ECC SSL ciphers on http://bugs.python.org/issue13627 .
> 
> Do you think we can use the same method/concept as
> ssl.OP_SINGLE_ECDH_USE but ssl.OP_SINGLE_DH_USE for DH?

Of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:48:31 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:48:31 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324291711.32.0.678249591176.issue13626@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

In the meantime i added two other tickets on security and performance improvements of Python SSL support, to make it really complete and comparable to Apache/Dovecot/PHP in terms of configuration and capability: 

Python SSL stack doesn't support ordering of Ciphers
http://bugs.python.org/issue13635

Python SSL stack doesn't support Compression configuration
http://bugs.python.org/issue13634

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:49:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 10:49:03 +0000
Subject: [issue13635] Python SSL stack doesn't support ordering of Ciphers
In-Reply-To: <1324291443.18.0.0191846315359.issue13635@psf.upfronthosting.co.za>
Message-ID: <1324291743.05.0.727697554794.issue13635@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently it's just a matter of exposing SSL_OP_CIPHER_SERVER_PREFERENCE?

----------
nosy: +pitrou
type: security -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13635>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:53:36 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:53:36 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324292016.82.0.631284256073.issue13627@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

The Tor Project is composed of Cryptography experts, thus i am opening that ticket cause with our group we're implementing Tor2web based on Python that require *strict* security requirements for crypto.

The Tor Project heavily use Python for most of tools.

If you want we can open a discussion within Tor Project to have a "rationale method" to define a set of "default ciphers" considering the ration of security/performance/compatibility.

That way anyone using Python SSL/TLS will be sure in using a "Secure system" without the risk of legacy protocol such as SSLv2 or insecure ciphers like Export 40bit DES that are nowdays enabled by default.

Today a Python coder approaching SSL/TLS will have an insecurely configured TLS connection that can be hijacked via SSLv2 protocol or cracked via 40bit DES. 

Even Firefox, Chrome, IE, Opera disable by default certain protocols and certain ciphers, so imho it would be valuable to have a "Secure default", obviously considering and maintaining compatibility.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:55:58 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:55:58 +0000
Subject: [issue13635] Python SSL stack doesn't support ordering of Ciphers
In-Reply-To: <1324291443.18.0.0191846315359.issue13635@psf.upfronthosting.co.za>
Message-ID: <1324292158.87.0.653470830542.issue13635@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Looking at the code from mod_ssl i would say that this is the preference required https://issues.apache.org/bugzilla/show_bug.cgi?id=28665

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13635>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:58:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 10:58:05 +0000
Subject: [issue13634] Python SSL stack doesn't support Compression
	configuration
In-Reply-To: <1324291199.34.0.550922917675.issue13634@psf.upfronthosting.co.za>
Message-ID: <1324292285.38.0.700610420777.issue13634@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, there are two things here:
- allow to disable compression (it's enabled by default AFAICT) using the SSL_OP_NO_COMPRESSION flag
- allow to query compression status on SSL sockets using the SSL_get_current_compression() API

----------
nosy: +pitrou
stage:  -> needs patch
type:  -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13634>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:00:08 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 11:00:08 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
Message-ID: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>


New submission from naif <naif at globaleaks.org>:

By default the Python SSL/TLS Stack (client/server) expose unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).

This ticket is about defining a set of secure ciphers that should also provide maximum performance and compatibility, in order to allow any Python coder to use a Secure SSL/TLS stack without the need to became a Crypto Experts.

The discussion come from ticket http://bugs.python.org/issue13627 .

The proposal is to involve a discussion from the Tor Project (mailing list Tor-Talk & Tor-Dev) to define rationally a default set of ciphers/protocol for Python SSL/TLS from the Cryptography point of view .

----------
components: Library (Lib)
messages: 149839
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL Stack doesn't have a Secure Default set of ciphers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:14:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 11:14:24 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324292016.82.0.631284256073.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324293228.3588.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If you want we can open a discussion within Tor Project to have a
> "rationale method" to define a set of "default ciphers" considering
> the ration of security/performance/compatibility.

Why don't you simple define your own default ciphers and call the
set_ciphers() method?

That said, we could perhaps call set_ciphers("HIGH") by default. This
excludes legacy ciphers (such as RC4, DES) without having us maintain an
explicit list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:16:14 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 11:16:14 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324293374.62.0.705804784013.issue13627@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Created a ticket there for a default-setting:

Python SSL Stack doesn't have a Secure Default set of ciphers
http://bugs.python.org/issue13636

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:17:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 11:17:37 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324293457.36.0.697127487169.issue13636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I said, I don't think maintaining an explicit list of ciphers ourselves is reasonable, since there are no crypto experts (AFAICT) amongst the Python core developers.

Also, maintaining an explicit list of ciphers means people wouldn't benefit automatically from new ciphers unless Python itself is modified.

However, as I've proposed on issue13627, we could call set_ciphers("HIGH") by default. This excludes legacy ciphers (such as RC4, DES) without having us maintain an explicit list.

----------
nosy: +gregory.p.smith, pitrou
stage:  -> needs patch
type:  -> security
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:20:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 11:20:25 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <E1RcbGZ-0007w2-HP@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c6d41dd60d2d by Charles-Fran?ois Natali in branch '2.7':
Issue #11867: Make test_mailbox.test_lock_conflict deterministic (and fix a
http://hg.python.org/cpython/rev/c6d41dd60d2d

New changeset 0053b7c68a02 by Charles-Fran?ois Natali in branch '3.2':
Issue #11867: Make test_mailbox.test_lock_conflict deterministic (and fix a
http://hg.python.org/cpython/rev/0053b7c68a02

New changeset 020260ec44f2 by Charles-Fran?ois Natali in branch 'default':
Issue #11867: Make test_mailbox.test_lock_conflict deterministic (and fix a
http://hg.python.org/cpython/rev/020260ec44f2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:32:59 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 11:32:59 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324294379.35.0.440410647503.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

>From Antoine Pitrou (pitrou):
> Why don't you simple define your own default ciphers and call the
> set_ciphers() method?
> That said, we could perhaps call set_ciphers("HIGH") by default. This
> excludes legacy ciphers (such as RC4, DES) without having us maintain an
> explicit list.

I would suggest to follow a future proof approach that would consider:
* Disable SSLv2 (no one support it anymore)
* Enable Elliptic Curve Crypto and provide it as a priority (maximum security with strong performance gain)
* Enable Perfect Forward Secrecy ciphers first (DH ephemeral DHE)

* Provide an ordered cipher list for TLSv1
 - First ECC/DHE ciphers (Future Proof, PFS, with maximum performance)
 - Second DHE ciphers (Non-future proof, PFS, less performance)
 - Third TLSv1 AES ciphers (AES-128/AES-256, max compatibility, max performance)

* Then provide an ordered cipher list for SSLv3 (No AES support)
 - First 3DES DHE ciphers (PFS security)
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA       EDH-RSA-DES-CBC3-SHA

 - Second 3DES non-DHE cipher 
 SSL_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA

 - Third RC4 based encryption
 SSL_RSA_WITH_RC4_128_SHA


That way (but this is an approach to be discussed) we will pick-up a set of widely secure ciphers, high performance ciphers, highly compatible ciphers, but with a selection logic that's optimized for existing set of application and servers.

Or eventually hide that complexity for the Python developers by providing a set of "pre-configured" profiles to be used?

I always find ppl having difficulties in dealing with SSL/TLS, as a result SSL/TLS configuration it's often "by default" .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:04:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 12:04:30 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324296270.57.0.457274541207.issue13636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it seems we want 'HIGH:!aNULL:!eNULL' to avoid non-encrypted and non-authenticated ciphers.

> That way (but this is an approach to be discussed) we will pick-up
> a set of widely secure ciphers

Please read my message above and understand this faces us with a number of maintenance problems which can actually *decrease* security.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:16:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 12:16:01 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324296961.16.0.01528574605.issue13636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a possible patch for 3.2.
Probably needs a doc addition as well.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file24051/default_ciphers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:19:10 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 12:19:10 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324297150.81.0.798902647643.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Ok for:
'HIGH:!aNULL:!eNULL'

but also:
- Disable SSLv2
- Enable ECC/ECDHE by default
- Enable DH/DHE by default

With this in place, i would then suggest to see which is the "Default ordered list of ciphers" with an SSL cipher scanner/wireshark.

Then we would be able to know if the "default order" for the ciphers is reasonable or if we would need to manually organize it to have a preferred selection that consider security and performance, while keeping always compatibility.

What do you think of an approach like this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:27:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 12:27:51 +0000
Subject: [issue13635] Python SSL stack doesn't support ordering of Ciphers
In-Reply-To: <1324291443.18.0.0191846315359.issue13635@psf.upfronthosting.co.za>
Message-ID: <E1RccJp-0001jt-EH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c706f76c9ea8 by Antoine Pitrou in branch 'default':
Issue #13635: Add ssl.OP_CIPHER_SERVER_PREFERENCE, so that SSL servers
http://hg.python.org/cpython/rev/c706f76c9ea8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13635>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:33:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 12:33:47 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324298027.42.0.503894765572.issue13636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> - Disable SSLv2

It should be disabled automatically since the SSLv2 cipher suites are not part of "HIGH": see http://www.openssl.org/docs/apps/ciphers.html#SSL_v2_0_cipher_suites_

> - Enable ECC/ECDHE by default
> - Enable DH/DHE by default

These both require parameters. I think adding simple instructions in the documentation would go a long way towards helping users. It would also probably be more instructive than silently choosing default values.

(after all, for ECDHE it's a one-line addition; DHE needs a separate file so it's less immediate)

> With this in place, i would then suggest to see which is the "Default
> ordered list of ciphers" with an SSL cipher scanner/wireshark.

I'm not really able to do that. Perhaps you can help?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:34:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 12:34:22 +0000
Subject: [issue13635] Python SSL stack doesn't support ordering of Ciphers
In-Reply-To: <1324291443.18.0.0191846315359.issue13635@psf.upfronthosting.co.za>
Message-ID: <1324298062.7.0.439349679955.issue13635@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The new option is now committed in 3.3. Thanks for the report!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13635>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:34:52 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 19 Dec 2011 12:34:52 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1324298092.59.0.0329617281959.issue11867@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Should be fixed now, thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:45:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 12:45:19 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
In-Reply-To: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>
Message-ID: <E1Rccaj-000096-Ju@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0b03cb97dac0 by Victor Stinner in branch '3.2':
Issue #13628: python-gdb.py is now able to retrieve more frames in the Python
http://hg.python.org/cpython/rev/0b03cb97dac0

New changeset 5e3a172bba89 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13628: python-gdb.py is now able to retrieve more frames in
http://hg.python.org/cpython/rev/5e3a172bba89

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13628>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:53:00 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 12:53:00 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324299180.03.0.495012472007.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

To disable SSLv2 you must specifically disable it.

Look, i tried a server we're working on http://github.com/hellais/tor2web that's running on:

privacyresearch.infosecurity.ch port 8888

With 'HIGH:!aNULL:!eNULL' SSLv2 can connect:

openssl s_client -connect  privacyresearch.infosecurity.ch:8888 -ssl2

SSLv2, Cipher is DES-CBC3-MD5

So it negotiated SSLv2 with 3DES that's not a good choice, SSLv2 must be disabled.

We must disable SSLv1 with !SSLv2, for example i am using just now 'HIGH:!aNULL:!eNULL:!SSLv2:@STRENGTH' .

Trying to connect with SSLv2 fail:
openssl s_client -connect  privacyresearch.infosecurity.ch:8888 -ssl2
140735092141340:error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list:s2_clnt.c:450:

Trying to connect by default, it select a strong cipher (i still didn't setup the dh/stuff):

openssl s_client -connect  privacyresearch.infosecurity.ch:8888

Connect with: TLSv1/SSLv3, Cipher is AES256-SHA

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:58:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 12:58:25 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
In-Reply-To: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>
Message-ID: <E1RccnP-0001gR-SI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1cc8e9565339 by Victor Stinner in branch '2.7':
Issue #13628: python-gdb.py is now able to retrieve more frames in the Python
http://hg.python.org/cpython/rev/1cc8e9565339

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13628>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:59:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2011 12:59:41 +0000
Subject: [issue13628] python-gdb.py: patch to improve support of optimized
	Python
In-Reply-To: <1324225888.15.0.612025519119.issue13628@psf.upfronthosting.co.za>
Message-ID: <1324299581.3.0.286622170392.issue13628@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It is possible to retrieve "f" from the caller, PyEval_EvalCodeEx()

It does not always work, but it works sometimes, so it's better to try :-)

I applied my fix to Python 2.7, 3.2 and 3.3. lipython.py of Python 2.7 is outdated, it should be resynchronized with the one of Python 3.3. I will do that later and in another issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13628>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:02:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 13:02:32 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324299180.03.0.495012472007.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324299716.3588.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> We must disable SSLv1 with !SSLv2, for example i am using just now
> 'HIGH:!aNULL:!eNULL:!SSLv2:@STRENGTH' .

Ok, thanks for the investigation. I think "HIGH:!aNULL:!eNULL:!SSLv2" is
sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:03:09 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 13:03:09 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324299789.65.0.701910827139.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Yes, i can do the test for the ordered set of ciphers with all the patches in-place, can build a custom python 3.2 with the patch applied.

I would suggest to try to keep  ECC/ECDH/ECDHE enabled, conceptually we would like to have ECDHE as the first ciphers because it's the most modern, performance and secure.

For DH, you say that it require some file, but looking at mod_ssl Changelog it say:
      The reason was that mod_ssl's temporary RSA keys and DH parameters
      were stored in the persistent memory pool directly as OpenSSL's
      RSA and DH structures.

I mean, when i install Apache with SSL, from the system administrator point of view, i never have to create a file somewhere in order to have that ciphers.

Maybe also DH/EDH stuff can be done "in memory"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:08:22 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 13:08:22 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324300102.25.0.748776655218.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

About ECDHE use as a default, prioritized key exchange method, google is using it along with RC4:
http://www.julianevansblog.com/2011/11/https-encryption-increased-for-gmail-and-google.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:31:33 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 13:31:33 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324301493.21.0.301225362541.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

We could also disable all the ciphers that use MD5 for authentication:

MD5 has been disabled for SSL use due to it's weakness by:

- Firefox (All mozilla products now refuse any MD5 ciphers)
https://www.thesslstore.com/blog/index.php/firefox-to-stop-supporting-md5-based-ssl/
- Duracon by Jacob Appelbaum (Tor Project)
https://github.com/ioerror/duraconf

"HIGH:!aNULL:!eNULL:!SSLv2:!MD5" would do the magic, so we update the default to a modern, yet compatible set of SSL ciphers supported.

I don't want in any case to break compatibilities, but by default a software, should not support vulnerable, weak ciphers and this seems a good compromise.

Then the last fine tuning would be have the right preferred orders of ciphers to always prefer ECDHE (if available).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:37:22 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 13:37:22 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324301842.73.0.107913581224.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

It would be also useful to "Sort" the order of ciphers by it's strength.

This is done by the parameter @STRENGTH" :

>From http://www.openssl.org/docs/apps/ciphers.html

"Additionally the cipher string @STRENGTH can be used at any point to sort the current cipher list in order of encryption algorithm key length."

In that case the default cipher string would become:
"HIGH:!aNULL:!eNULL:!SSLv2:!MD5:@STRENGTH"

The logic for third party developers could be explained as:

Only =>128bit ciphers
Disable unauthenticated ciphers
Disable SSLv2 protocol
Disable weak MD5 hash as authentication
Sort the cipher preferences by it's strength

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:48:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 13:48:17 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324301493.21.0.301225362541.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324302460.3588.25.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> MD5 has been disabled for SSL use due to it's weakness by:

Apparently MD5 is already disabled by "HIGH:!SSLv2".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:50:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 13:50:58 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324299789.65.0.701910827139.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324302622.3588.27.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I would suggest to try to keep  ECC/ECDH/ECDHE enabled, conceptually
> we would like to have ECDHE as the first ciphers because it's the most
> modern, performance and secure.

However, this will also divide performance by a large factor (from 2x to
4x apparently).

> Maybe also DH/EDH stuff can be done "in memory"?

Yes, there are also APIs for that, but you still have to provide magic
numbers (or have Python provide them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:55:49 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 13:55:49 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324302949.54.0.594588770069.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

I confirm, tested "HIGH:!SSLv2" and MD5 cannot be negotiated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 15:47:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 14:47:19 +0000
Subject: [issue13634] Python SSL stack doesn't support Compression
	configuration
In-Reply-To: <1324291199.34.0.550922917675.issue13634@psf.upfronthosting.co.za>
Message-ID: <1324306039.33.0.662969492897.issue13634@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24052/compression.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13634>
_______________________________________

From report at bugs.python.org  Mon Dec 19 15:48:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 14:48:32 +0000
Subject: [issue13634] Python SSL stack doesn't support Compression
	configuration
In-Reply-To: <1324291199.34.0.550922917675.issue13634@psf.upfronthosting.co.za>
Message-ID: <1324306112.24.0.4830205016.issue13634@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(note that some OpenSSLs are built without compression, such as Mageia's)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13634>
_______________________________________

From report at bugs.python.org  Mon Dec 19 15:54:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 14:54:42 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324306482.76.0.215549465935.issue13636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> About ECDHE use as a default, prioritized key exchange method, google
> is using it along with RC4:

Hmmm... do note that RC4 is disabled with "HIGH".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:02:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 15:02:26 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324306946.46.0.605804963627.issue13620@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +easy, needs review -patch
nosy: +georg.brandl
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:05:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 19 Dec 2011 15:05:28 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1324307128.64.0.185689778185.issue13453@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Another failure on an OpenIndiana buildbot:
"""
======================================================================
ERROR: testTimeoutConnect (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/test_ftplib.py", line 837, in testTimeoutConnect
    ftp.connect(HOST, timeout=30)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/ftplib.py", line 142, in connect
    self.sock = socket.create_connection((self.host, self.port), self.timeout)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/socket.py", line 404, in create_connection
    raise err
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/socket.py", line 395, in create_connection
    sock.connect(sa)
socket.error: [Errno 146] Connection refused
"""

I guess it's always the same problem, a broken name resolution service which takes a long time to resolve "localhost".
I'll try to bump the timeouts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:13:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 15:13:31 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1324132031.61.0.321446919372.issue13453@psf.upfronthosting.co.za>
Message-ID: <1324307574.3588.28.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

>   File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275, in readinto
>     raise IOError("cannot read from timed out object")
> OSError: cannot read from timed out object

Ah, annoying. The NNTP tests use a single connection, and when a timeout
occurs in a test, subsequent tests will all fail with this error...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:14:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 15:14:14 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1324307654.4.0.469555095062.issue13453@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Jesus is the OpenIndiana buildbots' administrator.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:14:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 15:14:50 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <E1RcevQ-0001N6-QV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2228d985fdcc by Charles-Fran?ois Natali in branch '2.7':
Issue #13453: Try to increase some socket timeouts to make some buildbots stop
http://hg.python.org/cpython/rev/2228d985fdcc

New changeset d7daf98c068e by Charles-Fran?ois Natali in branch '3.2':
Issue #13453: Try to increase some socket timeouts to make some buildbots stop
http://hg.python.org/cpython/rev/d7daf98c068e

New changeset 307d698c3ece by Charles-Fran?ois Natali in branch 'default':
Issue #13453: Try to increase some socket timeouts to make some buildbots stop
http://hg.python.org/cpython/rev/307d698c3ece

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:15:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 15:15:16 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1324307716.85.0.276180875868.issue13612@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox, haypo
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13612>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:17:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 15:17:41 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>
Message-ID: <1324307861.52.0.342893278227.issue13583@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. Two things:

- there is a compilation warning using gcc:

/home/antoine/cpython/default/Modules/_sqlite/row.c: In function ?pysqlite_row_subscript?:
/home/antoine/cpython/default/Modules/_sqlite/row.c:128:26: attention : passing argument 1 of ?PySlice_GetIndicesEx? from incompatible pointer type

- you can use assertEqual to avoid defining the error message yourself

----------
nosy: +pitrou
stage:  -> patch review
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13583>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:23:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 15:23:15 +0000
Subject: [issue5424] Packed IPaddr conversion tests should be extended
In-Reply-To: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>
Message-ID: <E1Rcf3a-0002Vn-8T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 71e5a083f9b1 by Antoine Pitrou in branch '3.2':
Issue #5424: add tests for inet_ntoa, inet_ntop, inet_aton and inet_pton.
http://hg.python.org/cpython/rev/71e5a083f9b1

New changeset a3d5f522065f by Antoine Pitrou in branch 'default':
Issue #5424: add tests for inet_ntoa, inet_ntop, inet_aton and inet_pton.
http://hg.python.org/cpython/rev/a3d5f522065f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5424>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:23:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 15:23:45 +0000
Subject: [issue5424] Packed IPaddr conversion tests should be extended
In-Reply-To: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>
Message-ID: <1324308225.79.0.092683475789.issue5424@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have finally committed the patch. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5424>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:40:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 15:40:04 +0000
Subject: [issue6743] Add function compatible with print to pprint module
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1324309204.69.0.984543421291.issue6743@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Mon Dec 19 17:18:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 16:18:24 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <E1Rcfuw-0001IZ-V4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8b729d65cfd2 by Antoine Pitrou in branch 'default':
Issue #13627: Add support for SSL Elliptic Curve-based Diffie-Hellman
http://hg.python.org/cpython/rev/8b729d65cfd2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 17:19:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 16:19:09 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324311549.14.0.934199417151.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch now committed in 3.3.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Mon Dec 19 17:30:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 16:30:45 +0000
Subject: [issue13637] binascii.a2b_* functions could accept unicode strings
Message-ID: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

a2b_hex and friends accept only byte strings:

>>> binascii.a2b_hex(b'00')
b'\x00'
>>> binascii.a2b_hex('00')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' does not support the buffer interface

But they could just as well accept ASCII-only unicode strings. Also, with PEP 393, accessing the 8-bit ASCII data doesn't even need a conversion.

----------
components: Library (Lib)
messages: 149876
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: binascii.a2b_* functions could accept unicode strings
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13637>
_______________________________________

From report at bugs.python.org  Mon Dec 19 17:41:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 16:41:16 +0000
Subject: [issue13638] PyErr_SetFromErrnoWithFilenameObject is undocumented
Message-ID: <1324312876.6.0.318234215993.issue13638@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Its declaration can be found in Include/pyerrors.h.
Same for PyErr_SetExcFromWindowsErrWithFilenameObject.

----------
assignee: docs at python
components: Documentation
messages: 149877
nosy: arnaudc, docs at python, haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PyErr_SetFromErrnoWithFilenameObject is undocumented
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13638>
_______________________________________

From report at bugs.python.org  Mon Dec 19 18:30:12 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 19 Dec 2011 17:30:12 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324315812.99.0.999184395913.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I meant to paste the repro with distutils.core:

python -c "from distutils.core import setup; setup(name=u'foo')" sdist --formats gztar

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 19 18:27:22 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 19 Dec 2011 17:27:22 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324315642.88.0.61781572109.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This error is also encountered if the package name is unicode. The error can be simply reproduced with this command:

python -c "from setuptools import setup; setup(name=u'foo')" sdist --formats gztar

The error also occurs with the bdist command, and probably others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 19 18:37:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 17:37:23 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324316243.18.0.819463065453.issue13626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch adding the load_dh_params method on SSL contexts, and the OP_SINGLE_DH_USE option flag.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24053/dh.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Mon Dec 19 18:44:00 2011
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 19 Dec 2011 17:44:00 +0000
Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box
	is open
In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za>
Message-ID: <1324316640.12.0.40723849086.issue13630@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

IDLE does have a color scheme configuration for "found" as listed in the highlighting config dialog and internally as the Tkinter Text tag "hit". This looks like the stubs for functionality that never got implemented.

Take a look at the SearchBar IDLE extension. It provides incremental searching which highlights all matches.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13630>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:07:15 2011
From: report at bugs.python.org (David Butler)
Date: Mon, 19 Dec 2011 18:07:15 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324318035.44.0.91733772928.issue13616@psf.upfronthosting.co.za>


David Butler <croepha at gmail.com> added the comment:

sorry for the delay, I had to wait until the problem occurred again...

I gdb'ed into the process again, the backtrace is a little different this time...

(gdb) bt
#0  0xb76adfc6 in update_refs (containers=<optimized out>) at Modules/gcmodule.c:292
#1  collect (generation=2) at Modules/gcmodule.c:873
#2  0xb76ae5e3 in collect_generations () at Modules/gcmodule.c:996
#3  _PyObject_GC_Malloc (basicsize=16) at Modules/gcmodule.c:1457
#4  0xb76ae684 in _PyObject_GC_New (tp=0xb76f6aa0) at Modules/gcmodule.c:1467
#5  0xb761a8bd in list_iter (seq=
    [((None, u'to'), u'aves.rule'), ((None, u'rel'), u'ManyToOneRel'), ((None, u'name'), u'rule')]) at Objects/listobject.c:2873
#6  0xb75eef45 in PyObject_GetIter (o=
    [((None, u'to'), u'aves.rule'), ((None, u'rel'), u'ManyToOneRel'), ((None, u'name'), u'rule')]) at Objects/abstract.c:3083
#7  0xb7680f35 in PyEval_EvalFrameEx (f=
    Frame 0x9bcc0c4, for file /usr/lib/python2.7/xml/dom/pulldom.py, line 88, in startElementNS (self=<PullDOM(documentFactory=<DOMImplementation() at remote 0x9c217cc>, _ns_contexts=[{'http://www.w3.org/XML/1998/namespace': 'xml'}], pending_events=None, _current_context={...}, elementStack=[<Document(implementation=<...>, _elem_info={}, doctype=None, _id_search_stack=None, childNodes=<NodeList at remote 0xa2fac6c>, _id_cache={}) at remote 0xa2fac4c>, <Element(ownerDocument=<...>, nodeName=u'django-objects', nextSibling=None, parentNode=<...>, namespaceURI=None, prefix=None, _attrsNS={(None, u'version'): <Attr(ownerDocument=<...>, nodeName=u'version', ownerElement=<...>, value=u'1.0', namespaceURI=None, prefix=None, nodeValue=u'1.0', childNodes=<NodeList at remote 0xa2faccc>, name=u'version') at remote 0xa2facac>}, tagName=u'django-objects', childNodes=<NodeList at remote 0xa2fabcc>, _attrs={u'version': <...>}) at remote 0xa2faa8c>, <Element(ownerDocument=<...>, nodeName=u'object', namespaceURI=None, prefix=None,...(truncated), throwflag=0) at Python/ceval.c:2483
#8  0xb768189a in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, 
    pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4099
#9  call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4034
#10 PyEval_EvalFrameEx (f=
    Frame 0x9ed8f74, for file /usr/lib/python2.7/xml/sax/expatreader.py, line 338, in start_element_ns (self=<ExpatParser(_namespaces=1, _parser=<pyexpat.xmlparser at remote 0xa22fe2c>, _external_ges=1, _source=<InputSource(_InputSource__charfile=None, _InputSource__bytefile=None, _InputSource__public_id=None, _InputSource__system_id=None, _InputSource__encoding=None) at remote 0xa2fabac>, _decl_handler_prop=None, _bufsize=65516, _cont_handler=<PullDOM(documentFactory=<DOMImplementation() at remote 0x9c217cc>, _ns_contexts=[{'http://www.w3.org/XML/1998/namespace': 'xml'}], pending_events=None, _current_context={...}, elementStack=[<Document(implementation=<...>, _elem_info={}, doctype=None, _id_search_stack=None, childNodes=<NodeList at remote 0xa2fac6c>, _id_cache={}) at remote 0xa2fac4c>, <Element(ownerDocument=<...>, nodeName=u'django-objects', nextSibling=None, parentNode=<...>, namespaceURI=None, prefix=None, _attrsNS={(None, u'version'): <Attr(ownerDocument=<...>, nodeName=u'version', ownerElement=<...>, va...(truncated), throwflag=0) at Python/ceval.c:2666
#11 0xb7683508 in PyEval_EvalCodeEx (co=0x9dd6c80, globals=
    {'SAXNotRecognizedException': <type at remote 0x9c6967c>, 'expat': <module at remote 0x96cbd94>, '__name__': 'xml.sax.expatreader', 'feature_namespace_prefixes': 'http://xml.org/sax/features/namespace-prefixes', 'AttributesNSImpl': <classobj at remote 0x9d8db0c>, 'feature_string_interning': 'http://xml.org/sax/features/string-interning', '__package__': 'xml.sax', 'versi---Type <return> to continue, or q <return> to quit---step
on': '0.20', 'AttributesImpl': <classobj at remote 0x9d8dadc>, 'feature_namespaces': 'http://xml.org/sax/features/namespaces', '__doc__': "\nSAX driver for the pyexpat C module.  This driver works with\npyexpat.__version__ == '2.22'.\n", 'feature_validation': 'http://xml.org/sax/features/validation', 'create_parser': <function at remote 0x9ddba74>, '__builtins__': {'bytearray': <type at remote 0xb76ed660>, 'IndexError': <type at remote 0xb76f1520>, 'all': <built-in function all>, 'help': <_Helper at remote 0xb73643ac>, 'vars': <built-in function vars>, 'SyntaxError': <type at remote 0xb76f11a0>, 'unicode': <type at remote 0xb7701340>, 'UnicodeD...(truncated), locals=0x0, args=0x9d94510, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    closure=0x0) at Python/ceval.c:3253
#12 0xb7614f2a in function_call (func=<function at remote 0x9dd502c>, arg=
    (<ExpatParser(_namespaces=1, _parser=<pyexpat.xmlparser at remote 0xa22fe2c>, _external_ges=1, _source=<InputSource(_InputSource__charfile=None, _InputSource__bytefile=None, _InputSource__public_id=None, _InputSource__system_id=None, _InputSource__encoding=None) at remote 0xa2fabac>, _decl_handler_prop=None, _bufsize=65516, _cont_handler=<PullDOM(documentFactory=<DOMImplementation() at remote 0x9c217cc>, _ns_contexts=[{'http://www.w3.org/XML/1998/namespace': 'xml'}], pending_events=None, _current_context={...}, elementStack=[<Document(implementation=<...>, _elem_info={}, doctype=None, _id_search_stack=None, childNodes=<NodeList at remote 0xa2fac6c>, _id_cache={}) at remote 0xa2fac4c>, <Element(ownerDocument=<...>, nodeName=u'django-objects', nextSibling=None, parentNode=<...>, namespaceURI=None, prefix=None, _attrsNS={(None, u'version'): <Attr(ownerDocument=<...>, nodeName=u'version', ownerElement=<...>, value=u'1.0', namespaceURI=None, prefix=None, nodeValue=u'1.0', childNodes=<NodeList at remote 0xa2faccc>,...(truncated), kw=0x0) at Objects/funcobject.c:526

--- truncated ---

(gdb) b collect
Breakpoint 1 at 0xb76ade3c: file Modules/gcmodule.c, line 822.
(gdb) cont
Continuing.

( here i let it run for a about a minute )

^C
Program received signal SIGINT, Interrupt.
0xb76adfcb in update_refs (containers=<optimized out>) at Modules/gcmodule.c:290
290     in Modules/gcmodule.c
(gdb) print gc
$1 = (PyGC_Head *) 0xb770df00
(gdb) step
292     in Modules/gcmodule.c
(gdb) info locals
gc = 0xb770df00
(gdb) step
290     in Modules/gcmodule.c
(gdb) info locals
gc = 0xb770df00

I was going to leave the process running, and the debugger up, but I forgot that a reboot script was still enabled, and it caused the machine to reboot... so i am recompiling python with CFLAGS="-O0 ..." to try to fix some "value optimized out" issue in gdb... need to try to figure out what object its getting caught on... 

Could this be caused by one of the loadable libraries that I am importing? ( pyside, psycopg2, ... ) and one of those is making an object that isn't playing nice with the gc?

Also, I have attached a histogram of the cpu usage

I'll try to answer more of your questions when it happens next

----------
Added file: http://bugs.python.org/file24054/cpu_usage.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:12:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 18:12:08 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <E1Rchh1-0005d1-C3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 50267d2bb320 by Giampaolo Rodola' in branch 'default':
(bug #8684) fix 'fedora without thread buildbot' as per http://bugs.python.org/issue8684
http://hg.python.org/cpython/rev/50267d2bb320

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:13:26 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Dec 2011 18:13:26 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1324318406.65.0.09014109105.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This should now be fixed. Thanks for signaling.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Mon Dec 19 20:05:40 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Mon, 19 Dec 2011 19:05:40 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324321540.06.0.0513132840579.issue13620@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Hi.
The patch works fine on my box with Chromium 16 under Archlinux.

However, I think it might not work under Ubuntu or Debian, since the program is named "chromium-browser" on these distros, and it is missing from the list of tested browser. I am setting up an Ubuntu box to test and confirm this.

----------
nosy: +arnaudc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Mon Dec 19 20:25:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Dec 2011 19:25:11 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1324322711.41.0.526880866938.issue13051@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +haypo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Mon Dec 19 20:40:55 2011
From: report at bugs.python.org (Oleg Broytman)
Date: Mon, 19 Dec 2011 19:40:55 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324323655.88.0.671786930749.issue13620@psf.upfronthosting.co.za>


Changes by Oleg Broytman <phd at phdru.name>:


Removed file: http://bugs.python.org/file23986/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Mon Dec 19 20:41:43 2011
From: report at bugs.python.org (Oleg Broytman)
Date: Mon, 19 Dec 2011 19:41:43 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324323703.95.0.435024735782.issue13620@psf.upfronthosting.co.za>


Oleg Broytman <phd at phdru.name> added the comment:

I updated the patch. Thank you for reviewing!

----------
keywords: +patch
Added file: http://bugs.python.org/file24055/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Mon Dec 19 20:54:44 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 19 Dec 2011 19:54:44 +0000
Subject: [issue13601] sys.stderr should be unbuffered (or always line-buffered)
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1324324484.29.0.780076023192.issue13601@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

> I'm hesitant to make it line-buffered by default when directed to a 
> file, since this could significantly slow down a program that for some
> reason produces super-voluminous output (e.g. when running a program
> with heavy debug logging turned on).

Is that really the purpose of standard error though? Heavy debug output, in my experience, is usually sent to standard output or to another file.

Also, did anyone ever complain about this as a problem, given it is the default behaviour of Python 2?

In my view the requirements of seeing errors when they happen, and guaranteeing that they will always be seen no matter what happens afterwards, should weigh more heavily than this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Mon Dec 19 21:05:08 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 19 Dec 2011 20:05:08 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1324325108.04.0.532988665504.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

The changes are good as far as they go, but they only affect the documentation of sys.stderr and sys.stdout. 

I also suggested changes to the documentation of the "-u" flag, and to "What's New in Python 3.0", can someone look at that also?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Mon Dec 19 21:09:25 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 19 Dec 2011 20:09:25 +0000
Subject: [issue13601] sys.stderr should always be line-buffered
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1324325365.98.0.995472941291.issue13601@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I think we all agree line-buffering is sufficient, so I change the title.

----------
title: sys.stderr should be unbuffered (or always line-buffered) -> sys.stderr should always be line-buffered

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Mon Dec 19 21:13:19 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Mon, 19 Dec 2011 20:13:19 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324325599.65.0.336635453954.issue13620@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

The new patch works under Ubuntu but not not under Archlinux anymore (where the program is named "chromium").
 
Here is a patch that works with python 3.3 under both distributions.

----------
Added file: http://bugs.python.org/file24056/webbrowser.py-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Mon Dec 19 21:20:13 2011
From: report at bugs.python.org (Oleg Broytman)
Date: Mon, 19 Dec 2011 20:20:13 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324326013.42.0.659187589142.issue13620@psf.upfronthosting.co.za>


Changes by Oleg Broytman <phd at phdru.name>:


Removed file: http://bugs.python.org/file24055/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Mon Dec 19 21:20:37 2011
From: report at bugs.python.org (Oleg Broytman)
Date: Mon, 19 Dec 2011 20:20:37 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324326037.43.0.969198657137.issue13620@psf.upfronthosting.co.za>


Oleg Broytman <phd at phdru.name> added the comment:

I'm fine with that version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Mon Dec 19 22:35:34 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 19 Dec 2011 21:35:34 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1324330534.85.0.0851948715469.issue13051@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Would you be able to produce a unit test which fails before your patch is applied, but succeeds after applying your changes? That'll make your changes more likely to get accepted.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Mon Dec 19 22:35:55 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Mon, 19 Dec 2011 21:35:55 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324330555.08.0.546382061385.issue13620@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Here is a patch against the 3.3 documentation, mentionning the new supported browser types.

----------
Added file: http://bugs.python.org/file24057/webbrowser_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Tue Dec 20 00:53:20 2011
From: report at bugs.python.org (Stan Cox)
Date: Mon, 19 Dec 2011 23:53:20 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1324338800.51.0.509040155374.issue13405@psf.upfronthosting.co.za>


Stan Cox <scox at redhat.com> added the comment:

systemtap doesn't have have a ustack helper, but if the frame pointer were provided to PYTHON_FUNCTION_ENTRY, then it could be cached to provide python stack frame access.

--- Python/ceval.c.1	2011-12-07 11:18:03.733659382 -0500
+++ Python/ceval.c	2011-12-19 18:45:54.601309213 -0500
@@ -796,3 +796,3 @@
 	lineno = PyCode_Addr2Line(f->f_code, f->f_lasti);
-	PYTHON_FUNCTION_ENTRY(filename, name, lineno);
+	PYTHON_FUNCTION_ENTRY(filename, name, lineno, f);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Dec 20 01:23:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 20 Dec 2011 00:23:28 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324340608.75.0.969472117779.issue13616@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

It seems to be a real infinite loop. Bad thing. Could be a bug in an extension, difficult to say.

This is going to be VERY difficult to debug without a reproductible case we can try.

Could you possibly check the object type of the "infinite loop" object?. If the loop is from an object to itself, maybe you can instrumentalize python to detect this loop when created.

Add to your code "gc.collect()" is a frequent loop. It is going to suck CPU, but could reproduce the issue faster and make it easier to diagnose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:23:24 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Dec 2011 01:23:24 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
Message-ID: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

python -c "import tarfile; tarfile.open(u'hello.tar.gz', 'w|gz')"

produces

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 1687, in open
    _Stream(name, filemode, comptype, fileobj, bufsize),
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 431, in __init__
    self._init_write_gz()
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 459, in _init_write_gz
    self.__write(self.name + NUL)
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 475, in __write
    self.buf += s
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8b in position 1: ordinal not in range(128)


Remove the compression ('|gz') or remove the unicode name or run under Python 3 and the command completes without error.

The error does not occur under Python 3 (even with non-ascii characters), so it should be possible to create a tarfile with a unicode filename on Python 2.7.

This failure is the underlying cause of #11638.

----------
messages: 149896
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: UnicodeDecodeError when creating tar.gz with unicode name
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:28:52 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Dec 2011 01:28:52 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324344532.89.0.632895392225.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I believe the underlying cause of this issue is #13639.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:31:41 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 20 Dec 2011 01:31:41 +0000
Subject: [issue13634] Python SSL stack doesn't support Compression
	configuration
In-Reply-To: <1324291199.34.0.550922917675.issue13634@psf.upfronthosting.co.za>
Message-ID: <1324344701.2.0.187414844046.issue13634@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/issue13634>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:32:13 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 20 Dec 2011 01:32:13 +0000
Subject: [issue13635] Python SSL stack doesn't support ordering of Ciphers
In-Reply-To: <1324291443.18.0.0191846315359.issue13635@psf.upfronthosting.co.za>
Message-ID: <1324344733.52.0.290937074636.issue13635@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/issue13635>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:32:32 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 20 Dec 2011 01:32:32 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324344752.65.0.193197351782.issue13636@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/issue13636>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:37:59 2011
From: report at bugs.python.org (Hiroaki Kawai)
Date: Tue, 20 Dec 2011 01:37:59 +0000
Subject: [issue13640] add mimetype for application/vnd.apple.mpegurl
Message-ID: <1324345079.76.0.172332572268.issue13640@psf.upfronthosting.co.za>


New submission from Hiroaki Kawai <hiroaki.kawai at gmail.com>:

Add application/vnd.apple.mpegurl, which is used by smartphones recently.
It is registered in IANA : http://www.iana.org/assignments/media-types/application/vnd.apple.mpegurl

An application is described in http://tools.ietf.org/html/draft-pantos-http-live-streaming-07

----------
components: Library (Lib)
files: mimetypes.patch
keywords: patch
messages: 149898
nosy: Hiroaki.Kawai
priority: normal
severity: normal
status: open
title: add mimetype for application/vnd.apple.mpegurl
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24058/mimetypes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13640>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:41:38 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Dec 2011 01:41:38 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324345298.6.0.015765671183.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've created a repo to continue this work. I've integrated David's patch (thanks).

It's not obvious to me what the encoding should be. Python and the tarfile module can accept unicode filenames. It seems that only the gzip part of tarfile fails if a unicode name is passed. Encoding to 'utf-8' or the default file system encoding doesn't seem right (as the characters end up getting stored in the gzip archive itself). Additionally, encoding as 'utf-8' would cause the file to be created with a utf-8 filename, which would be undesirable.

So in the current repo, I've created a check to convert the filename to ASCII. If it can be converted to ASCII, it is converted and passed through to tarfile. This should address the majority of users who have thus encountered this issue. For those who wish to use non-ascii characters in project names or versions, one will have to use Python 3 or wait until #13639 is fixed.

Please review the enclosed patch.

Since one test fails (and is known to fail), should it omitted? Can it remain but be marked as "expected to fail"?

----------
hgrepos: +96

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:43:05 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Dec 2011 01:43:05 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324345385.43.0.495235581075.issue11638@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file24059/9e9ea96eb0dd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Tue Dec 20 03:12:25 2011
From: report at bugs.python.org (David Butler)
Date: Tue, 20 Dec 2011 02:12:25 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324340608.75.0.969472117779.issue13616@psf.upfronthosting.co.za>
Message-ID: <CANm61jdZb4AH4zQr3RigZ2=oBKommLq_nSBfdfDKeEPYEZaLJg@mail.gmail.com>


David Butler <croepha at gmail.com> added the comment:

2011/12/19 Jes?s Cea Avi?n <report at bugs.python.org>

I am willing to work toward a simplified test case, but its going to be
difficult, I am hoping that I can narrow down the source of the problem...

Forgive me, I'm gdb is actually a new thing to me... how could I check the
object type?
Also what do you mean exactly when you say "instrumentalize"

I started some valgrind testing today, (to try to figure out whats causing
some segfaults in a possibly unrelated bug, will this interfere with
testing for this bug?)

> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13616>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Tue Dec 20 03:27:48 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 20 Dec 2011 02:27:48 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324348068.21.0.160796091157.issue13616@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Instrumentalize: check for this pathological case (an object with a GC pointer back to itself) in the code that modify the GC pointers. Lets say, everytime code change the pointers, you test for this. Luckily you can learn the codepath creating this situation. Change and recompile python code for checking this.

Read Include/object.h. You will see that ANY python object has, at least, two components: a reference counter and a pointer to its type. Follow that pointer to type and get its name.

Let me try an example...

"""
gdb python
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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 "i386-pc-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/python...done.
(gdb) br PyTuple_New
Function "PyTuple_New" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (PyTuple_New) pending.
(gdb) r
Starting program: /usr/local/bin/python 
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[Switching to Thread 1 (LWP 1)]

Breakpoint 1, PyTuple_New (size=0) at Objects/tupleobject.c:50
50      Objects/tupleobject.c: No such file or directory.
        in Objects/tupleobject.c
(gdb) fin
Run till exit from #0  PyTuple_New (size=0) at Objects/tupleobject.c:50
0xfee650e4 in PyType_Ready (type=0xfef5cd00) at Objects/typeobject.c:4077
4077    Objects/typeobject.c: No such file or directory.
        in Objects/typeobject.c
Value returned is $1 = (PyObject *) 0x806202c
(gdb) print $1->ob_type
$2 = (struct _typeobject *) 0xfef5cb40
(gdb) print *($1->ob_type)
$3 = {ob_refcnt = 1, ob_type = 0xfef5cde0, ob_size = 0, tp_name = 0xfef07542 "tuple", tp_basicsize = 12, tp_itemsize = 4, 
  tp_dealloc = 0xfee568f0 <tupledealloc>, tp_print = 0xfee56c80 <tupleprint>, tp_getattr = 0, tp_setattr = 0, tp_compare = 0, 
  tp_repr = 0xfee57380 <tuplerepr>, tp_as_number = 0x0, tp_as_sequence = 0xfef52500, tp_as_mapping = 0xfef52528, 
  tp_hash = 0xfee56850 <tuplehash>, tp_call = 0, tp_str = 0, tp_getattro = 0xfee416d0 <PyObject_GenericGetAttr>, tp_setattro = 0, 
  tp_as_buffer = 0x0, tp_flags = 67519979, 
  tp_doc = 0xfef3b580 "tuple() -> empty tuple\ntuple(iterable) -> tuple initialized from iterable's items\n\nIf the argument is a tuple, the return value is the same object.", tp_traverse = 0xfee56440 <tupletraverse>, tp_clear = 0, 
  tp_richcompare = 0xfee56b10 <tuplerichcompare>, tp_weaklistoffset = 0, tp_iter = 0xfee56a60 <tuple_iter>, tp_iternext = 0, 
  tp_methods = 0xfef52540, tp_members = 0x0, tp_getset = 0x0, tp_base = 0x0, tp_dict = 0x0, tp_descr_get = 0, tp_descr_set = 0, 
  tp_dictoffset = 0, tp_init = 0, tp_alloc = 0, tp_new = 0xfee57680 <tuple_new>, tp_free = 0xfeede6a0 <PyObject_GC_Del>, 
  tp_is_gc = 0, tp_bases = 0x0, tp_mro = 0x0, tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist = 0x0, tp_del = 0, 
  tp_version_tag = 0}
"""

I break in the tuple creation routine. Then I let it finish. It is going to return a PyObject, a generic python object. I follow the type pointer and get the name of the type: 'tp_name = 0xfef07542 "tuple"'. I already knew the result was going to be a tuple, but it is nice to cross-check :)

Sometimes it is more complicated, and you have to cast pointers. Use the source code as your map.

Sorry, it is difficult to teach how to do such a low level debug remotely :).

PS: Remember to add "gc.collect()" in your mainloop. In this way you will hit the problem faster, because you don't have to wait for Python to invoke the collector implicitly. If you have tons of objects this can be actually slower. Try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Tue Dec 20 03:36:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 20 Dec 2011 02:36:07 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324348567.83.0.857576346847.issue13616@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

David, if you get desperate, let us know. If you can deal with Mercurial and compiling Python code, I could post a mercurial repository/branch with code modifications to help you to debug this.

But it is almost Christmas and I am VERY busy and have to do a few long distance trips yet, so that better be the last option. First try to advance a bit yourself. At least you will learn a lot.

But don't let this bug to languish...

If you can manage to reproduce the issue more easily, that would be VERY useful. Tell us too what external modules are you using.

Good luck.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Tue Dec 20 07:13:15 2011
From: report at bugs.python.org (Duncan Findlay)
Date: Tue, 20 Dec 2011 06:13:15 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1324361595.69.0.251062830248.issue1975@psf.upfronthosting.co.za>


Duncan Findlay <duncan at duncf.ca> added the comment:

I've been digging into this quite a bit, and I've been able to dig up a little more info.

* In Python 2.1, the behavior was very similar to what we have now -- signals were not blocked. http://bugs.python.org/issue465673 was filed reporting issues with readline on Solaris. The issue was basically that readline used setjmp/longjmp to handle the SIGINT, and the exception handler was being executed by the wrong thread. The fix that was implemented (for Python 2.2b1) was to block threads except to the main thread. There was some discussion at the time about this being the "proper" way according to POSIX. (http://groups.google.com/group/comp.lang.python/browse_frm/thread/61da54186fbeebf9)

* Python 2.2 and 2.3 had the opposite of the current behavior (i.e. all signals were blocked in threads). Several bugs were reported. Most of the problems seemed to be about blocked synchronous signals (e.g. SIGSEGV) leading to bad things, and the unkillable subprocesses caused when you fork/exec with signals block.
  - http://bugs.python.org/issue756924
  - http://bugs.python.org/issue949332
  - http://mail.python.org/pipermail/python-dev/2003-December/041138.html

  * The patch to fix these bugs was submitted as http://bugs.python.org/issue960406. Unfortunately, it was not well described and so the links to the above issues were not clear. The discussion in the tracker for 960406 revolves mostly around readline, and for good reason -- reverting to the 2.1 behavior required a fix to readline so as to not regress. Unfortunately,  I believe the main impetus behind the patch was to fix the handling of synchronous signals and unkillable subprocesses. It was implemented in Python 2.4.

* Since Python 2.4, everything's been working fine on Linux, because Linux will send signals to the main thread, only. Unfortunately, the problem remains that the signals in FreeBSD are generally handled by the user thread instead. This causes two problems.

  1. On FreeBSD, we must assume that every blocking system call, in *every thread*, can be interrupted, and we need to catch EINTR.

  2. On FreeBSD, we cannot block indefinitely in the main thread and expect to handle signals. This means that indefinite selects are not possible if we want to handle signals, and, perhaps more perversely, signal.pause() cannot be reliably used in the main thread.

  * Current attempts to fix this in the FreeBSD ports revert to the pre-2.4 behavior of blocking all signals. This leads to the same unkillable subprocesses and (presumably) issues with synchronous signals.

  * Attempts to fix this properly in Python are stalled because we've rightly detected that we're just oscillating between two behaviors, both having issues, and nobody has proposed a suitable middle ground.


I think I've found a suitable solution, that should resolve all of the issues:

* Block all *asynchronous* signals in user threads. The synchronous threads, such as SIGSEGV should not be blocked. (This was actually the original fix proposed for http://bugs.python.org/issue949332)

* Unblock all signals after a fork() in a thread, since the thread is now the main thread. This will solve the unkillable subprocesses.

* Readline should not be impacted by this change. The readline functionality was replaced as part of the 2.4 patch to not install readline's signal handlers, unless you're using a really old version of readline, *and* the original readline problems were only present when signals were unblocked, but we're going to start blocking them.

* As bamby points out in his first post here, this is unlikely to change the behavior of much code. Anything portable should work, it will now just be more predictable. I suppose if you were developing for FreeBSD (specifically for a stock unmodified Python compiled from source, not the version distributed through ports), this change could subtly change the behavior of an application. For most FreeBSD developers (i.e. the ones using ports), this change should simply result in killable subprocesses.


I will put together a patch, though I would like to see some consensus around this approach before I spend too much (more) time on this.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 20 08:33:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 07:33:38 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1324366418.13.0.348248918392.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>  1. On FreeBSD, we must assume that every blocking system call, in *every thread*, can be interrupted, and we need to catch EINTR.
> 
>  2. On FreeBSD, we cannot block indefinitely in the main thread and expect to handle signals. This means that indefinite selects are not possible if we want to handle signals, and, perhaps more perversely, signal.pause() cannot be reliably used in the main thread.

Well, I agree it makes matters more complicated, but if FreeBSD decides this behaviour is desireable, why would Python try to work around it?
To solve the select() problem you can have the signal handler write on a pipe (using signal.set_wakeup_fd (*)) and the select() call wait on that pipe. This also should allow to emulate signal.pause() (basically a select() with only the signal pipe).

IMHO, the general idea of Unix signals is a low-level kludge and any attempt to make it sane at the Python level is probably doomed to failure. Other synchronization methods should always be preferred, if possible.

(*) Linux has signalfd, but we don't expose it yet

----------
nosy: +haypo, neologix
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:58:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 08:58:44 +0000
Subject: [issue13637] binascii.a2b_* functions could accept unicode strings
In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za>
Message-ID: <1324371524.53.0.706151880564.issue13637@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24060/binasciistr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13637>
_______________________________________

From report at bugs.python.org  Tue Dec 20 10:18:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Dec 2011 09:18:43 +0000
Subject: [issue13634] Python SSL stack doesn't support Compression
	configuration
In-Reply-To: <1324291199.34.0.550922917675.issue13634@psf.upfronthosting.co.za>
Message-ID: <E1Rcvm8-0000Nn-Vt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 20b52be99b5d by Antoine Pitrou in branch 'default':
Issue #13634: Add support for querying and disabling SSL compression.
http://hg.python.org/cpython/rev/20b52be99b5d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13634>
_______________________________________

From report at bugs.python.org  Tue Dec 20 10:20:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 09:20:08 +0000
Subject: [issue13634] Python SSL stack doesn't support Compression
	configuration
In-Reply-To: <1324291199.34.0.550922917675.issue13634@psf.upfronthosting.co.za>
Message-ID: <1324372808.5.0.305348595451.issue13634@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now committed in 3.3.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13634>
_______________________________________

From report at bugs.python.org  Tue Dec 20 10:34:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 20 Dec 2011 09:34:40 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1324373680.14.0.959637318041.issue13405@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

As I said, I'm skeptical about the benefit vs maintenance burden ratio, especially since cPython doesn't target performance critical applications. I just fear that's a lot of intrusive code which will only be used by a handful of people worldwild, but I could be wrong.
But I'm definitely not stubborn, so if other core developers think it's a worthwhile feature, I won't object to it (but I'd really prefer if the patch also supported SystemTap).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Dec 20 11:10:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 20 Dec 2011 10:10:03 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1324375803.85.0.839854162682.issue1975@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> 1. On FreeBSD, we must assume that every blocking system call, in
> *every thread*, can be interrupted, and we need to catch EINTR.

That's true for every Unix. Every blocking syscall can return EINTR, and there are may non restartable syscalls. Writting code which depends on
a specific OS behavior, or whether the code is run from the main thread,
is broken.

>  2. On FreeBSD, we cannot block indefinitely in the main thread and
> expect to handle signals. This means that indefinite selects are not
> possible if we want to handle signals, and, perhaps more perversely,
> signal.pause() cannot be reliably used in the main thread.

The proper way to do so, in Python as in C, is to use pthread_sigmask
(http://docs.python.org/dev/library/signal.html#signal.pthread_sigmask)
- thanks to Victor. Just block all signals by default, and create a thread dedicated to signals management (that's the approach used by Java). You could also play some nice tricks with set_wakeup_fd (http://docs.python.org/dev/library/signal.html#signal.set_wakeup_fd).

> * Block all *asynchronous* signals in user threads.

What if some code expects to receive a signal from a thread other than
the main thread?

> * Unblock all signals after a fork() in a thread, since the thread is
> now the main thread.

What if a signal is delivered between fork() and unblock?

Really, signals and threads don't mix well (kinda like fork() and threads), so I don't think we can expect to fix this in Python. There's no free lunch, every design will chose will break existing code, or won't work as expected on a platform. The best we can do is to keep a sensitive default behavior (i.e. the one chosen by the OS designers), and offer APIs allowing the user to fine-tune the behavior according to its needs.

We've fixed many bugs pertaining to signals and threads during the last months, and we've gained a couple useful APIs to deal with signals and threads (pthread_sigmask(), sigwait(), etc).

I'd suggest to close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 20 12:06:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Dec 2011 11:06:14 +0000
Subject: [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <E1RcxGk-0000qC-06@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c9facd251725 by Charles-Fran?ois Natali in branch '2.7':
Followup to issue #11867: Use socketpair(), since FreeBSD < 8 doesn't really
http://hg.python.org/cpython/rev/c9facd251725

New changeset 9dee8a095faf by Charles-Fran?ois Natali in branch '3.2':
Followup to issue #11867: Use socketpair(), since FreeBSD < 8 doesn't really
http://hg.python.org/cpython/rev/9dee8a095faf

New changeset 9014e0cc5589 by Charles-Fran?ois Natali in branch 'default':
Followup to issue #11867: Use socketpair(), since FreeBSD < 8 doesn't really
http://hg.python.org/cpython/rev/9014e0cc5589

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11867>
_______________________________________

From report at bugs.python.org  Tue Dec 20 14:05:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Dec 2011 13:05:12 +0000
Subject: [issue13637] binascii.a2b_* functions could accept unicode strings
In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za>
Message-ID: <E1RczJN-00058a-Bc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eb8d62706d5f by Antoine Pitrou in branch 'default':
Issue #13637: "a2b" functions in the binascii module now accept ASCII-only unicode strings.
http://hg.python.org/cpython/rev/eb8d62706d5f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13637>
_______________________________________

From report at bugs.python.org  Tue Dec 20 14:06:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 13:06:32 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
Message-ID: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Similarly to #13637 for the binascii module, the decoding functions in the base64 module could accept ASCII-only unicode strings.

----------
components: Library (Lib)
keywords: easy
messages: 149912
nosy: pitrou
priority: normal
severity: normal
status: open
title: decoding functions in the base64 module could accept unicode strings
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Tue Dec 20 14:09:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 13:09:20 +0000
Subject: [issue13637] binascii.a2b_* functions could accept unicode strings
In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za>
Message-ID: <1324386560.14.0.416831539466.issue13637@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed now.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13637>
_______________________________________

From report at bugs.python.org  Tue Dec 20 14:09:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 13:09:24 +0000
Subject: [issue13637] binascii.a2b_* functions could accept unicode strings
In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za>
Message-ID: <1324386564.98.0.753122234618.issue13637@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13637>
_______________________________________

From report at bugs.python.org  Tue Dec 20 16:00:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 15:00:30 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324393230.98.0.970654514823.issue12708@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks like a reasonable request to me, and the patch looks generally ok as well.

----------
nosy: +neologix, pitrou
stage:  -> patch review
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 16:03:45 2011
From: report at bugs.python.org (Joonas Kuorilehto)
Date: Tue, 20 Dec 2011 15:03:45 +0000
Subject: [issue13642] urllib incorrectly quotes username and password in https
	basic auth
Message-ID: <1324393425.24.0.243026081887.issue13642@psf.upfronthosting.co.za>


New submission from Joonas Kuorilehto <oh8gdv at gmail.com>:

Reproduction:

>>> import urllib
>>> urllib.urlopen("https://example.com/")
Enter username for Test Site at example.com: user
Enter password for user in Test Site at example.com: top secret
Enter username for Test Site at example.com:
# If the correct password contains spaces, nothing will be accepted.

The problem is that the password in basic auth is URI quoted and then base64 encoded. The password should not be quoted.

RFC 2617:
      userid      = *<TEXT excluding ":">
      password    = *TEXT
      base64-user-pass  = <base64 [4] encoding of user-pass,
                       except not limited to 76 char/line>

I traced the problem with Pydev to urllib retry_https_basic_auth where I can see that
  user = "user"
  passwd = "my secret password"

After that, the path is like this:
self.retry_https_basic_auth:
  self.open(fullurl="https://user:my%20%secret%20password at example.com/")
  self.open_https(url="://user:my%20%secret%20password at example.com/")
  => in open_https:
    host, selector = splithost(url)
    user_passwd, host = splituser(host)
    host = unquote(host)

user_passwd is not unquoted, host is.

I found closely related Issue2244 - but did not confirm where this bug has been introduced. I added some people from 2244 to this issue. I hope that is ok.

I think a test should be added that covers usernames and passwords with spaces to avoid further regressions. The reproduction code given works with Python 2.4.3 urllib. This probably also affects python3, did not try.

----------
components: Library (Lib)
messages: 149915
nosy: carljm, joneskoo, orsenthil
priority: normal
severity: normal
status: open
title: urllib incorrectly quotes username and password in https basic auth
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13642>
_______________________________________

From report at bugs.python.org  Tue Dec 20 16:04:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 15:04:55 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324393495.16.0.134463591357.issue12708@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

One nit: the patch needs "versionadded" tags for the two new functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 16:13:21 2011
From: report at bugs.python.org (Joonas Kuorilehto)
Date: Tue, 20 Dec 2011 15:13:21 +0000
Subject: [issue9725] urllib.request.FancyURLopener won't connect to pages
	requiring username and password
In-Reply-To: <1283274337.79.0.0864543833676.issue9725@psf.upfronthosting.co.za>
Message-ID: <1324394001.55.0.147895473243.issue9725@psf.upfronthosting.co.za>


Changes by Joonas Kuorilehto <oh8gdv at gmail.com>:


----------
nosy: +joneskoo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9725>
_______________________________________

From report at bugs.python.org  Tue Dec 20 16:25:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 15:25:13 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324394713.22.0.624227365759.issue13639@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:21:52 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 20 Dec 2011 17:21:52 +0000
Subject: [issue13614] `setup.py register` fails if long_description contains
	RST
In-Reply-To: <1324069250.69.0.136486094973.issue13614@psf.upfronthosting.co.za>
Message-ID: <1324401712.18.0.420950440327.issue13614@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

A good analysis of the issue is made by Jason Conti at Ubuntu bug report mentioned in the first commit.

----------
title: `setup.py register` fails with traceback -> `setup.py register` fails if long_description contains RST

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13614>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:22:42 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 20 Dec 2011 17:22:42 +0000
Subject: [issue13614] `setup.py register` fails if long_description contains
	RST
In-Reply-To: <1324069250.69.0.136486094973.issue13614@psf.upfronthosting.co.za>
Message-ID: <1324401762.9.0.300856182706.issue13614@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

s/commit/comment/ sry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13614>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:34:13 2011
From: report at bugs.python.org (samwyse)
Date: Tue, 20 Dec 2011 17:34:13 +0000
Subject: [issue6321] Reload Python modules when running programs
In-Reply-To: <1245648620.51.0.901061764952.issue6321@psf.upfronthosting.co.za>
Message-ID: <1324402453.29.0.828782240191.issue6321@psf.upfronthosting.co.za>


samwyse <samwyse at gmail.com> added the comment:

[issue5847] fixed in 2.7/3.1

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6321>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:34:25 2011
From: report at bugs.python.org (Tycho Andersen)
Date: Tue, 20 Dec 2011 17:34:25 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1324402465.09.0.305202616076.issue13051@psf.upfronthosting.co.za>


Tycho Andersen <tycho at tycho.ws> added the comment:

Attached is a patch which contains a testcase as well. A few notes about this testcase:

1. I couldn't figure out how to get it to run correctly after all the other tests had run, so I had to run it first. This seems lame. One possible fix is to run each testcase in curses.wrapper; I'd be happy to change this patch to do that if it's more acceptable.

2. This testcase only tests one of the two bugs this patch fixes. The other seems much harder to write a testcase for, since you have to have a terminal such that curses.LINES * curses.COLUMS > sys.getrecursionlimit(). If there's a good way to guarantee this, I'd be happy to write a testcase for it.

Comments are appreciated!

----------
Added file: http://bugs.python.org/file24061/textpad-recursion-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:51:11 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 20 Dec 2011 17:51:11 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324403471.14.0.766379691763.issue12708@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Thanks for the feedback Antoine!

I updated the patch to latest default tip and added the requested tags to the docs.

----------
hgrepos: +97

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:51:56 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 20 Dec 2011 17:51:56 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324403516.03.0.633118501787.issue12708@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24062/8a9e14cda106.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:54:08 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 20 Dec 2011 17:54:08 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324403648.23.0.833329377258.issue12708@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Removed file: http://bugs.python.org/file22860/mp-starmap-w-docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 19:07:45 2011
From: report at bugs.python.org (=?utf-8?b?Q2hyaXN0aWFuIEjDpGdnc3Ryw7Zt?=)
Date: Tue, 20 Dec 2011 18:07:45 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1324404465.78.0.766104622428.issue3905@psf.upfronthosting.co.za>


Changes by Christian H?ggstr?m <pajton at kalvdans.no-ip.org>:


----------
nosy: +chn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Tue Dec 20 19:18:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 20 Dec 2011 18:18:33 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324405113.18.0.669407687708.issue12708@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Looks good to me, except for another minor nit:
"""
the elements of the `iterable` are expected to be tuples
"""

AFAICT, you just require the elements of `?terables` to be iterables, not necessarily tuples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 19:56:05 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 20 Dec 2011 18:56:05 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324407365.87.0.86310030664.issue12708@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

You're right. I've updated the docs accordingly, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 19:56:24 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 20 Dec 2011 18:56:24 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324407384.01.0.116140571138.issue12708@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24063/c02fbcda56f3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 19:56:57 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 20 Dec 2011 18:56:57 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324407417.06.0.760621113121.issue12708@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Removed file: http://bugs.python.org/file24062/8a9e14cda106.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Tue Dec 20 20:02:21 2011
From: report at bugs.python.org (Martin)
Date: Tue, 20 Dec 2011 19:02:21 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
Message-ID: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>


New submission from Martin <gzlist at googlemail.com>:

Currently when running Python on a non-OSX posix environment under either the C locale, or with an invalid or missing locale, it's not possible to operate using unicode filenames outside the ascii range. Using bytes works, as does reading expecting unicode, using the surrogates hack.

This makes robustly working with non-ascii filenames on different platforms needlessly annoying, given no modern nix should have problems just using UTF-8 in these cases.

See the downstream bzr bug for more:
<https://bugs.launchpad.net/bzr/+bug/794353>

One option is to just use UTF-8 for encoding and decoding filenames when otherwise ascii would be used. As a strict superset, this shouldn't break too many existing assumptions, and it's unlikely that non-UTF-8 filenames will accidentally be mangled due to a locale setting blip. See the attached patch for this behaviour change. It does not include a test currently, but it's possible to write one using subprocess and overriden LANG and LC_ALL vars.

----------
components: Interpreter Core
files: /tmp/filesystem_encoding_utf8.patch
keywords: patch
messages: 149924
nosy: benjamin.peterson, gz
priority: normal
severity: normal
status: open
title: 'ascii' is a bad filesystem default encoding
versions: Python 3.3
Added file: http://bugs.python.org/file24064//tmp/filesystem_encoding_utf8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Tue Dec 20 20:17:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Dec 2011 19:17:07 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324408627.98.0.816037874816.issue13643@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure why having a locale set to C or something invalid should be considered a Python bug.  You have to handle un-decodable filenames no matter what you do, since things aren't always encoded in utf-8 on non-OSX unix even when that is the system locale.  It's just something you have to live with.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Tue Dec 20 20:37:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2011 19:37:41 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324409861.03.0.901067638959.issue13643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Currently when running Python on a non-OSX posix environment
> under either the C locale, or with an invalid or missing locale,
> it's not possible to operate using unicode filenames outside
> the ascii range.

It was already discussed: using a different encoding for filenames and for other things is really not a good idea. The main problem is the interaction with other programs.

Read discussion of issues #8622, #8775 and #9992.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Tue Dec 20 20:38:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2011 19:38:54 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324409934.82.0.179686755151.issue13643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> under either the C locale, or with an invalid or missing locale

The right fix is to fix your locale, not Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Tue Dec 20 21:24:44 2011
From: report at bugs.python.org (Martin)
Date: Tue, 20 Dec 2011 20:24:44 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324412684.22.0.763687005894.issue13643@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

> I'm not sure why having a locale set to C or something invalid should be
> considered a Python bug.  You have to handle un-decodable filenames no
> matter what you do, since things aren't always encoded in utf-8 on non-OSX
> unix even when that is the system locale.  It's just something you have to
> live with.

This is more about un-encodable filenames. At the moment work with non-ascii filenames in Python robustly requires two branches, one using unicode and one that encodes to bytestrings and deals with the case where the name can't be represented in the declared filesystem encoding. That may be something that just had to be lived with, but it's a little annoying when even without a UTF-8 locale for a particular process, that's what most systems will want on disk.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Tue Dec 20 21:45:12 2011
From: report at bugs.python.org (Martin)
Date: Tue, 20 Dec 2011 20:45:12 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324413912.22.0.755313670707.issue13643@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

> It was already discussed: using a different encoding for filenames and for
> other things is really not a good idea. The main problem is the interaction
> with other programs.

Yes, for many programs, a change like this will mean they create the file, but then throw a traceback anyway when trying to print its name to stdout or something.

> Read discussion of issues #8622, #8775 and #9992.

Thanks. I agree that spreading different values to things like subprocess arguments and the environment is asking for trouble. Just changing how unicode filename are encoded by default seems safer, though it certainly won't help all code.

> The right fix is to fix your locale, not Python.

I've found that hard to stick to in the face of bug reports where "your locale" turns out to be "the locale used by some cronjob". Fixing my library to work under LANG=C is easier than bugging every downstream project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Tue Dec 20 22:33:34 2011
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 20 Dec 2011 21:33:34 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1324416814.79.0.985781219595.issue10079@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I went through the changes in "idlelib20101012_From_r32a3.patch". 

A lot of the changes are for using relative imports. Those changes aside, here is a list of issues that this patch covers. Most of these issues already have patches that are included in the large patch.

EditorWindow.py, textView.py:
    issue964437 - "idle help is modal"

EditorWindow.py, OutputWindow.py, PyShell.py:
    issue1207589 - "Right Click Context Menu"

ClassBrowser.py:
    patch in issue1612262 - "Class Browser doesn't show internal classes"

FileRevert.py:
    patch in issue1721083 - "Add File - Reload"

IOBinding.py:
    patch in issue6699 - "IDLE: Warn user about overwriting a file that has a newer version on filesystem"
    patch in issue4832 - "idle filename extension"

PyShell.py:
    - use "subprocess" module - already fixed in issue12540
    - patch for "paste_callback" in issue3359 - "Pasted \n not same as typed \n"
    - fix for issue6698 "IDLE no longer opens only an edit window when configured to do so"
 
    
There are two major changes that are not covered by other issues (AFAIK). 
1) The "PseudoStderrFile" in PyShell.py brings the shell forward if an error occurs. I like this behavior.
2) Run a script without saving it first. This functionality is scattered across several files.

There are several other small tweaks in the patch that will need some review. 

If I missed anything, please add a comment.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Tue Dec 20 22:35:26 2011
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 20 Dec 2011 21:35:26 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1324416926.13.0.873042242737.issue10079@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

minor mistake - issue3559 "Pasted \n not same as typed \n"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Tue Dec 20 23:14:14 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 20 Dec 2011 22:14:14 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1324419254.67.0.372088731243.issue10079@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks, Roger.  It would also be helpful if you ascertain for the overlaps which of the two versions is newer, the individual issue/path or the large feature diff.  The relative import changes should not be applied in the standard library; they were specifically removed earlier.

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Tue Dec 20 23:20:32 2011
From: report at bugs.python.org (David Butler)
Date: Tue, 20 Dec 2011 22:20:32 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324419632.53.0.977548705884.issue13616@psf.upfronthosting.co.za>


David Butler <croepha at gmail.com> added the comment:

I have 10 identical test machines running this this code ( operating systems are cloned ). I am not usning valgrind in these tests, it was causing various issues...

(gdb) info sharedlibrary
>From        To          Syms Read   Shared Object Library
0xb75a02b0  0xb76baa38  Yes         /usr/lib/libpython2.7.so.1.0
0xb75695a0  0xb7575878  Yes         /lib/libpthread.so.0
0xb7422060  0xb7529374  Yes         /lib/libc.so.6
0xb7404bd0  0xb7405b28  Yes         /lib/libdl.so.2
0xb73ffbc0  0xb7400498  Yes         /lib/libutil.so.1
0xb73dd360  0xb73f7e58  Yes         /lib/libm.so.6
0xb77288d0  0xb773f97f  Yes         /lib/ld-linux.so.2
0xb7721310  0xb77226d8  Yes         /usr/lib/python2.7/lib-dynload/time.so
0xb728c130  0xb728e4b8  Yes         /usr/lib/python2.7/site-packages/zope/interface/_zope_interface_coptimizations.so
0xb7284060  0xb7286cf8  Yes         /usr/lib/python2.7/lib-dynload/strop.so
0xb72772a0  0xb727d648  Yes         /usr/lib/python2.7/lib-dynload/_socket.so
0xb7271c50  0xb72729e8  Yes         /usr/lib/python2.7/lib-dynload/_functools.so
0xb726a7d0  0xb726deb8  Yes         /usr/lib/python2.7/lib-dynload/_ssl.so
0xb721ec00  0xb7253f28  Yes         /usr/lib/libssl.so.1.0.0
0xb70f47c0  0xb71d3dd8  Yes         /usr/lib/libcrypto.so.1.0.0
0xb70a3b20  0xb70af7b8  Yes         /lib/libz.so.1
0xb7264130  0xb72653c8  Yes         /usr/lib/python2.7/lib-dynload/cStringIO.so
0xb709aab0  0xb709e108  Yes         /usr/lib/python2.7/lib-dynload/_struct.so
0xb70934c0  0xb70958a8  Yes         /usr/lib/python2.7/lib-dynload/operator.so
0xb708b7e0  0xb708e868  Yes         /usr/lib/python2.7/lib-dynload/_collections.so
0xb707db00  0xb7083dd8  Yes         /usr/lib/python2.7/lib-dynload/itertools.so
0xb725f7d0  0xb725ff98  Yes         /usr/lib/python2.7/lib-dynload/_bisect.so
0xb7077920  0xb7078ee8  Yes         /usr/lib/python2.7/lib-dynload/_heapq.so
0xb7073970  0xb7074028  Yes         /usr/lib/python2.7/lib-dynload/grp.so
0xb771d510  0xb771d6f8  Yes         /usr/lib/python2.7/site-packages/twisted/python/_initgroups.so
0xb7062bf0  0xb706d3f8  Yes         /usr/lib/python2.7/lib-dynload/datetime.so
0xb705ab90  0xb705d358  Yes         /usr/lib/python2.7/lib-dynload/binascii.so
0xb7055a00  0xb7057018  Yes         /usr/lib/python2.7/lib-dynload/fcntl.so
0xb704d9a0  0xb7051258  Yes         /usr/lib/python2.7/lib-dynload/math.so
0xb7046e80  0xb7047d48  Yes         /usr/lib/python2.7/lib-dynload/_hashlib.so
0xb7042d90  0xb7043d78  Yes         /usr/lib/python2.7/lib-dynload/_random.so
0xb703c460  0xb703e548  Yes         /usr/lib/python2.7/lib-dynload/select.so
0xb7036360  0xb7036e18  Yes         /usr/lib/python2.7/lib-dynload/termios.so
0xb7032660  0xb7032968  Yes         /usr/lib/python2.7/site-packages/twisted/internet/_sigchld.so
0xb6ce7930  0xb6ed3188  Yes         /usr/lib/python2.7/site-packages/PySide/QtCore.so
0xb6c903b0  0xb6ca3b58  Yes         /usr/lib/libpyside-python2.7.so.1.0
0xb7016230  0xb7023058  Yes         /usr/lib/libshiboken-python2.7.so.1.0
0xb69ba370  0xb6b4c358  Yes         /usr/lib/qt4/libQtCore.so.4
0xb68cd7e0  0xb693dac8  Yes         /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/libstdc++.so.6
0xb686a390  0xb6880a18  Yes         /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/libgcc_s.so.1
0xb6860e90  0xb68655c8  Yes         /lib/librt.so.1
---Type <return> to continue, or q <return> to quit---
0xb5d81c30  0xb65d9cf8  Yes         /usr/lib/python2.7/site-packages/PySide/QtGui.so
0xb54d9e50  0xb5ba8a38  Yes         /usr/lib/qt4/libQtGui.so.4
0xb5394b80  0xb53b0a58  Yes         /usr/lib/libpng15.so.15
0xb5315a80  0xb5377748  Yes         /usr/lib/libfreetype.so.6
0xb5305910  0xb530a278  Yes         /usr/lib/libSM.so.6
0xb52eee00  0xb52fddd8  Yes         /usr/lib/libICE.so.6
0xb52e3740  0xb52e8be8  Yes         /usr/lib/libXrender.so.1
0xb52db5c0  0xb52dfa48  Yes         /usr/lib/libXrandr.so.2
0xb52b0f50  0xb52ca548  Yes         /usr/lib/libfontconfig.so.1
0xb529f220  0xb52a8e98  Yes         /usr/lib/libXext.so.6
0xb519b580  0xb5220388  Yes         /usr/lib/libX11.so.6
0xb5173200  0xb5181a38  Yes         /lib/libbz2.so.1
0xb5151580  0xb5167338  Yes         /usr/lib/libexpat.so.1
0xb513e0c0  0xb514b988  Yes         /usr/lib/libxcb.so.1
0xb5131b60  0xb51328b8  Yes         /usr/lib/libXau.so.6
0xb512c0f0  0xb512dab8  Yes         /usr/lib/libXdmcp.so.6
0xb50417e0  0xb50f0cf8  Yes         /usr/lib/python2.7/site-packages/PySide/QtNetwork.so
0xb4f13ff0  0xb4fd6f18  Yes         /usr/lib/qt4/libQtNetwork.so.4
0xb702d1e0  0xb702ebd8  Yes         /usr/lib/python2.7/lib-dynload/_locale.so
0xb4ed2ab0  0xb4ee4fa8  Yes         /usr/lib/python2.7/site-packages/psycopg2/_psycopg.so
0xb4ea7d90  0xb4ebe638  Yes (*)     /usr/lib/libpq.so.5
0xb4e8fc90  0xb4e9da98  Yes         /usr/lib/python2.7/lib-dynload/cPickle.so
0xb4e84c70  0xb4e89498  Yes         /usr/lib/python2.7/lib-dynload/array.so
0xb4e69d90  0xb4e7cb08  Yes         /usr/lib/python2.7/lib-dynload/_ctypes.so
0xb4e5f310  0xb4e62638  Yes         /usr/lib/libffi.so.5
0xb4ec8100  0xb4ec9ab8  Yes         /lib/libuuid.so.1
0xb6fb2200  0xb6fb4618  Yes         /usr/lib/libXfixes.so
0xb6fa93e0  0xb6fae248  Yes         /usr/lib/libXcursor.so.1
0xb6f9ad70  0xb6fa4808  Yes         /usr/lib/libXi.so
0xb4e316d0  0xb4e56308  Yes         /usr/lib/python2.7/site-packages/PIL/_imaging.so
0xb4ddfff0  0xb4e134c8  Yes         /usr/lib/libjpeg.so.8
0xb6f79d00  0xb6f8d748  Yes         /usr/lib/python2.7/lib-dynload/_io.so
0xb6f6fef0  0xb6f724d8  Yes         /usr/lib/python2.7/lib-dynload/zlib.so
0xb4d4c190  0xb4db81e8  Yes         /usr/lib/python2.7/site-packages/PySide/QtWebKit.so
0xb4049e70  0xb4ade738  Yes         /usr/lib/qt4/libQtWebKit.so.4
0xb3e22850  0xb3e90648  Yes         /usr/lib/libsqlite3.so.0
0xb3de9c20  0xb3e13f28  Yes         /usr/lib/qt4/libphonon.so.4
0xb3dcd0d0  0xb3dd0548  Yes         /usr/lib/python2.7/site-packages/alsaaudio.so
0xb3d302c0  0xb3db2648  Yes         /usr/lib/libasound.so.2
0xb6fb9b60  0xb6fbcef8  Yes         /usr/lib/qt4/plugins/imageformats/libqgif.so
0xb3509f30  0xb350cd88  Yes         /usr/lib/qt4/plugins/imageformats/libqico.so
0xaebf0710  0xaebf3c28  Yes         /usr/lib/qt4/plugins/imageformats/libqjpeg.so
0xade9ad30  0xadea6eb8  Yes (*)     /usr/lib/libresolv.so
0xade8dfa0  0xade955c8  Yes         /lib/libnss_files.so.2
0xade86da0  0xade89e18  Yes         /lib/libnss_dns.so.2
---Type <return> to continue, or q <return> to quit---
0xad63b080  0xad63c6e8  Yes         /usr/lib/qt4/plugins/imageformats/libqsvg.so
0xad601ac0  0xad633038  Yes         /usr/lib/qt4/libQtSvg.so.4
0xad4a5610  0xad4ab728  Yes         /usr/lib/python2.7/lib-dynload/_json.so
0xad499640  0xad49f578  Yes         /usr/lib/python2.7/lib-dynload/pyexpat.so
0xad018350  0xad01a708  Yes         /usr/lib/python2.7/lib-dynload/unicodedata.so

I am importing twisted, pyside, django, psycopg2, and datetuil 


3 of the machines had a stall much like the last two backtraces, except now originating from my gc.collect() call:

#0  0xb769e9ff in update_refs (containers=0xb7709328) at Modules/gcmodule.c:290
#1  0xb769f55f in collect (generation=2) at Modules/gcmodule.c:873
#2  0xb769f98d in gc_collect (self=0x0, args=(), kws=0x0) at Modules/gcmodule.c:1067
#3  0xb75f0e91 in PyCFunction_Call (func=<built-in function collect>, arg=(), kw=0x0)
    at Objects/methodobject.c:85
#4  0xb7666287 in call_function (pp_stack=0xbfa61960, oparg=0) at Python/ceval.c:4013
#5  0xb7662dff in PyEval_EvalFrameEx (f=
    Frame 0xb0b5b9c, for file /usr/lib/python2.7/site-packages/qt4reactor.py, line 261, in doIteration (self=<QtReactor(waker=<_UnixWaker(i=13, fileno=<function at remote 0xa688994>, reactor=<...>, o=14) at remote 0xa684dac>, threadCallQueue=[], _cancellations=0, _justStopped=False, _newTimedCalls=[], _pendingTimedCalls=[<DelayedCall(resetter=<instancemethod at remote 0xb00016c>, seconds=<built-in function time>, args=(), canceller=<instancemethod at remote 0xad81e64>, delayed_time=0, kw={}, func=<LoopingCall(a=(...), interval=2, clock=<...>, _expectNextCallAt=<float at remote 0xb03ac1c>, f=<instancemethod at remote 0xa97234c>, deferred=<Deferred(_canceller=None, callbacks=[((<function at remote 0x9e59f44>, None, None), (<instancemethod at remote 0xa972374>, (...), {}))]) at remote 0xa9710cc>, running=True, kw={}, starttime=<float at remote 0x9ed5f3c>, call=<...>, _runAtStart=True) at remote 0xa96e76c>, time=<float at remote 0xac30db4>, cancelled=0, called=0) at remote 0xb03482c>, <DelayedCall(resetter=<instancem...(truncated), throwflag=0) at Python/ceval.c:2666

this is weird, but it seems like the type pointer is 0x0 (no type?):

(gdb) print {PyObject} ((PyObject *)(((PyGC_Head *)*gc)+1))
$1 = {ob_refcnt = 700, ob_type = 0x0}

gc gets stuck again in update_refs, and if you look at its members, gc.gc_next == gc.gc_prev == gc ....
(gdb) print {PyGC_Head} gc         
$3 = {gc = {gc_next = 0xb77a3300, gc_prev = 0xb77a3300, gc_refs = 700}, 
  dummy = 1.2675072995965765876244656259641832e-4721}

Two of the machines produced core files, first core:
(Incidentally, this machine, once reset was one of the ones that was counted in the previous list that locked up at update_refs)

Program terminated with signal 6, Aborted.
#0  0xb76fe424 in __kernel_vsyscall ()

(gdb) info thread
  Id   Target Id         Frame 
  12   Thread 0xb0afab70 (LWP 2752) 0xb76fe424 in __kernel_vsyscall ()
  11   Thread 0xb12fbb70 (LWP 2751) 0xb76fe424 in __kernel_vsyscall ()
  10   Thread 0xaf2f7b70 (LWP 2755) 0xb76fe424 in __kernel_vsyscall ()
  9    Thread 0xb22fdb70 (LWP 2749) 0xb76fe424 in __kernel_vsyscall ()
  8    Thread 0xb2afeb70 (LWP 2748) 0xb76fe424 in __kernel_vsyscall ()
  7    Thread 0xb1afcb70 (LWP 2750) 0xb76fe424 in __kernel_vsyscall ()
  6    Thread 0xb32ffb70 (LWP 2747) 0xb76fe424 in __kernel_vsyscall ()
  5    Thread 0xaeaeeb70 (LWP 2757) 0xb76fe424 in __kernel_vsyscall ()
  4    Thread 0xb02f9b70 (LWP 2753) 0xb76fe424 in __kernel_vsyscall ()
  3    Thread 0xb3ce6b70 (LWP 2740) 0xb76fe424 in __kernel_vsyscall ()
  2    Thread 0xafaf8b70 (LWP 2754) 0xb7039cda in __i686.get_pc_thunk.bx ()
   from /usr/lib/python2.7/lib-dynload/datetime.so
* 1    Thread 0xb73af6c0 (LWP 2597) 0xb76fe424 in __kernel_vsyscall ()

I'm not at all sure whats going on here... but the file for the service ends with this:
Fatal Python error: GC object already tracked

The other core file is different:

Program terminated with signal 11, Segmentation fault.
#0  0xb766f3ee in call_function (pp_stack=0xbfda38c0, oparg=0) at Python/ceval.c:4047
4047    Python/ceval.c: No such file or directory.
        in Python/ceval.c
#0  0xb766f3ee in call_function (pp_stack=0xbfda38c0, oparg=0) at Python/ceval.c:4047
#1  0xb766bdff in PyEval_EvalFrameEx (f=<unknown at remote 0xa0bf31c>, throwflag=0)
    at Python/ceval.c:2666
#2  0xb766f542 in fast_function (func=<function at remote 0x922733c>, pp_stack=0xbfda3ac0, 
    n=1, na=1, nk=0) at Python/ceval.c:4099
#3  0xb766f383 in call_function (pp_stack=0xbfda3ac0, oparg=0) at Python/ceval.c:4034
#4  0xb766bdff in PyEval_EvalFrameEx (f=<unknown at remote 0xa0a69ac>, throwflag=0)
    at Python/ceval.c:2666
#5  0xb766f542 in fast_function (func=<function at remote 0x92272cc>, pp_stack=0xbfda3cc0, 
    n=2, na=2, nk=0) at Python/ceval.c:4099
#6  0xb766f383 in call_function (pp_stack=0xbfda3cc0, oparg=1) at Python/ceval.c:4034
#7  0xb766bdff in PyEval_EvalFrameEx (f=<unknown at remote 0xa0c27a4>, throwflag=0)
    at Python/ceval.c:2666
#8  0xb766d7ad in PyEval_EvalCodeEx (co=0x9212cc8, globals=
    {'DeferredFilesystemLock': <type at remote 0x92691b4>, 'AlreadyCalledError': <type at remote 0x912420c>, 'returnValue': <function at remote 0x9227684>, '_deferGenerator': <function at remote 0x92275a4>, 'DebugInfo': <classobj at remote 0x922032c>, '_parseDListResult': <function at remote 0x922702c>, 'FirstError': <type at remote 0x91253a4>, 'deferredGenerator': <function at remote 0x922764c>, 'fail': <function at remote 0x9217e64>, 'waitForDeferred': <classobj at remote 0x922044c>, 'inlineCallbacks': <function at remote 0x922772c>, 'logError': <function at remote 0x9217ca4>, 'log': <module at remote 0xb6ff5a64>, '__all__': ['Deferred', 'DeferredList', 'succeed', 'fail', 'FAILURE', 'SUCCESS', 'AlreadyCalledError', 'TimeoutError', 'gatherResults', 'maybeDeferred', 'waitForDeferred', 'deferredGenerator', 'inlineCallbacks', 'returnValue', 'DeferredLock', 'DeferredSemaphore', 'DeferredQueue', 'DeferredFilesystemLock', 'AlreadyTryingToLockError'], 'CancelledError': <type at remote 0x91243e4>, '__package__': 'twiste...(truncated), locals=0x0, args=0xa2fd8d8, argcount=2, kws=0xb73a1038, kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:3253
(past this point in the backtrace, you get alot of python tracebacks ( something in the core file is messing with the python-gdb extension )

na = 0
nk = 0
n = 0
pfunc = 0xa0bf47c
func = <classobj at remote 0x931c9bc>
x = 
    <Failure(count=60, tb=None, value=exceptions.SystemError('Python/traceback.c:89: bad argument to internal function',), parents=['exceptions.SystemError', 'exceptions.StandardError', 'exceptions.Exception', 'exceptions.BaseException', '__builtin__.object', 'exceptions.SystemError'], frames=[], type=<type at remote 0xb76ee1e0>, stack=[]) at remote 0xa2fdb8c>
w = 0x0



I don't know if this will be helpful?
http://mail.python.org/pipermail/python-dev/2001-October/018002.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Tue Dec 20 23:37:38 2011
From: report at bugs.python.org (David Butler)
Date: Tue, 20 Dec 2011 22:37:38 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324420658.39.0.698314580897.issue13616@psf.upfronthosting.co.za>


David Butler <croepha at gmail.com> added the comment:

This also looks familiar:
http://bytes.com/topic/python/answers/36901-fatal-error-gc-object-already-tracked
"semi-randomly locks somewhere outside my C-code (after returning to
python), and semi-randomly issues a "Fatal error: GC object already
tracked... "
Someone replies with:
"... should be calling PyObject_GC_UnTrack before doing anything else..."

So, perhaps one of the extensions is not calling PyObject_GC_UnTrack? but I need to know which one to go further...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Tue Dec 20 23:50:03 2011
From: report at bugs.python.org (David Butler)
Date: Tue, 20 Dec 2011 22:50:03 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324421403.64.0.318673715382.issue13616@psf.upfronthosting.co.za>


David Butler <croepha at gmail.com> added the comment:

I think I have found the problem! I took a closer look at the Fatal error core:

#0  0xb76fe424 in __kernel_vsyscall ()
#1  0xb740ccb1 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb740e3f2 in *__GI_abort () at abort.c:92
#3  0xb766193f in Py_FatalError (msg=0xb76949de "GC object already tracked")
    at Python/pythonrun.c:1670
#4  0xb7595a3a in PyMethod_New (func=<function at remote 0x8d649cc>, self=
    <QtReactor(waker=<_UnixWaker(i=13, fileno=<function at remote 0x93f6994>, reactor=<...>, o=14) at remote 0x93f3dac>, threadCallQueue=[(<instancemethod at remote 0x9b5639c>, (0,), {})], _cancellations=0, _justStopped=False, _newTimedCalls=[], _pendingTimedCalls=[<DelayedCall(resetter=<instancemethod at remote 0x9b5d504>, seconds=<built-in function time>, args=(), canceller=<instancemethod at remote 0x9cb48ec>, delayed_time=0, kw={}, func=<LoopingCall(a=(...), interval=2, clock=<...>, _expectNextCallAt=<float at remote 0x9ab7b44>, f=<instancemethod at remote 0x96db34c>, deferred=<Deferred(_canceller=None, callbacks=[((<function at remote 0x8bc6f44>, None, None), (<instancemethod at remote 0x96db374>, (...), {}))]) at remote 0x96da0cc>, running=True, kw={}, starttime=<float at remote 0x8c3f0f4>, call=<...>, _runAtStart=True) at remote 0x96d776c>, time=<float at remote 0x9d4cb74>, cancelled=0, called=0) at remote 0x9d1184c>, <DelayedCall(resetter=<instancemethod at remote 0xa2c4edc>, seconds=<built-in function ti...(truncated), klass=<type at remote 0x8e5a3dc>) at Objects/classobject.c:2250
#5  0xb6c71225 in PySide::DynamicSlotDataV2::callback (this=0x96b6440)
    at /var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-qt4.7+1.0.9/libpyside/globalreceiverv2.cpp:129
#6  0xb6c718fc in PySide::GlobalReceiverV2::qt_metacall (this=0x9519b88, 
    call=QMetaObject::InvokeMetaMethod, id=5, args=0xbffbeef4)
    at /var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-qt4.7+1.0.9/libpyside/globalreceiverv2.cpp:289
#7  0xb6ab76a7 in QMetaObject::metacall (object=0x9519b88, cl=QMetaObject::InvokeMetaMethod, 
    idx=5, argv=0xbffbeef4) at kernel/qmetaobject.cpp:237
#8  0xb6ac9b8c in QMetaObject::activate (sender=0x9760e40, m=0xb6c5d644, 
    local_signal_index=<optimized out>, argv=<optimized out>) at kernel/qobject.cpp:3278
#9  0xb6b21b27 in QTimer::timeout (this=0x9760e40) at .moc/debug-shared/moc_qtimer.cpp:128
#10 0xb6acfb01 in QTimer::timerEvent (this=0x9760e40, e=0xbffbf41c) at kernel/qtimer.cpp:271
#11 0xb6e35efb in QTimerWrapper::timerEvent (this=0x9760e40, arg__1=0xbffbf41c)
    at /var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-1.0.9_build/PySide/QtCore/PySide/QtCore/qtimer_wrapper.cpp:233
#12 0xb6ac2e67 in QObject::event (this=0x9760e40, e=0x6) at kernel/qobject.cpp:1181
#13 0xb6e37717 in QTimerWrapper::event (this=0x9760e40, arg__1=0xbffbf41c)
    at /var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-1.0.9_build/PySide/QtCore/PySide/QtCore/qtimer_wrapper.cpp:164


If this would explain the update_refs lock up then I will close this bug... (i also opening on on pyside)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Wed Dec 21 00:13:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 20 Dec 2011 23:13:21 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324422801.12.0.448919265315.issue13616@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Hey, you found it!
PySide::DynamicSlotDataV2::callback() calls PyMethod_New() without getting the GIL.  The Python allocator is not thread-safe, operations are supposed to be serialized by this Global Interpreter Lock.

I suggest to modify this DynamicSlotDataV2::callback() and add the line "Shiboken::GilState gil;" at the beginning of the function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Wed Dec 21 00:18:44 2011
From: report at bugs.python.org (David Butler)
Date: Tue, 20 Dec 2011 23:18:44 +0000
Subject: [issue13616] Never ending loop in in update_refs Modules/gcmodule.c
In-Reply-To: <1324078033.17.0.823551238178.issue13616@psf.upfronthosting.co.za>
Message-ID: <1324423124.05.0.325204576812.issue13616@psf.upfronthosting.co.za>


David Butler <croepha at gmail.com> added the comment:

resolved as wont fix, because its not python's fault :)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13616>
_______________________________________

From report at bugs.python.org  Wed Dec 21 00:53:29 2011
From: report at bugs.python.org (Martin Pool)
Date: Tue, 20 Dec 2011 23:53:29 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324425209.38.0.934256426551.issue13643@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

> I'm not sure why having a locale set to C or something invalid should be considered a Python bug. 

Programs like bzr that hit these problems can tell their users, either in the docs or an error message, "change your locale to a UTF-8 one".

There are two problems with this: one is just the practical one that it scales poorly to have to tell every user to do this and to take them through working out how to set this in a way that covers cron jobs, daemons, things run over ssh, etc.

The other problem is that the locale variables primarily describe the locale for input/output, and that can very reasonably be different from the filesystem encoding.  As a specific common example people may have UTF-8 filenames but want a C locale terminal.  If there was a separate LC_FILENAMES then Python could respect that and insist people set it, but there isn't.

----------
nosy: +poolie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:01:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 00:01:55 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324425715.22.0.786157593245.issue13643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If there was a separate LC_FILENAMES then Python could respect
> that and insist people set it, but there isn't.

During 1 month, we had PYTHONFSENCODING environment variable. It was not a good idea. Again: please read the discussion (in closed issues) explaing why we removed it (and which problems it introduced).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:24:22 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Wed, 21 Dec 2011 00:24:22 +0000
Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box
	is open
In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za>
Message-ID: <1324427062.33.0.303236160107.issue13630@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

Well I checked 'SearchBar' IDLE extension and is not bad... has some minor bugs, nothing major just very very minor quirky behavior, but nothing that seems to impair functionality AFAIK.
It should be cleaned up and added to release in place of the existing non-functional one.
Just my 2c, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13630>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:26:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 00:26:03 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324427163.71.0.811977840615.issue13643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> There are two problems with this: one is just the practical
> one that it scales poorly to have to tell every user to do this
> and to take them through working out how to set this in a way
> that covers cron jobs, daemons, things run over ssh, etc.

I never checked which locale is used by default for programs called by cron. So I checked: on Fedora 16, programs start with a very few environment variables, and LANG and LC_ALL are not set. You can add "LANG=fr_FR.UTF-8" (for example) to /etc/environment to set the default language for the whole system (for all programs). I checked, it works with cron. Or if you don't want to affect all programs, it is maybe safer to only set the locale for one specific program in your crontab by adding "LANG=fr_FR.UTF-8 " before you command. Example:

* *  *  *  * LANG=fr_FR.UTF-8 /home/haypo/test.sh

--


If you want to handle any filename without having to care of the locale, the simplest solution is to use the bytes type to store filenames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:28:57 2011
From: report at bugs.python.org (Martin Pool)
Date: Wed, 21 Dec 2011 00:28:57 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324425715.22.0.786157593245.issue13643@psf.upfronthosting.co.za>
Message-ID: <CAA9uavCz=LBZW246qej026wcin2uJSpVvyj6ScH6HmwMQDtfgw@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 21 December 2011 11:01, STINNER Victor <report at bugs.python.org> wrote:
>
> Again: please read the discussion (in closed issues) explaing why we removed it (and which problems it introduced).

There's a lot of history, so I'm not sure exactly which problems
you're referring to.  The main problem I see being discussed is that
changing the encoding after Python starts would be dangerous, which I
agree with, but we're not proposing to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:38:19 2011
From: report at bugs.python.org (Martin Pool)
Date: Wed, 21 Dec 2011 00:38:19 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324427163.71.0.811977840615.issue13643@psf.upfronthosting.co.za>
Message-ID: <CAA9uavDjrpMuMJ77fEwHKiVxKZgKZiOozg1zM6YZ-SQ4AAawoA@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 21 December 2011 11:26, STINNER Victor <report at bugs.python.org> wrote:
> I never checked which locale is used by default for programs called by cron. So I checked: on Fedora 16, programs start with a very few environment variables, and LANG and LC_ALL are not set. You can add "LANG=fr_FR.UTF-8" (for example) to /etc/environment to set the default language for the whole system (for all programs). I checked, it works with cron. Or if you don't want to affect all programs, it is maybe safer to only set the locale for one specific program in your crontab by adding "LANG=fr_FR.UTF-8 " before you command. Example:
>
> * * ?* ?* ?* LANG=fr_FR.UTF-8 /home/haypo/test.sh

That is the correct kind of configuration.  When I say it scales
poorly I mean that every user running a Python program on a unicode
system needs to insert this configuration in every relevant place, and
they need to work this out from what is typically a fairly cryptic
message.  (bzr just added a workaround for this, but for other
programs it still exists.)

Also, my other point, is that people may very well want their cron
scripts to send ascii output but cope with unicode filenames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:42:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 00:42:28 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324428148.62.0.365731349442.issue13643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The main problem I see being discussed is that
> changing the encoding after Python starts would
> be dangerous, which I agree with, but we're not
> proposing to do that.

Not after Python start. Using two encodings at the same would just adds new problems. On UNIX (at least on Linux?), it is mandatory to use the same encoding for:

 - command line arguments
 - environment variables
 - filenames
 - and more generally, all data exchanged with the system and other programs

Let's take an example: you use UTF-8 for filenames and ISO-8859-1 for all other data. You want to check if a specific filename is present in your home directory: encode the filename to UTF-8 and read the home directory from the HOME environment variable. But environment variables are decoded from ISO-8859-1, so you have to encode them back to ISO-8859-1 to avoid mojibake (and real bugs, like file not found).

Ok, let say that filenames and environment variables are UTF-8 and that other data are ISO-8859-1. You would like to play a MP3 using mplayer: you pass the filename encoded to UTF-8 as an argument of mplayer command line. But mplayer uses ISO-8859-1 to decode its command line (it's not exactly like that, but image that it's the case): mplayer will be unable to find your MP3.

etc.

That's why on UNIX there is one unique encoding, the locale encoding, and that Python uses the same encoding (called "the filesystem encoding", I don't like this name, sys.getfilesystemencoding()).

--

It is no more possible to change the Python filesystem encoding at runtime (I remove sys.setfilesystemencoding()) because I would like to inconsistency. If you decoded a filename before changing the encoding, and then you decode the same filename after changing the encoding: you will get two different names and encode the filenames back will give you two different byte sequences (and more likely, a Unicode encode error).

It was possible to override the filesystem encoding using a PYTHONFSENCODING environment variable, but it introduced all the inconsistencies listed before (especially with external programs).

Now the only right way to change the Python (filesystem) encoding is the UNIX way of doing that: set LC_ALL, LC_CTYPE or LANG environment variable (configure your locale).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:47:53 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 00:47:53 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1324428473.51.0.306854526779.issue10079@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I checked the submitted patches from the issues against the large patch by eye. Guilherme's patches in these separate issues have the same contents: issue1207589, issue1612262, issue1721083, issue6699, issue3359.

The large patch updates issue964437, but the "view_file" change is outdated. 

I wrote more recent patches for issue4832 and issue6698.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:48:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 00:48:51 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324428531.86.0.929600974446.issue13619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I would be possible to implement incremental decoder with mbsrtowcs() and incremental encoder with wcsrtombs(), by serializing mbstate_t to a long integer (TextIOWrapper.tell() does something like that). The problem is that mbsrtowcs() and wcsrtombs() are "recent" (not always available). It may also be dangerous to allow the user to pass an arbitrary mbstate_t (using .setstate()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:55:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 00:55:17 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324428148.62.0.365731349442.issue13643@psf.upfronthosting.co.za>
Message-ID: <4EF12EBF.7020809@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I should not write comments so late :-p

> Not after Python start. Using two encodings at the same would just ...

at the same time

 > ... because I would like to inconsistency.

because it would lead to inconsistencies

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 02:12:30 2011
From: report at bugs.python.org (Martin)
Date: Wed, 21 Dec 2011 01:12:30 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324429950.17.0.0585650740961.issue13643@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

> During 1 month, we had PYTHONFSENCODING environment variable. It was not a
> good idea.

I strongly agree. There is no sense in having a separate configurable value, anyone who would think about using a PYTHONFSENCODING should just change their locale instead. However, avoiding the need for manual intervention completely in a relatively narrow set of cases is still useful.

> Not after Python start. Using two encodings at the same would just adds new
> problems. On UNIX (at least on Linux?), it is mandatory to use the same
> encoding for:
>
>  - command line arguments
>  - environment variables
>  - filenames
>  - and more generally, all data exchanged with the system and other programs

Having more than one encoding on unix is already a reality, there's nothing to stop someone setting LANG=de_DE.UTF-8 and LC_MESSAGES=C say.

The real lesson is not that having more than one encoding is dangerous, but that having incompatible encodings is dangerous. As 'ascii' is a strict subset of 'utf-8' the cross process communication issues are greatly lessened, at worst stuff just breaks still.

Expanding the filesystem default encoding to utf-8 should be a very narrow change, mostly just affecting io and os operations. Other actions involving paths will still break if a non-ascii string is used, but without the possibility of mangling data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 02:16:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 01:16:21 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324430181.75.0.96576790642.issue13643@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, you're complaining about something which works, kind of:

$ touch h?h?
$ LANG=C python3 -c "import os; print(os.listdir())"
['h\udcc3\udca9h\udcc3\udca9']

> This makes robustly working with non-ascii filenames on different
> platforms needlessly annoying, given no modern nix should have problems
> just using UTF-8 in these cases.

So why don't these supposedly "modern" systems at least set the appropriate environment variables for Python to infer the proper character encoding?
(since these "modern" systems don't have a well-defined encoding...)

Answer: because they are not modern at all, they are antiquated, inadapted and obsolete pieces of software designed and written by clueless Anglo-American people. Please report bugs against these systems. The culprit is not Python, it's the Unix crap and the utterly clueless attitude of its maintainers ("filesystems are just bytes", yeah, whatever...).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 02:18:09 2011
From: report at bugs.python.org (Martin Pool)
Date: Wed, 21 Dec 2011 01:18:09 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <4EF12EBF.7020809@haypocalc.com>
Message-ID: <CAA9uavBkvO46_pPpKfgRpXO_J4buo_odd0K=OL3TOM69QHvuhw@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

Thanks for the example.

Like you say, realistically, all data exchanged with other programs
and with the system needs to be in the same encoding.  (User document
content may be in something else.)

On modern systems, this problem is solved by making the standard
encoding UTF-8.  So it is unfortunate that, when no locale is set,
Python3 defaults to ascii for the filesystem.

With no locale set, python3 makes getdefaultencoding() utf-8, so it
seems oddly pessimistic to make the fsencoding only ascii.

If someone really wants to run everything in iso-8859-1 this patch
would not stop them doing so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 02:36:02 2011
From: report at bugs.python.org (Martin Pool)
Date: Wed, 21 Dec 2011 01:36:02 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324430181.75.0.96576790642.issue13643@psf.upfronthosting.co.za>
Message-ID: <CAA9uavCDbswD4Zbn-HeaBGvuj4GnH5Z32dBqsL5MJP8Yyhc0kw@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 21 December 2011 12:16, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> So, you're complaining about something which works, kind of:
>
> $ touch h?h?
> $ LANG=C python3 -c "import os; print(os.listdir())"
> ['h\udcc3\udca9h\udcc3\udca9']

It's possible to work around this in some cases, such as listdir, by
coping with the result including some byte strings, and then manually
decoding them.  But there are, iirc, other cases where the call just
fails and there is no easy workaround.

It wasn't impossible to get unicode right in python2, but python3
still thinks it's worth changing things to make it work better.

>> This makes robustly working with non-ascii filenames on different
>> platforms needlessly annoying, given no modern nix should have problems
>> just using UTF-8 in these cases.
>
> So why don't these supposedly "modern" systems at least set the appropriate environment variables for Python to infer the proper character encoding?
> (since these "modern" systems don't have a well-defined encoding...)

The standard encoding is UTF-8.  Python shouldn't need to have a
variable set to tell it this.  Python is making an assumption about
the default but it is a bad assumption.

> The culprit is not Python, it's the Unix crap....

Programs need to work with the environments that are available to
them, even though those environments often have flaws.  Windows and
Mac have annoying bugs too, even bugs specifically about Unicode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 02:41:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 01:41:26 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <CAA9uavCDbswD4Zbn-HeaBGvuj4GnH5Z32dBqsL5MJP8Yyhc0kw@mail.gmail.com>
Message-ID: <1324431645.611.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The standard encoding is UTF-8.

How so? I don't know of any Linux or Unix spec which says so. If you get
the Linux heads to standardize this then I'll certainly be very happy
(and countless others will, too). But AFAIK this it not the case and I
don't see why you are asking Python to make a choice that OS vendors
refuse to make. You are certainly asking the wrong project to solve this
problem. So I'd rather not solve your problem at the Python level so
that you instead try to get it solved at the right (OS) level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 03:03:32 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Dec 2011 02:03:32 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324433012.57.0.911913682663.issue13607@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Wed Dec 21 03:10:37 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Dec 2011 02:10:37 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324433437.77.0.774028121466.issue13607@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

With the new patch I see no benefits on the same micro-benchmarks you posted (it is even slower for the smaller case) on a quad-core 64-bit F15 box:

BEFORE:

$ ./python -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(10))"
1000000 loops, best of 3: 1.33 usec per loop
$ ./python -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(1000000))"
10 loops, best of 3: 66 msec per loop

AFTER:

$ ./python -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(10))"
1000000 loops, best of 3: 1.45 usec per loop
$ ./python -mtimeit "def y(n):" "  for x in range(n):" "    yield  x" "sum(y(1000000))"
10 loops, best of 3: 65.8 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:10:59 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Dec 2011 03:10:59 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324437059.67.0.996822497548.issue13607@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The thing that most appeals to me with this concept is moving closer to making it possible to experiment with generator-style functionality in *extension* modules (albeit extension modules that are coupled to private CPython APIs). So, for me, "not worse than the status quo" would be the main thing I'd be looking for out of any micro-benchmarks.

However, that also makes me question the movement of the "why_exit" from the frame to the tstate - having it on the thread state is significantly less flexible when it comes to experimenting with execution models.

The move from orthogonal bit flags in a dedicated enum to int fields and macro definitions also seems like a completely unnecessary pessimisation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:17:32 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 21 Dec 2011 03:17:32 +0000
Subject: [issue8098] PyImport_ImportModuleNoBlock() may solve problems but
	causes others.
In-Reply-To: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>
Message-ID: <1324437452.06.0.139614603368.issue8098@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/issue8098>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:39:10 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Dec 2011 03:39:10 +0000
Subject: [issue8098] PyImport_ImportModuleNoBlock() may solve problems but
	causes others.
In-Reply-To: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>
Message-ID: <1324438750.18.0.631752353983.issue8098@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8098>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:18:26 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Dec 2011 05:18:26 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324444706.49.0.536796349625.issue13627@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

ECC is *not* available in the OpenSSL package provided on RedHat systems.  RedHat intentionally strips it due to patent concerns (http://en.wikipedia.org/wiki/ECC_patents).  Therefore committing this work made it much more difficult to build the ssl module on RedHat systems.

I couldn't find a clear statement of this in any RedHat documentation, but I did find a few references to the stripping in these places:

   * https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=623483
   * https://www.martineve.com/2011/07/22/using-elliptical-curve-cryptography-in-openssh/
   * https://bugzilla.redhat.com/show_bug.cgi?id=615372

Perhaps we should make these algorithms build conditional?  Are these patent issues of concern to us?

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:54:52 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 21 Dec 2011 05:54:52 +0000
Subject: [issue13644] Python crashes with this code.
Message-ID: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

When you run the following code, Python 3 (not Python 2) crashes.
Interestingly, Python 2.7 doesn't seem to be affected and correctly raises an error about recursion ( so this must be a regression ).
The code's recursion should be detected and Python should raise a RuntimeError about recursion.

def recurse():
    try:raise Exception #An arbitary exception
    except Exception:recurse()

After running this code Python 3 says "Fatal Python error: Cannot recover from stack overflow." and then Python aborts .
In Jython, this code doesn't crash it.

----------
components: Interpreter Core
messages: 149956
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: Python crashes with this code.
type: crash
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:55:20 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 21 Dec 2011 05:55:20 +0000
Subject: [issue13644] Python 3 crashes with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324446920.29.0.156378663025.issue13644@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
title: Python crashes with this code. -> Python 3 crashes with this code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:11:21 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 21 Dec 2011 06:11:21 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324447881.74.0.710590689787.issue13644@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
title: Python 3 crashes with this code. -> Python 3 crashes (segfaults) with this code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:15:41 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 21 Dec 2011 06:15:41 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324448141.37.0.930283832117.issue13644@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Python isn't crashing; it's bailing out of an impossible situation. It's not clear what the correct behavior is, since you're basically preventing Python from aborting the recursive behavior.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:24:43 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 21 Dec 2011 06:24:43 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324448683.34.0.958856491752.issue13644@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

But Python 2 doesn't crash after running the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:26:16 2011
From: report at bugs.python.org (maniram maniram)
Date: Wed, 21 Dec 2011 06:26:16 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324448776.14.0.53835679895.issue13644@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Oops, to reproduce this bug after running the code run "recurse()".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:57:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 21 Dec 2011 06:57:35 +0000
Subject: [issue4691] IDLE Code Caching Windows
In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za>
Message-ID: <1324450655.73.0.702958150804.issue4691@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> IDLE/Win Installer: drop -n switch for 2.7/3.1; install 3.1 as idle3
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4691>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:58:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 21 Dec 2011 06:58:21 +0000
Subject: [issue6321] Reload Python modules when running programs
In-Reply-To: <1245648620.51.0.901061764952.issue6321@psf.upfronthosting.co.za>
Message-ID: <1324450701.4.0.975738343735.issue6321@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution: out of date -> duplicate
stage:  -> committed/rejected
superseder:  -> IDLE/Win Installer: drop -n switch for 2.7/3.1; install 3.1 as idle3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6321>
_______________________________________

From report at bugs.python.org  Wed Dec 21 08:04:46 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 21 Dec 2011 07:04:46 +0000
Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character
	is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1324451086.0.0.220592314302.issue2382@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

What's the status of this issue?

FWIW, this is not only a problem with east asian characters:

>>> ? ???
  File "<stdin>", line 1
    ? ???
            ^
SyntaxError: invalid syntax

----------
nosy: +petri.lehtinen
versions: +Python 3.2, Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2382>
_______________________________________

From report at bugs.python.org  Wed Dec 21 08:22:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 07:22:56 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324444706.49.0.536796349625.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324452135.3385.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Perhaps we should make these algorithms build conditional?  Are these
> patent issues of concern to us?

Well, if RedHat used the "standard" OPENSSL_NO_ECDH flag, it's easy
enough to fix compilation of the ssl module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 08:27:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 07:27:53 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324452473.68.0.525289876615.issue13627@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:17:00 2011
From: report at bugs.python.org (vila)
Date: Wed, 21 Dec 2011 08:17:00 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324455420.24.0.459593718308.issue13643@psf.upfronthosting.co.za>


Changes by vila <v.ladeuil+bugs-python at free.fr>:


----------
nosy: +vila

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:18:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 08:18:59 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324455539.79.0.755651395766.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you post the exact compiler errors you encountered?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:19:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 08:19:43 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324455583.49.0.669595417761.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nevermind, I've found them on the Fedora buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:28:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 08:28:25 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <E1RdHXE-0003oL-36@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ec44f2e82707 by Antoine Pitrou in branch 'default':
Fix ssl module compilation if ECDH support was disabled in the OpenSSL build.
http://hg.python.org/cpython/rev/ec44f2e82707

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:33:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 08:33:38 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324456418.29.0.458352758787.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Since we're at it, do you know if Redhat also disables regular Diffie-Hellman? See issue13626.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:34:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 08:34:53 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324456493.44.0.192116836672.issue13627@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:01:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 09:01:10 +0000
Subject: [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <E1RdI2v-0006PF-1W@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 902f694a7b0e by Antoine Pitrou in branch '3.2':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/902f694a7b0e

New changeset b08bf8df8eec by Antoine Pitrou in branch 'default':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/b08bf8df8eec

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13581>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:01:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 09:01:10 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <E1RdI2v-0006PF-1f@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 902f694a7b0e by Antoine Pitrou in branch '3.2':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/902f694a7b0e

New changeset b08bf8df8eec by Antoine Pitrou in branch 'default':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/b08bf8df8eec

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:15:06 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 21 Dec 2011 09:15:06 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324458906.66.0.610980266249.issue11638@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Is there a good reason why the tarfile mode that is used is "w|gz"? It seems to me that this is not necessary, "w:gz" should be enough. "w|gz" is for special operations only (see the tarfile docs).

----------
nosy: +lars.gustaebel
Added file: http://bugs.python.org/file24065/distutils_tarfile_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:18:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 09:18:06 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <E1RdIJJ-0008JG-2m@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 13f56cd8dec1 by Antoine Pitrou in branch '2.7':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/13f56cd8dec1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:18:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 09:18:06 +0000
Subject: [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <E1RdIJJ-0008JG-2E@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 13f56cd8dec1 by Antoine Pitrou in branch '2.7':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/13f56cd8dec1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13581>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:18:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 09:18:55 +0000
Subject: [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <1324459135.37.0.0869753387592.issue13581@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now fixed in all 3 branches.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> "inspect" gets broken by some descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13581>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:19:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 09:19:08 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1324459148.27.0.72941138682.issue1785@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now fixed in all 3 branches.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:42:42 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 21 Dec 2011 09:42:42 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324460562.8.0.816275552529.issue13639@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

tarfile under Python 2.x is not particularly designed to support unicode filenames (the gzip module does not support them either), but that should not be too hard to fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file24066/tarfile-stream-gzip-unicode-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:04:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 10:04:31 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <E1RdJ2D-0003dY-Fm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b07b1e58582d by Antoine Pitrou in branch 'default':
Issue #12708: Add starmap() and starmap_async() methods (similar to itertools.starmap()) to multiprocessing.Pool.
http://hg.python.org/cpython/rev/b07b1e58582d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:05:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 10:05:03 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1324461903.23.0.773134940187.issue12708@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed. Thanks for your contribution!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12708>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:13:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 10:13:50 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324462430.11.0.0192357411555.issue13636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think we should relax the constraints a bit (RC4 seems ok for TLS/SSL use (*)) and therefore suggest we settle on "DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2".

(OpenSSL's default is "DEFAULT:!aNULL:!eNULL", so we're really disabling weak ciphers)

(*) Wikipedia even notes: ?RC4, being a stream cipher, is the only common cipher which is immune[7] to the 2011 BEAST attack on TLS 1.0, which exploits a known weakness in the way cipher block chaining mode is used with all of the other ciphers supported by TLS 1.0, which are all block ciphers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:25:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 10:25:31 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <E1RdJMY-0005JC-6j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 19df72a77b39 by Antoine Pitrou in branch '3.2':
Issue #13597: Fix the documentation of the "-u" command-line option, and wording of "What's new in Python 3.0" about standard streams.
http://hg.python.org/cpython/rev/19df72a77b39

New changeset 1ab124a6f171 by Antoine Pitrou in branch 'default':
Issue #13597: Fix the documentation of the "-u" command-line option, and wording of "What's new in Python 3.0" about standard streams.
http://hg.python.org/cpython/rev/1ab124a6f171

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:26:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 10:26:00 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1324463160.21.0.185292120054.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I also suggested changes to the documentation of the "-u" flag, and to 
> "What's New in Python 3.0", can someone look at that also?

Sorry for having overlooked that. This should now be fixed as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:26:41 2011
From: report at bugs.python.org (th9)
Date: Wed, 21 Dec 2011 10:26:41 +0000
Subject: [issue13553] Tkinter doesn't set proper application name
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1324463201.22.0.717106245657.issue13553@psf.upfronthosting.co.za>


th9 <rei4dan at gmail.com> added the comment:

Yes, I'm aware of the 'iconname' docs. In this case 'iconname' probably is not the right property to set, but I don't know which one should be.

For GTK+ applications there is a special function for setting application name which should be shown to user and apparently Gnome 3 is using that. 

http://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-set-application-name

I don't know how to achieve the same for Tkinter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13553>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:35:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 10:35:17 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1324463717.89.0.103358976757.issue13577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. Since you modified PyCFunction_GET_SELF to return NULL for static methods, why not simply use it instead of manually looking up the flags in several places?

I'm talking about the following changes:

-    PyObject *self = PyCFunction_GET_SELF(func);
+    int flags = PyCFunction_GET_FLAGS(func);
+    PyObject *self = flags & METH_STATIC ? NULL :
+        _PyCFunction_GET_RAW_SELF(func);

[...]

     self = m->m_self;
-    if (self == NULL)
+    if (self == NULL || PyCFunction_GET_FLAGS(m) & METH_STATIC)
         self = Py_None;

[...]

-            PyObject *self = PyCFunction_GET_SELF(func);
+            PyObject *self = flags & METH_STATIC ? NULL :
+                _PyCFunction_GET_RAW_SELF(func);


Unless you demonstrate there's a significant performance improvement in this style, we should really favour the simpler style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Wed Dec 21 13:24:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 12:24:51 +0000
Subject: [issue12453] test_import.test_failing_import_sticks() sporadic
	failures
In-Reply-To: <1309446981.3.0.601023155331.issue12453@psf.upfronthosting.co.za>
Message-ID: <1324470291.22.0.147411768144.issue12453@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12453>
_______________________________________

From report at bugs.python.org  Wed Dec 21 13:32:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 12:32:18 +0000
Subject: [issue13645] test_import fails after test_coding
Message-ID: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_import fails when run directly after test_coding:

$ ./python -m test test_coding test_import
[1/2] test_coding
[2/2] test_import
test test_import failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_import.py", line 115, in test_creation_mode
    self.assertEqual(stat.S_IMODE(s.st_mode), 0o666 & ~mask)
AssertionError: 436 != 420


384 is 0o600 while 420 is 0o644.

(seen sporadically on some buildbots, e.g.
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/1462/steps/test/logs/stdio
)


The same thing happens in 3.2, although the failing test is a different one:

$ ./python -m test test_coding test_import
[1/2] test_coding
[2/2] test_import
test test_import failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/32/Lib/test/test_import.py", line 117, in test_execute_bit_not_copied
    stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH)
AssertionError: 436 != 292

----------
components: Interpreter Core, Tests
messages: 149982
nosy: brett.cannon, ncoghlan, neologix, pitrou
priority: normal
severity: normal
status: open
title: test_import fails after test_coding
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 13:41:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 12:41:18 +0000
Subject: [issue13645] test_import fails after test_coding
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1324471278.91.0.028900462423.issue13645@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The cause is that the import machinery checks the timestamp stored in the pyc file to decide whether it must be refreshed. Depending on the system's timestamp granularity, there can be false negatives: the py file was modified twice with the same timestamp, but the pyc file isn't regenerated for the second version of the py file. Adding a time.sleep(1) call to the failing test case makes it pass.

Correct fix for 3.2's tests is the following. I don't know if the import machinery can be improved not to exhibit any false negatives:

diff --git a/Lib/test/test_import.py b/Lib/test/test_import.py
--- a/Lib/test/test_import.py
+++ b/Lib/test/test_import.py
@@ -107,8 +107,9 @@ class ImportTests(unittest.TestCase):
                 open(fname, 'w').close()
                 os.chmod(fname, (stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH |
                                  stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH))
+                fn = imp.cache_from_source(fname)
+                unlink(fn)
                 __import__(TESTFN)
-                fn = imp.cache_from_source(fname)
                 if not os.path.exists(fn):
                     self.fail("__import__ did not result in creation of "
                               "either a .pyc or .pyo file")

----------
nosy: +barry
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 13:54:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 12:54:12 +0000
Subject: [issue13645] test_import fails after test_coding
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1324472052.82.0.52069101893.issue13645@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The pyc format currently stores the modification time cast to a 32-bit int. A 3.3 iteration of the pyc format could instead store two 32-bit ints, one for the integral part and one for the fractional part (e.g. in nanoseconds). When HAVE_STAT_TV_NSEC is defined, struct stat has a "st_mtim" member which is a struct timespec providing theoretical nanosecond precision.

Whether this would be useful remains to be decided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:31:50 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 21 Dec 2011 13:31:50 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1324474310.57.0.0725904230888.issue12715@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24067/c92c4d936255.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:33:50 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 21 Dec 2011 13:33:50 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324474430.9.0.997264528391.issue13639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

That looks like a good patch to me. Do you want to commit it, or would you rather I do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:36:08 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 21 Dec 2011 13:36:08 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1324474568.44.0.338525267159.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I have updated the patch to latest default/tip and would appreciate a review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:45:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 13:45:31 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1324475131.26.0.199889370012.issue12715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've done a review at http://bugs.python.org/review/12715

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:59:07 2011
From: report at bugs.python.org (Stefano Rivera)
Date: Wed, 21 Dec 2011 13:59:07 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1324475947.33.0.0361983601187.issue3990@psf.upfronthosting.co.za>


Changes by Stefano Rivera <python at rivera.za.net>:


----------
nosy: +stefanor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3990>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:16:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Dec 2011 14:16:03 +0000
Subject: [issue13646] Document poor interaction between multiprocessing and -m
	on Windows
Message-ID: <1324476963.91.0.938014809315.issue13646@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The http://docs.python.org/library/multiprocessing#windows section of the docs should document the limitations that multiprocessing on Windows places on __main__ module invocation.

- no execution of modules inside packages with -m
- no execution of packages (since their __main__ is inside the package)

----------
messages: 149988
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Document poor interaction between multiprocessing and -m on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13646>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:22:48 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Dec 2011 14:22:48 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1324477368.81.0.879485113043.issue10128@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The fix from #10845 should be backported to Python 2.7 (bypassing the assertion isn't enough - you want to skip re-executing __main__ entirely)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:32:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 14:32:04 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <E1RdNCz-0001Ki-BY@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7faa90a6324c by Senthil Kumaran in branch 'default':
Issue 13620 - Support chrome browser in webbrowser.py module.
http://hg.python.org/cpython/rev/7faa90a6324c

New changeset bd3631f9aa5c by Senthil Kumaran in branch 'default':
Docs and News update for Issue13620. Chrome support in webbrowser.py
http://hg.python.org/cpython/rev/bd3631f9aa5c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:32:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Dec 2011 14:32:55 +0000
Subject: [issue13646] Document poor interaction between multiprocessing and -m
	on Windows
In-Reply-To: <1324476963.91.0.938014809315.issue13646@psf.upfronthosting.co.za>
Message-ID: <1324477975.07.0.967718473118.issue13646@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Actually the latter isn't true - the __main__ bypass handles that case. Since none of the code gets executed in the child process, it doesn't generally matter that __package__ isn't set properly)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13646>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:33:43 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 21 Dec 2011 14:33:43 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324478023.58.0.652372222529.issue13620@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is in 3.3. Thanks for the patches.

----------
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:40:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 14:40:36 +0000
Subject: [issue13620] Support Chrome in webbrowser.py
In-Reply-To: <1324120952.27.0.935913311476.issue13620@psf.upfronthosting.co.za>
Message-ID: <1324478436.59.0.0196021274672.issue13620@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13620>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:43:22 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 21 Dec 2011 14:43:22 +0000
Subject: [issue11012] Add log1p(), exp1m(), gamma(), and lgamma() to cmath
In-Reply-To: <1295997901.71.0.113497713942.issue11012@psf.upfronthosting.co.za>
Message-ID: <1324478602.42.0.571265960266.issue11012@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11012>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:48:41 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Dec 2011 14:48:41 +0000
Subject: [issue13645] test_import fails after test_coding
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1324478921.76.0.234823529498.issue13645@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> a struct timespec providing theoretical nanosecond precision.

Indeed. EXT3's timestamps have a 1s granularity, for example.
Another possibility would be to store both mtime and st_size (it's the default heuristic used by rsync does to decide whether to skip a file).

> Whether this would be useful remains to be decided.

Dunno.
On the one hand, it's frustrating to think that you can end up with a stale bytecode file forever (I've had more or less the same problem because of NFS mounts, and it can be quite puzzling when the last modification you made to the source file is not taken into account).
OTOH, nobody has ever complained about this...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:54:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 14:54:01 +0000
Subject: [issue13645] test_import fails after test_coding
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <E1RdNYO-0003bZ-76@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f4afc6858ed2 by Antoine Pitrou in branch '3.2':
Issue #13645: fix test_import failure when run immediately after test_coding.
http://hg.python.org/cpython/rev/f4afc6858ed2

New changeset a6bd166abde5 by Antoine Pitrou in branch 'default':
Issue #13645: fix test_import failure when run immediately after test_coding.
http://hg.python.org/cpython/rev/a6bd166abde5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:56:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 14:56:54 +0000
Subject: [issue13645] test_import fails after test_coding
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1324479414.76.0.070931332564.issue13645@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In the meantime, I've committed the test patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:04:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Dec 2011 15:04:28 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1324479868.79.0.609367570922.issue8713@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks for the patch sbt.
I think this is indeed useful, but I'm tempted to go further and say we should make this the default - and only - behavior. This will probably break existing code that accidentaly relied the fact that the implementation uses a bare fork(), but i'd say it's worth it:
- it's cleaner
- it will make it possible to remove all the ad-hoc handlers called after fork()
- it will remove the only place in the whole stdlib where fork() isn't followed by exec(): people who get bitten by issue #6721 will thus only be people calling explicitely fork(), in which case they're the sole responsibles for their misery ;-)

Another - although less common - advantage over the current implementation is that now one can run out of memory pretty easily if the operating system doesn't do overcommitting if you work with a large dataset. If fork() is followed by an exec, no problem.

Thoughts?

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:13:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 15:13:00 +0000
Subject: [issue13645] test_import fails after test_coding
In-Reply-To: <1324478921.76.0.234823529498.issue13645@psf.upfronthosting.co.za>
Message-ID: <1324480339.3385.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Indeed. EXT3's timestamps have a 1s granularity, for example.
> Another possibility would be to store both mtime and st_size (it's the
> default heuristic used by rsync does to decide whether to skip a
> file).

Good idea. It would also avoid too much Windows-specific code (subsecond
precision for timestamps requires the use of a Win32 API).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:28:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 15:28:04 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1324479868.79.0.609367570922.issue8713@psf.upfronthosting.co.za>
Message-ID: <1324481242.3385.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thanks for the patch sbt.
> I think this is indeed useful, but I'm tempted to go further and say
> we should make this the default - and only - behavior. This will
> probably break existing code that accidentaly relied the fact that the
> implementation uses a bare fork(),

There is probably lots of such code:
- code that passes non-pickleable function object / function args to
execute in the child process
- code that executes code with side effects at module top level
- code that relies (willingly or not) on other stuff such as fds being
inherited

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:45:09 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Dec 2011 15:45:09 +0000
Subject: [issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
In-Reply-To: <1324215538.93.0.209202773548.issue13627@psf.upfronthosting.co.za>
Message-ID: <1324482309.31.0.991898637083.issue13627@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine.

Awesome, thanks Antoine.  I will checkout the DH patch from issue13626 on Fedora today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13627>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:54:13 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Dec 2011 15:54:13 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324482853.22.0.905575058452.issue13626@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Per the Red Hat problems in issue13627 I just tried this patch on Fedora 16.  Everything built just fine.  However, the patch doesn't apply cleanly to tip an longer:

[meadori at motherbrain cpython]$ patch -p1 < ../patches/dh.patch 
patching file Doc/library/ssl.rst
Hunk #2 succeeded at 715 (offset 27 lines).
patching file Lib/ssl.py
Hunk #1 succeeded at 68 with fuzz 2.
patching file Lib/test/dh512.pem
patching file Lib/test/ssl_servers.py
Hunk #1 succeeded at 180 (offset 1 line).
Hunk #2 succeeded at 194 (offset 1 line).
patching file Lib/test/test_ssl.py
Hunk #2 succeeded at 101 with fuzz 2.
Hunk #3 succeeded at 541 (offset 3 lines).
Hunk #4 FAILED at 1200.
Hunk #5 succeeded at 1858 with fuzz 2 (offset 29 lines).
1 out of 5 hunks FAILED -- saving rejects to file Lib/test/test_ssl.py.rej
patching file Modules/_ssl.c
Hunk #1 succeeded at 1922 (offset 20 lines).
Hunk #2 succeeded at 2082 (offset 22 lines).
Hunk #3 succeeded at 2539 with fuzz 2 (offset 24 lines).

After fixing the unit test hunk everything builds and the SSL unit tests pass.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:57:24 2011
From: report at bugs.python.org (sbt)
Date: Wed, 21 Dec 2011 15:57:24 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1324483044.86.0.34425591672.issue8713@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> I think this is indeed useful, but I'm tempted to go further and say we 
> should make this the default - and only - behavior. This will probably 
> break existing code that accidentaly relied the fact that the 
> implementation uses a bare fork(), but i'd say it's worth it:

I'm not convinced about making it the default behaviour, and certainly not the only one.

I have a working patch which ensures that leaked semaphores get cleaned up on exit.  However, I think to add proper tests for the patch, test_multiprocessing needs to be refactored.  Maybe we could end up with

multiprocessing_common.py
test_multiprocessing_processes_fork.py
test_multiprocessing_processes_nofork.py
test_multiprocessing_manager_fork.py
test_multiprocessing_manager_nofork.py
test_multiprocessing_threads.py
test_multiprocessing_others.py

The actual unittests would be in multiprocessing_common.py and test_multiprocessing_others.py.  The other files would run the unittests in multiprocessing_common.py using different configurations.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:57:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Dec 2011 15:57:44 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1324483064.62.0.37167539768.issue8604@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'd like to make this move forward.
Milko, I see you have an implementation which looks OK at a first glance. Would like to propose a patch against the default branch? The patch should include documentation and tests.
I'm not sure about the best module to host this, though: os.path ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:04:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 16:04:40 +0000
Subject: [issue13511] Let ./configure accept multiple --includedir and
	--libdir options
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1324483480.46.0.846691919348.issue13511@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You haven?t answered my question: Is it a standard configure feature to support multiple --includedir and --libdir?

If it?s a standard feature used by people, then you can argue it?s a build bug for all active versions (2.7, 3.2, 3.3).

If it?s a request for something specific to CPython, then as a new feature it would go into 3.3 only.

----------
title: ./configure --includedir, --libdir accept multiple -> Let ./configure accept multiple --includedir and --libdir options
type: behavior -> enhancement
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13511>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:05:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Dec 2011 16:05:50 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1324483550.91.0.0679880012559.issue8713@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> There is probably lots of such code:

> I'm not convinced about making it the default behaviour, and 
> certainly not the only one.

Then I'm not convinced that this patch is useful.
Having three different implentations and code paths doesn't sound like a good idea to me.
fork() vs fork() + exec() is an implementation detail, and exposing such tweakables to the user will only make confusion worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:10:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 16:10:25 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1324483825.67.0.13192522722.issue1785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great stuff.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:14:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 21 Dec 2011 16:14:54 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324484094.57.0.886220872818.issue13644@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The behavior of Python 2 is not anymore correct than that of Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:15:44 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 21 Dec 2011 16:15:44 +0000
Subject: [issue13511] Let ./configure accept multiple --includedir and
	--libdir options
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1324484144.95.0.0738453623269.issue13511@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Parsing of options is implemented inside autoconf. The feature would have to be implemented in autoconf and then 'configure' would have to be regenerated from 'configure.in' using new version of autoconf.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13511>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:16:33 2011
From: report at bugs.python.org (naif)
Date: Wed, 21 Dec 2011 16:16:33 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324484193.55.0.80798803669.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Well, if you do:
"DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2" ciphers enabled are
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5 
PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1


If we want to start from the "DEFAULT" than we should probably disable:
- PSK
- CAMELLIA
- MD5
- IDEA
- SEED

That way:
openssl ciphers -v 'DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2:!PSK:!CAMELLIA:!MD5:!IDEA!SEED'

ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:29:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 16:29:20 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324484193.55.0.80798803669.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324484918.3385.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If we want to start from the "DEFAULT" than we should probably disable:
> - PSK
> - CAMELLIA
> - MD5
> - IDEA
> - SEED

Why do you want to disable all these?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:31:43 2011
From: report at bugs.python.org (sbt)
Date: Wed, 21 Dec 2011 16:31:43 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1324485103.7.0.29095919104.issue13577@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

A simplified patch getting rid of _PyCFunction_GET_RAW_SELF().

----------
Added file: http://bugs.python.org/file24068/method_qualname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:40:45 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Dec 2011 16:40:45 +0000
Subject: [issue13645] test_import fails after test_coding
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1324485645.94.0.676715656048.issue13645@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:46:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 16:46:42 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324486002.37.0.0515224595711.issue13585@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The idea is to add a general-purpose context manager to manage (python
> or non-python) resources that don't come with their own context manager.

I read the thread back on python-ideas and didn?t like the idea, without knowing exactly why?maybe a feeling that it?s too generic and less clean than adding context management support to the classes directly.  My opinion is only that of a user, I?m less qualified than Nick or Raymond for this module.

In the passage I quoted, I don?t understand what is meant by ?non-Python resources?.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:48:51 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 21 Dec 2011 16:48:51 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1324486002.37.0.0515224595711.issue13585@psf.upfronthosting.co.za>
Message-ID: <4EF20DF1.3010308@rath.org>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

On 12/21/2011 11:46 AM, ?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
>> The idea is to add a general-purpose context manager to manage (python
>> or non-python) resources that don't come with their own context manager.
> 
> In the passage I quoted, I don?t understand what is meant by ?non-Python resources?.

Think about e.g. mounting a file system.

Best,

   -Nikolaus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:49:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 16:49:30 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324486170.81.0.161359147392.issue2134@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The cmdoption directive should be used with a program directive.  See library/trace for an example of how to use it and to see the anchors and index entries it generates.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:55:08 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 21 Dec 2011 16:55:08 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1324486508.53.0.461058138023.issue12715@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24069/4832bf7aa028.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:57:09 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 21 Dec 2011 16:57:09 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1324486629.15.0.840606609505.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Thanks to Antoine & Charles-Fran?ois for their reviews! I think I've incorporated all desired changes.

Please let me know if I have missed something, meanwhile I'll tackle the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:59:51 2011
From: report at bugs.python.org (naif)
Date: Wed, 21 Dec 2011 16:59:51 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324486791.94.0.490262661912.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Well,

with your latest proposal 'HIGH:!aNULL:!eNULL:!SSLv2' :
- MD5 was disabled
- IDEA was disabled
- SEED was disabled

Then we realized that RC4 could be a cipher to be leaved enabled, so the new proposal starting from 'DEFAULT'.

While i don't like RC4 because it's not FIPS-140 compliant (https://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html) i understand that we may want to keep it.

I would suggest by default to keep disabled also CAMELIA and PSK because almost no one use it, they are just into the standard like many ciphers.

Generally speaking, as a concept to define a default we could:
- Start from a FIPS-140 compliant SSL stack
- Open some additional ciphers for compatibility reason (for example RC4-SHA)

What do you think about such approach?

-naif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:01:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 17:01:15 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs waiting for connection
	close after a redirect
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <1324486875.37.0.0878124430523.issue8035@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this would need a test.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:03:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 17:03:03 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324486983.89.0.30111495326.issue13585@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> In the passage I quoted, I don?t understand what is meant by ?non-Python resources?.
> Think about e.g. mounting a file system.

Ah, ok.  In that case there would still be a Python-level object (just like a Python file object will also release the OS-level handle when it?s closed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:10:00 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 21 Dec 2011 17:10:00 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324486791.94.0.490262661912.issue13636@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNKNTW6TV5nA+DmU4a3oqgr3n+6f1oZXPqzp5gxZ5zDmBg@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Why make this decision ourselves at all? Copy what Mozilla and Chromium do
by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:10:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 17:10:45 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324487445.4.0.794595123843.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Lars: I will check the history to see if there is a reason (there is probably none) and apply your patch, thank you.

Jason: Thanks for the input.

> It's not obvious to me what the encoding should be. Python and the tarfile module can
> accept unicode filenames.
Note that distutils2 supports back to 2.4, which may not be as convenient.

> It seems that only the gzip part of tarfile fails if a unicode name is passed.
OK.

> Encoding to 'utf-8' or the default file system encoding doesn't seem right (as the
> characters end up getting stored in the gzip archive itself).
I don?t understand.

> Additionally, encoding as 'utf-8' would cause the file to be created with a utf-8 filename,
> which would be undesirable.
Why?

> So in the current repo, I've created a check to convert the filename to ASCII. If it can be
> converted to ASCII, it is converted and passed through to tarfile. This should address the
> majority of users who have thus encountered this issue. For those who wish to use non-ascii
> characters in project names or versions, one will have to use Python 3 or wait until #13639
> is fixed.
The problem is that even in the latest PEP (345), the characters allowed in a project name are under-specified.  I don?t know if restricting to ASCII-only is acceptable.

> Please review the enclosed patch.
I will.

> Since one test fails (and is known to fail), should it omitted? Can it remain but be marked as
> "expected to fail"?
Is it the test with non-ASCII characters?  If there?s hope to fix it later, you can include it and mark it @unittest.expectedFailure.

----------
keywords:  -easy, patch
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:22:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 17:22:15 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <CAGE7PNKNTW6TV5nA+DmU4a3oqgr3n+6f1oZXPqzp5gxZ5zDmBg@mail.gmail.com>
Message-ID: <1324488092.3385.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Why make this decision ourselves at all? Copy what Mozilla and Chromium do
> by default.

If that translates to an explicit list of ciphers it will be a pain to
maintain. Using a generic OpenSSL string such as "DEFAULT:!LOW:[etc.]"
means OpenSSL mostly does the maintenance for us.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:26:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 17:26:40 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324486791.94.0.490262661912.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324488358.3385.27.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> with your latest proposal 'HIGH:!aNULL:!eNULL:!SSLv2' :
> - MD5 was disabled
> - IDEA was disabled
> - SEED was disabled

That was the consequence of it, but that wasn't an explicit goal.

> Generally speaking, as a concept to define a default we could:
> - Start from a FIPS-140 compliant SSL stack
> - Open some additional ciphers for compatibility reason (for example
> RC4-SHA)
> 
> What do you think about such approach?

As I already said, the more sophisticated the approach, the more tedious
the maintenance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:28:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Dec 2011 17:28:58 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs waiting for connection
	close after a redirect
In-Reply-To: <1324486875.37.0.0878124430523.issue8035@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3f5xnesaUAwzuUZ2jNTpA59p1n7Sc7w42rgdtKNSLRag@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Yes, but it's not easy: the different URLs provided don't demonstrate
the behavior anymore (even if we do find such an URL, there's no
guarantee it won't change in a couple days/weeks).
It could be possible to set up an ad-hoc httpserver for that purpose,
but that sounds a bit overkill.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:31:18 2011
From: report at bugs.python.org (naif)
Date: Wed, 21 Dec 2011 17:31:18 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324488678.17.0.706158850225.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Well, my concept is that it would be reasonable to use what people consider secure.

SSL/TLS are security protocol.

Some combination of the protocol configuration (ciphers/hash/key exchange) are:
- known to be insecure
- known to be secure
- known to be unused (like SEED, only used in South Korea by military applications) or PSK with almost no adoption
- Unknown (like CAMELIA, i don't find a single software using it)

The concept i would propose is to choose the ciphers that "known to be secure" by disabling everything else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:35:48 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 21 Dec 2011 17:35:48 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324488948.91.0.745330117699.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> > Encoding to 'utf-8' or the default file system encoding doesn't seem
> > right (as the characters end up getting stored in the gzip archive itself).
> I don?t understand.

The characters are being stored in the gzip archive as part of the gzip header. The comment in the Python 3 trunk indicates the encoding should be iso-8859-1: https://bitbucket.org/mirror/cpython/src/f3041e7f535d/Lib/tarfile.py#cl-475

My point is that the file system encoding is not relevant here. Because the name is being stored in a gzip blob, it should be encoded according to gzip specs.

> > Additionally, encoding as 'utf-8' would cause the file to be created
> > with a utf-8 filename, which would be undesirable.
> Why?

My concern here was that if we're encoding the string as utf-8 before passing to the __builtins__.open() call, Python might encode _that_ utf-8 string using the file system encoding and save the file that way (where the file is named with a utf-8 encoded string, not the unicode string intended). After further investigation, and based on the work that's been proposed, this is not a risk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:36:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 17:36:23 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324488678.17.0.706158850225.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324488940.3385.28.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The concept i would propose is to choose the ciphers that "known to be
> secure" by disabling everything else.

I hate repeating myself, but who will maintain it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:59:49 2011
From: report at bugs.python.org (Ron Adam)
Date: Wed, 21 Dec 2011 17:59:49 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324490389.4.0.118602385474.issue13607@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

I think the time benefits I saw are dependent on how the C code is compiled.  So it may be different on different compilers or the same compiler with only a very minor change.

Some of the things I've noticed...

A switch is sometimes slower if it has a "default:" block.

Moving "why = tstate->why_exit;" to just before the if helps a tiny bit.

    why = tstate->why_exit;
    if (why != WHY_EXCEPTION) {

Returning directly out of the WHY_YIELD case.

        case WHY_YIELD:
            return result;

These will be mostly compiler dependent, but they won't slow things down any either.

What I was trying to do is clean up things a bit in ceval.c.  Having the why available on the frame can help by allowing some things to be moved out of ceval.c where it makes sense to do that.

I'll post a new diff tonight with the why_exit moved back to the frame object and the why's back to enums.  Yes, I think the frame object is a good place for it.

One of the odd issues is the opcode and why values sometimes need to be pushed on the value stack.  Which means it needs to be converted to a pyobject first, then converted back after it's pulled off the stack.  I'm looking for a way to avoid that.

I also was able to make fast_block_end section simpler and more understandable without making it slower.  I think it was trying to be too clever in order to save some lines of code.  That makes it very hard to figure out by someone else.

But first I need to finish my Christmas shopping, I'll post a new patch tonight when I get a chance. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:07:58 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 21 Dec 2011 18:07:58 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1324490878.91.0.380436570454.issue12715@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24070/d9212bb67f64.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:09:35 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 21 Dec 2011 18:09:35 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1324490975.34.0.248185317251.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

The patch contains also the necessary changes for the docs now.

Please let me know, if I can do anything else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:15:11 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 21 Dec 2011 18:15:11 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1324486983.89.0.30111495326.issue13585@psf.upfronthosting.co.za>
Message-ID: <4EF2222D.6010201@rath.org>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

On 12/21/2011 12:03 PM, ?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
>>> In the passage I quoted, I don?t understand what is meant by ?non-Python resources?.
>> Think about e.g. mounting a file system.
> 
> Ah, ok.  In that case there would still be a Python-level object (just like a Python file object will also release the OS-level handle when it?s closed).

I don't think so.

subprocess.check_call(['mount', 'bla', '/mnt'])

Allocates the resource (mounts the file system) but doesn't leave you
with any Python object.

Best,

   -Nikolaus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:19:41 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 21 Dec 2011 18:19:41 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324491581.39.0.397511787735.issue11638@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Just for the record:

The gzip format (defined in RFC 1952) allows storing the original filename (without the .gz suffix) in an additional field in the header (the FNAME field). Latin-1 (iso-8859-1) is required. It is ironic that this causes so much trouble, because it is never used. A gzip file without that field is prefectly valid. The gzip program for example stores the original filename by default but does not use it when decompressing unless it is explicitly told to do so with the -N/--name option. If no FNAME field is present in a gzipped file the gzip program just falls back on stripping the .gz suffix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:26:14 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Dec 2011 18:26:14 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324491974.37.0.156072589443.issue13607@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:26:29 2011
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 21 Dec 2011 18:26:29 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1324479868.79.0.609367570922.issue8713@psf.upfronthosting.co.za>
Message-ID: <9B522B2EBFF744329CA7AF5DA791B427@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Wednesday, December 21, 2011 at 10:04 AM, Charles-Fran?ois Natali wrote:

While I would tend to agree with you in theory - I don't think we should make it the default - at least not without a LOT of lead time. There's a surprising amount of code relying on the current behavior that I think the best course is to enable this option, and change the docs to steer users in this direction.

For users jumping from 2.x into 3.x, I think the less surprises they have the better, and changing the default behavior of the stdlib module in this was would qualify as surprising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:27:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 18:27:39 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324429950.17.0.0585650740961.issue13643@psf.upfronthosting.co.za>
Message-ID: <4EF22598.6080900@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Having more than one encoding on unix is already a reality, there's nothing to stop someone setting LANG=de_DE.UTF-8 and LC_MESSAGES=C say.

Nope. The locale encoding is chosen using LC_ALL, LC_CTYPE or LANG 
variable: use the first non-empty variable. LC_MESSAGES doesn't affect 
the encoding. Example:

$ LANG=de_DE.iso88591 LC_MESSAGES=fr_FR.UTF-8 python -c 'import os, 
locale; locale.setlocale(locale.LC_ALL, ""); 
print(locale.getpreferredencoding(), repr(os.strerror(23)))'
('ISO-8859-1', "'Trop de fichiers ouverts dans le syst\\xe8me'")

$ LANG=de_DE.UTF-8 LC_MESSAGES=fr_FR.UTF-8 python -c 'import os, locale; 
locale.setlocale(locale.LC_ALL, ""); 
print(locale.getpreferredencoding(), repr(os.strerror(23)))'
('UTF-8', "'Trop de fichiers ouverts dans le syst\\xc3\\xa8me'")

 > The real lesson is not that having more than one encoding
 > is dangerous, but that having incompatible encodings is dangerous.

Yes, and ASCII and UTF-8 are incompatible. ASCII is unable to decode an 
UTF-8 encoded string.

 > Expanding the filesystem default encoding to utf-8
 > should be a very narrow change, mostly just affecting io
 > and os operations.

It affects everything because filenames are used everywhere.

 > On modern systems, this problem is solved by making the
 > standard encoding UTF-8.  So it is unfortunate that, when
 > no locale is set, Python3 defaults to ascii for the filesystem.

Python doesn't invent an encoding: ASCII is the result of 
nl_langinfo(CODESET). Example:

$ python3 -c "import locale; print(locale.nl_langinfo(locale.CODESET))"
UTF-8
$ LANG=C python3 -c "import locale; 
print(locale.nl_langinfo(locale.CODESET))"
ANSI_X3.4-1968

 >> $ LANG=C python3 -c "import os; print(os.listdir())"
 >> ['h\udcc3\udca9h\udcc3\udca9']

 > It's possible to work around this in some cases, such as listdir,
 > by coping with the result including some byte strings, and then
 > manually decoding them.  But there are, iirc, other cases where
 > the call just fails and there is no easy workaround.

In Python 3, os.listdir(str) *CANNOT* fail because of a Unicode decode 
error thanks to the PEP 393. In Python 2, it works differently (return 
the raw bytes filename if decoding fails).

 > Windows and Mac have annoying bugs too, even bugs specifically
 > about Unicode.

Windows supports Unicode since Windows 95 and fully support all Unicode 
characters since Windows 2000.

Mac enforces UTF-8. For example, it is not possible to *create* a 
filename with invalid UTF-8 name. It looks like it always use UTF-8 on 
the command line.

On Linux, we cannot rely on anything except of the locale encoding. We 
try to use Unicode API when it's possible (e.g. use wcstime() instead of 
strftime()), but quite all functions use byte strings and so rely on the 
locale encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:28:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 18:28:23 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <E1RdQtp-0006zH-LF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a60a3610a97b by Lars Gust?bel in branch '2.7':
Issue #13639: Accept unicode filenames in tarfile.open(mode="w|gz").
http://hg.python.org/cpython/rev/a60a3610a97b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:37:54 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 18:37:54 +0000
Subject: [issue12510] IDLE get_the_calltip mishandles raw strings
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1324492674.1.0.690916832184.issue12510@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The attached patch fixes the bug. The bug occurs in "get_entity" which is used to get the object. Then "get_argspec" determines the calltip text. 

The calltip can be prevented for strings by having get_argspec check if the object has a "__call__" method. I opted for adding "not callable" to the calltip initially for testing, but setting argspec="" will prevent the calltip altogether.

----------
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file24071/issue12510.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12510>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:03:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 19:03:51 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324494231.58.0.0608670473314.issue13636@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> By default the Python SSL/TLS Stack (client/server) expose
> unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).

If there is a problem, it should not be fixed in Python, but in the underlying library (OpenSSL) or in applications. Python only exposes features of the OpenSSL library. You should not see Python as an application but as a language: Python doesn't know what is your use case, or if you write a client or a server.

I suppose that OpenSSL has good reasons to still support weak algorithms like MD4 or SSLv2. Some operating systems, like Debian Sid, disable SSLv2 in the OpenSSL at the compilation.

If you consider that it is too complex to change the cipher list in a high level API (like http.client?), we may a ssl.DEFAULT_CIPHERS to allow an application to change the *default* cipher list.

SSLContext() requires a protocol, I suppose that the protocol is also by OpenSSL used in the negociation of the cipher list.

If we change the default behaviour, we should allow the user to get back the old behaviour (e.g. mark ssl._DEFAULT_CIPHERS as public in default_ciphers.patch).

--

IMO this issue is more a documentation issue: we should add a warning in the ssl module documentation, and maybe also in the documentation of modules using the ssl module (as we done for certificates for HTTPS).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:07:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 19:07:23 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324494443.29.0.942749989949.issue13639@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+ self.name = self.name.encode("iso-8859-1", "replace")

Why did you chose ISO-8859-1? I think that the filesystem encoding should be used instead:

-            self.name = self.name.encode("iso-8859-1", "replace")
+            self.name = self.name.encode(ENCODING, "replace")

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:15:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 19:15:09 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1324494909.65.0.099332420871.issue8604@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm not sure about the best module to host this, though: os.path ?

Some OS don't provide atomic rename. If we only define a function when it is atomic (as we do in the posix module, only expose functions available on the OS), programs will have to write two versions of their function. I prefer to write a "best-effort" function, and so I consider that shutil is the best place for such function.

If this function requires a function specific to the OS, the specific function can be added to posix (or another module).

Example:

with shutil.write_file(filename) as f:
  f.write("I hope it will be atomic!")

We need an "atomic rename file" function to implement "atomic write file": see #8828.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:31:14 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 21 Dec 2011 19:31:14 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324495874.7.0.972576560354.issue13639@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

See http://bugs.python.org/issue11638#msg150029

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:36:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 19:36:40 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324496200.18.0.257274812357.issue13639@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"The gzip format (defined in RFC 1952) allows storing the original filename (without the .gz suffix) in an additional field in the header (the FNAME field). Latin-1 (iso-8859-1) is required."

Hum, it looks like the author of the gzip program (on Linux Fedora 16) didn't read the RFC!

$ tar -cvf h?ho.tar README
README
$ gzip h?ho.tar 
$ hachoir-urwid ~/prog/python/default/h?ho.tar.gz 
0) file:/home/haypo/prog/python/default/h?ho.tar.gz: ...
   0) signature= "\x1f\x8b": GZip file signature (\x1F\x8B) (2 bytes)
   2) compression= deflate: Compression method (1 byte)
   3.0) is_text= False: File content is probably ASCII text (1 bit)
   3.1) has_crc16= False: Header CRC16 (1 bit)
   3.2) has_extra= False: Extra informations (variable size) (1 bit)
   3.3) has_filename= True: Contains filename? (1 bit)
   3.4) has_comment= False: Contains comment? (1 bit)
   3.5) reserved[0]= <null> (3 bits)
   4) mtime= 2011-12-21 19:34:54: Modification time (4 bytes)
   8.0) reserved[1]= <null> (1 bit)
   8.1) slowest= False: Compressor used maximum compression (slowest) (1 bit)
   8.2) fastest= False: Compressor used the fastest compression (1 bit)
   8.3) reserved[2]= <null> (5 bits)
   9) os= Unix: Operating system (1 byte)
   10) filename= "h??ho.tar": Filename (10 bytes)

Raw display:

   10) filename= "h\xc3\xa9ho.tar\0": Filename (10 bytes)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:47:05 2011
From: report at bugs.python.org (Martin)
Date: Wed, 21 Dec 2011 19:47:05 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324496825.25.0.531524103923.issue13643@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

> Nope. The locale encoding is chosen using LC_ALL, LC_CTYPE or LANG 
> variable: use the first non-empty variable. LC_MESSAGES doesn't affect 
> the encoding. Example:

That's good to know, thanks. Only leaves the case where setlocale is called again with a different value.

> Yes, and ASCII and UTF-8 are incompatible. ASCII is unable to decode an 
> UTF-8 encoded string.

I think we're envisioning different things here.

  os.stat("\u2601") # with LANG=C
    current -> UnicodeEncodeError
    changed -> works if utf-8 encoded file exists

  os.listdir() # with LANG=C
    current -> returns non-ascii as unicode with funky surrogates
    changed -> returns non-utf-8 as unicode with funky surrogates

> It affects everything because filenames are used everywhere.

But currently everything handling filenames as unicode on nix needs to worry about surrogates (that can't be encoded as ascii) already, or it will still be passing values that can't be interpreted by other processes as you highlighed earlier. Making utf-8 names come out correctly rather than as surrogates doesn't seem like it increases the burden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 21:04:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2011 20:04:44 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324497884.3.0.0325051788672.issue13643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> it will still be passing values that can't be
> interpreted by other processes as you highlighed earlier.

On UNIX, data going outside Python has be be encoded: you pass byte strings, not directly Unicode. Surrogates are encoded back to original bytes.

Example:

>>> b'a\xff'.decode('ascii', 'surrogateescape')
'a\udcff'
>>> b'a\xff'.decode('ascii', 'surrogateescape').encode('ascii', 'surrogateescape')
b'a\xff'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 21:19:58 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 20:19:58 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1324498798.07.0.780894235342.issue9016@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is this still a problem?

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Wed Dec 21 21:48:27 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 20:48:27 +0000
Subject: [issue6528] builtins colored as keyword at beginning of line
In-Reply-To: <1248125971.41.0.191814152476.issue6528@psf.upfronthosting.co.za>
Message-ID: <1324500507.64.0.615885609139.issue6528@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The attached patch excludes keywords from the builtin list and corrects the highlighting configuration panel.

----------
keywords: +patch
nosy: +serwy
versions: +Python 3.2, Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file24072/issue6528.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6528>
_______________________________________

From report at bugs.python.org  Wed Dec 21 21:50:53 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 21 Dec 2011 20:50:53 +0000
Subject: [issue13597] Improve documentation of stdout/stderr buffering in
	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1324500653.42.0.261788132816.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Thanks.

I'm not sure what you've written about the "-u" flag is correct though currently. From experimenting I believe it changes buffering of stdout and stderr to line-buffering also when directed to file, i.e. it does affect the behaviour of the text-layer.

Some other changes might be needed also, but perhaps they should wait until we know whether issue13601 will be accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13597>
_______________________________________

From report at bugs.python.org  Wed Dec 21 22:10:27 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 21:10:27 +0000
Subject: [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1324501827.93.0.656453642261.issue8093@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This issue should be closed since issue12540 fixes it.

I verified that the bug exists with 3.1.4 on Vista. It does not exist with 3.2.2 on Vista.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8093>
_______________________________________

From report at bugs.python.org  Wed Dec 21 22:13:15 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 21:13:15 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1324501995.77.0.0468564978328.issue8820@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is this still a problem with 2.7?

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8820>
_______________________________________

From report at bugs.python.org  Wed Dec 21 22:44:09 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 21 Dec 2011 21:44:09 +0000
Subject: [issue11829] inspect.getattr_static code execution with
	meta-metaclasses
In-Reply-To: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>
Message-ID: <1324503849.28.0.306230986741.issue11829@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

As the test demonstrates, it's still possible to trigger a dynamic lookup without the patch, hence I think this is still needed and valid, yes.

I updated the patch to make it reflect the latest committed changes.

----------
Added file: http://bugs.python.org/file24073/getattr_static_metaclasses_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11829>
_______________________________________

From report at bugs.python.org  Wed Dec 21 22:50:05 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 21:50:05 +0000
Subject: [issue7883] CallTips.py _find_constructor does not work
In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za>
Message-ID: <1324504205.95.0.178098336152.issue7883@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The patch works for me as well against 3.3a0. 

Are there any cases where "__init__.__func__" would work?

----------
nosy: +serwy
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7883>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:44:39 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 22:44:39 +0000
Subject: [issue13078] Python Crashes When Saving Or Opening
In-Reply-To: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za>
Message-ID: <1324507479.27.0.632304185002.issue13078@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is this still an issue?

Ash, can you please run IDLE from the command line and report the error message from there?

   cd c:\python32
   python -m idlelib.idle

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13078>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:50:53 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 22:50:53 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1324507853.77.0.980347006634.issue10079@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The large patch also contains the same patch in issue6649.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:54:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Dec 2011 22:54:43 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324508083.56.0.40180991722.issue13643@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

> But currently everything handling filenames as unicode on
> nix needs to worry about surrogates (that can't be encoded
> as ascii) already, or it will still be passing values that
> can't be interpreted by other processes as you highlighed
> earlier. Making utf-8 names come out correctly rather than
> as surrogates doesn't seem like it increases the burden.

And that is *exactly* the problem.  You can't assume that those other programs are expecting utf-8 on unix.  The only thing you have to go by is the locale.  So that's what we use.  And as Haypo pointed out, unless you manipulate it file system stuff gets turned back into the same bytes when it exits Python, so pre-existing stuff should work fine.

Now, if posix (or a given unix platform, like OS X did) would say "utf-8 is the standard filesystem and program interchange encoding", we could change Python.  Short of that, it is our experience that using anything other than locale leads to more problems than using locale does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:01:07 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 23:01:07 +0000
Subject: [issue9150] IDLE should not save trailing whitespace after strip
	trailing whitespace has been used
In-Reply-To: <1278179945.62.0.903425904075.issue9150@psf.upfronthosting.co.za>
Message-ID: <1324508467.19.0.781803745485.issue9150@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is this still an issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9150>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:02:31 2011
From: report at bugs.python.org (Martin Pool)
Date: Wed, 21 Dec 2011 23:02:31 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324431645.611.2.camel@localhost.localdomain>
Message-ID: <CAA9uavDwz1NR1NRiviJBUdS6d+N7YyrnkKUYg_6-9oVeX-K06g@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 21 December 2011 12:41, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> The standard encoding is UTF-8.
>
> How so? I don't know of any Linux or Unix spec which says so. If you get
> the Linux heads to standardize this then I'll certainly be very happy
> (and countless others will, too). But AFAIK this it not the case and I
> don't see why you are asking Python to make a choice that OS vendors
> refuse to make. You are certainly asking the wrong project to solve this
> problem.

It is a de facto, not de jure standard: UTF-8 is how things are
typically stored.  Other software (eg gnome file handling utilities)
makes this assumption.  See eg
<http://www.cl.cam.ac.uk/~mgk25/unicode.html#linux>.

I would be happy to see an authoritative document saying this is how
things _should_ be stored, but I can't find one yet.  But in Unix
there are no ultimate authorities: even if someone announced filenames
are utf-8 there will obviously continue to be many machines where in
practice they are not.

I started asking about it over here, to see if at least Ubuntu can
have an opinion that this is how things should normally be:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-December/034588.html

I'm not sure what you expect a technical solution at the OS level
would look like.  The api is 8-bit strings and that's not likely to
change.  It's possible to have a situation where no locale is
specified.  Applications unavoidably need to have some opinion about
what to do there.  Other applications assume the filenames are utf-8.
Python assumes that text in general will be UTF-8
(getdefaultencoding).

It is almost like your caricature of OS developers as being
anglocentric, but in fact here it's Python that assumes everything is
probably ascii - or more charitably, it is just assuming that failing
when things aren't ascii is the best tradeoff.  Maybe it is.

One OS-level fix is to try to reduce the number of situations where
people see no locale, or the C locale, and give them C.UTF-8 instead.
That is probably worth doing.  But having no locale can still happen,
and I think Python could handle that better, so the changes are
complimentary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:26:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 23:26:12 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <CAA9uavDwz1NR1NRiviJBUdS6d+N7YyrnkKUYg_6-9oVeX-K06g@mail.gmail.com>
Message-ID: <1324509930.3667.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It is a de facto, not de jure standard: UTF-8 is how things are
> typically stored.  Other software (eg gnome file handling utilities)
> makes this assumption.  See eg
> <http://www.cl.cam.ac.uk/~mgk25/unicode.html#linux>.

So should we specifically detect Linux? And under which conditions? When
the encoding is detected to be "ASCII"?

> But in Unix
> there are no ultimate authorities: even if someone announced filenames
> are utf-8 there will obviously continue to be many machines where in
> practice they are not.

POSIX is kind of an authority. Freedesktop.org could be another. LSB yet
another.
(all with different scopes obviously)

> I'm not sure what you expect a technical solution at the OS level
> would look like.

It doesn't need to be technical. It could just be a convention (all
filesystem paths, and other user-visible text such as environment
variables etc., are utf-8 encoded).
Although enforcing it technically would of course be safer.

> That is probably worth doing.  But having no locale can still happen,
> and I think Python could handle that better, so the changes are
> complimentary.

How do you detect "no locale"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:53:20 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 21 Dec 2011 23:53:20 +0000
Subject: [issue9201] IDLE: raises Exception TclError in a special case
In-Reply-To: <1278600015.52.0.587656960584.issue9201@psf.upfronthosting.co.za>
Message-ID: <1324511600.83.0.100184249398.issue9201@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This issue was fixed in 500e48708470, as part of issue3851.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9201>
_______________________________________

From report at bugs.python.org  Thu Dec 22 01:00:43 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 22 Dec 2011 00:00:43 +0000
Subject: [issue13553] Tkinter doesn't set proper application name
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1324512043.02.0.756518403462.issue13553@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Does IDLE appear as "Tk" in Gnome3?

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13553>
_______________________________________

From report at bugs.python.org  Thu Dec 22 01:21:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Dec 2011 00:21:27 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <CAA9uavDwz1NR1NRiviJBUdS6d+N7YyrnkKUYg_6-9oVeX-K06g@mail.gmail.com>
Message-ID: <4EF27885.6030204@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This discussion is becoming very long, I didn't remember the original 
purpose. You want to use UTF-8 instead of ASCII, so what? What do you 
want to do with your nicely well decoded filenames? You cannot print it 
to your terminal nor pass it to a subprocess, because your terminal uses 
ASCII, as subprocess. I don't see how it would help you.

Thanks to the PEP 383, Python 3 "just works" with an ASCII locale 
encoding. You can list the content of a directory and display a filename 
to your terminal: it will be displayed correctly (even if the terminal 
uses the correct encoding, UTF-8, whereas Python has an empty 
environment and use ASCII); you can also pass the filename to a 
subprocess: the other program will be able to open the file.

I don't understand what is the problem that your are trying to solve.

On 22/12/2011 00:02, Martin Pool wrote:
> It is a de facto, not de jure standard: UTF-8 is how things are
> typically stored.

For your information, on FreeBSD, Solaris and Mac OS X, the "C" locale 
encoding uses the ISO-8859-1, whereas on Linux it uses the "ASCII" 
encoding. There is no such "de facto standard". Each platform uses a 
different encoding and handle codecs differently.

> Other software (eg gnome file handling utilities)
> makes this assumption.  See eg
> <http://www.cl.cam.ac.uk/~mgk25/unicode.html#linux>.

The Qt library (and so KDE) and the glib library (and so Gtk and Gnome) 
use also the locale encoding to encode and decode filenames.

The glib has an useful g_get_filename_charsets() function trying other 
encodings to format correctly a filename.

> I'm not sure what you expect a technical solution at the OS level
> would look like.  The api is 8-bit strings and that's not likely to
> change.

Mac OS X kept the old legacy bytes API, but the kernel enforces valid 
UTF-8 names for filenames. This is a good start to move forward to 
Unicode. On such system, we can make some assumptions. On Linux, we 
cannot do such assumptions today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 01:35:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Dec 2011 00:35:45 +0000
Subject: [issue13585] Add contextlib.CleanupManager
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324514145.99.0.714969393103.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

My earlier descriptions here aren't really adequate - as soon as I started putting contextlib2 together, this CleanupManager idea quickly morphed into ContextStack [1], which is a far more powerful tool for manipulating context managers in a way that doesn't necessarily correspond with lexical scoping in the source code. Using the "collection of files" example:

    with ContextStack() as stack:
        files = [stack.enter_context(open(fname)) for fname in filenames]
        # All opened files will automatically be closed at the end of
        # the with statement, even if attempts to open files later
        # in the list throw an exception

Or the optional resource use case:

    with ContextStack() as stack:
        if resource is None:
            resource = stack.enter_context(make_default_resource())
        # If we created it, the resource will be cleaned up
        # Otherwise, it will be left alone

The "cleanup only if the operation fails" use case (coming in v0.3 [2])

    def open_files(*filenames):        
        """Returns an (opened_files, context_stack) 2-tuple

        The context stack will automatically close all of the opened files.
        If any file fails to open, all previously opened file handles will be released immediately.
        """
        with ContextStack() as stack:
            files = [stack.enter_context(open(fname)) for fname in filenames]
            return files, stack.preserve()

The "don't repeat your __exit__ code in __enter__" use case:

    def __enter__(self):
        resource = self._acquire_resource()
        with ContextStack() as stack:
            stack.register_exit(self.__exit__)
            self._check_resource_validity()
            stack.preserve() # All good!
        return resource

(In 0.3, register_exit() will probably check for __exit__ attributes automatically, so it will accept both callables and context managers)

[1] http://contextlib2.readthedocs.org/en/latest/index.html#contextlib2.ContextStack
[2] https://bitbucket.org/ncoghlan/contextlib2/issue/1/add-a-preserve-method-to-relinquish

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Thu Dec 22 01:50:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Dec 2011 00:50:19 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324515019.13.0.166871809348.issue13643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> Nope. The locale encoding is chosen using LC_ALL, LC_CTYPE or LANG 
>> variable: use the first non-empty variable. LC_MESSAGES doesn't affect 
>> the encoding. Example:
>
> That's good to know, thanks. Only leaves the case where setlocale
> is called again with a different value.

You mean changing the current locale encoding using setlocale(LC_CTYPE)? It doesn't affect the encoding used by Python for filenames (and other OS data). It is a design choice, but also mandatory to avoid mojibake. It was possible in Python 3.1 to set the filesystem encoding, but it doesn't solve any problem, whereas it leads to mojibake is most (or all?) cases. A very important property is: os.fsencode(os.fsdecode(name)) == name. It fails if the result of os.fsdecode(name) was stored before the encoding was changed.

Few C functions are affected by the locale encoding: strerror() and strftime() (tell me if there are others!). Python 3.2 used to filesystem encoding (so the locale encoding read at startup) for them, but it was wrong. I fixed this issue recently:  #13560 (see also #13619.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 01:54:15 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 22 Dec 2011 00:54:15 +0000
Subject: [issue694339] IDLE: Dedenting with Shift+Tab
Message-ID: <1324515255.29.0.414575691728.issue694339@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I applied the patch and encountered a problem. MultiCall.py is replacing "<Shift-Key-Tab>" with "<Shift-KeyPress-Tab>". When this happens, the logic for rebinding "<<PrevWindow>>" fails.

event_info('<<PrevWindow>>') returns ('<Key-ISO_Left_Tab>', '<Key-hpBackTab>', '<Shift-Key-Tab>') 

event_info('<<dedent-region>>') returns ('<Control-KeyPress-bracketleft>', '<Shift-KeyPress-Tab>')

This is with 3.3a0 on Ubuntu 11.04.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue694339>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:13:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2011 01:13:44 +0000
Subject: [issue11829] inspect.getattr_static code execution with
	meta-metaclasses
In-Reply-To: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>
Message-ID: <E1RdXE5-0005hC-Og@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8f33758df19a by Michael Foord in branch '3.2':
Metaclasses with metaclasses with a __dict__ descriptor can no longer trigger code execution with inspect.getattr_static.
http://hg.python.org/cpython/rev/8f33758df19a

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11829>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:16:55 2011
From: report at bugs.python.org (Martin Pool)
Date: Thu, 22 Dec 2011 01:16:55 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <4EF27885.6030204@haypocalc.com>
Message-ID: <CAA9uavA08pN19LC2i159wCnJyOaO52THNWfYqsM5dG5Utjb2tg@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 22 December 2011 11:21, STINNER Victor <report at bugs.python.org> wrote:
> This discussion is becoming very long, I didn't remember the original
> purpose.

The proposal is that in some cases where Python currently assumes
filenames are ascii on Linux, it ought to instead assume they are
utf-8.

> You want to use UTF-8 instead of ASCII, so what? What do you
> want to do with your nicely well decoded filenames? You cannot print it
> to your terminal nor pass it to a subprocess, because your terminal uses
> ASCII, as subprocess. I don't see how it would help you.

When the application has a unicode string, it can always encode itself
in whatever way it thinks most appropriate.  For instance if it is a
network service, the locale in which it was started may be entirely
irrelevant to the encoding it wants to talk to a particular peer.

However, there are or were some Python filesystem APIs where it is
very hard for the application to avoid being limited to the encoding
Python assumes at startup.  Also, for good reasons, the application
cannot change the filesystem encoding once it starts.  So the reason
for proposing a patch to Python is that there is no way for the
application to escape, once Python's assumed all names will be ascii.

It may be that all of those limitations have since been fixed
separately, either through pep383 or separate patches, so the
application at least has a chance to work around it.  It would be nice
to not burden the application or user with working around this when
the filenames really are valid in what should be the user's locale,
but perhaps this is the OS's fault for not having the right locale
configured.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:32:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Dec 2011 01:32:52 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <CAA9uavA08pN19LC2i159wCnJyOaO52THNWfYqsM5dG5Utjb2tg@mail.gmail.com>
Message-ID: <4EF2893E.1000403@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On 22/12/2011 02:16, Martin Pool wrote:
> The proposal is that in some cases where Python currently assumes
> filenames are ascii on Linux, it ought to instead assume they are
> utf-8.

Oh, I expected a use case describing the problem, not the proposed 
solution :-)

>> You want to use UTF-8 instead of ASCII, so what? What do you
>> want to do with your nicely well decoded filenames? You cannot print it
>> to your terminal nor pass it to a subprocess, because your terminal uses
>> ASCII, as subprocess. I don't see how it would help you.
>
> When the application has a unicode string,

Where does this string come from? (It is an important question).

If your locale encoding is ASCII, you cannot write such non-ASCII 
filenames using the keyboard for example.

 > with working around this when the filenames really are
 > valid in what should be the user's locale,

On your computer, UTF-8 is maybe a good candidate for "what should be 
the user's locale", but you cannot generalize for all computers.

I also wanted to force UTF-8 everywhere, but you cannot do that or your 
program will just not work in some configurations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:36:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Dec 2011 01:36:55 +0000
Subject: [issue13585] Add contextlib.ContextStack
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324517815.37.0.34826045613.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Updated issue title to reflect what I'll eventually be proposing (once the ContextStack API has had a chance to mature on PyPI as part of contextlib2)

----------
title: Add contextlib.CleanupManager -> Add contextlib.ContextStack

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:40:07 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 22 Dec 2011 01:40:07 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1324518007.45.0.218884054112.issue12930@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I applied the patch and it failed against the attached "tab_test.py" file. For reference, every '\t' in the file is followed by "Tab".

----------
nosy: +serwy
Added file: http://bugs.python.org/file24074/tab_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:41:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Dec 2011 01:41:54 +0000
Subject: [issue13585] Add contextlib.ContextStack
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324518114.38.0.273753234019.issue13585@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

"I put my version up as a cookbook recipe: http://code.activestate.com/recipes/577981-cleanupmanager-for-with-statements/"

One other idea is to model what I've done with the itertools docs by adding a recipe section.  I used it as an incubator for possible new itertools; as a set of tested cut-and-pasteable recipes; and to serve as an instructive guide for learning about how to build iterators.  A nice side benefit of posting code in the docs is that I was free to change, improve, or remove the recipes over time (the contrasts with real additions to the standard library which are hard to change once they are released).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:50:36 2011
From: report at bugs.python.org (Martin Pool)
Date: Thu, 22 Dec 2011 01:50:36 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <4EF2893E.1000403@haypocalc.com>
Message-ID: <CAA9uavB66=DuLwwfY_69=FfaU9dRo453v8pLnft78pn79A7s4g@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 22 December 2011 12:32, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> On 22/12/2011 02:16, Martin Pool wrote:
>> The proposal is that in some cases where Python currently assumes
>> filenames are ascii on Linux, it ought to instead assume they are
>> utf-8.
>
> Oh, I expected a use case describing the problem, not the proposed
> solution :-)

The problem as I see it is this:

On Linux, filenames are generally (but not always) in UTF-8; people
fairly commonly end up with no locale configured, which causes Python
to decode filenames as ascii.  It is easy for this to end up with them
hitting UnicodeErrors.

>>> You want to use UTF-8 instead of ASCII, so what? What do you
>>> want to do with your nicely well decoded filenames? You cannot print it
>>> to your terminal nor pass it to a subprocess, because your terminal uses
>>> ASCII, as subprocess. I don't see how it would help you.
>>
>> When the application has a unicode string,
>
> Where does this string come from? (It is an important question).

It comes, for example, from the name of a file, or a directory, or the
contents of a symlink.  Or the problem applies equally when the
program has got a unicode string (for example off the network in a
defined encoding) and it is trying to use it to access the filesystem.

> If your locale encoding is ASCII, you cannot write such non-ASCII
> filenames using the keyboard for example.

Sure you can.  The user could enter a backslash-escaped name, which
the program knows to decode to unicode.  The point is the program has
a choice of how it deals with user input, whereas it does not have as
much control in Python of how filenames are encoded.

> ?> with working around this when the filenames really are
> ?> valid in what should be the user's locale,
>
> On your computer, UTF-8 is maybe a good candidate for "what should be
> the user's locale", but you cannot generalize for all computers.
>
> I also wanted to force UTF-8 everywhere, but you cannot do that or your
> program will just not work in some configurations.

Just to be clear, I'm not proposing to force UTF-8 everywhere.  I am
only proposing to 'break' the case where the user has non-ascii
filenames but, intentionally or not, a locale that specifies only
ascii is used.  With this change, Python will try to decode them as
utf-8, and fail if they're not utf-8.

I am coming to think the best step here is just for the OS to do more
to make sure the application does get the appropriate locale.  (For
example, Ubuntu in recent releases uses a pam hook to set LANG for
cron jobs, to avoid the example described above.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 03:15:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Dec 2011 02:15:56 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <CAA9uavB66=DuLwwfY_69=FfaU9dRo453v8pLnft78pn79A7s4g@mail.gmail.com>
Message-ID: <4EF2935A.8080502@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The problem as I see it is this:
>
> On Linux, filenames are generally (but not always) in UTF-8; people
> fairly commonly end up with no locale configured, which causes Python
> to decode filenames as ascii.  It is easy for this to end up with them
> hitting UnicodeErrors.

I don't think that your problem is decoding, but encoding filenames.

>> Where does this string come from? (It is an important question).
>
> It comes, for example, from the name of a file, or a directory, or the
> contents of a symlink.

For all these cases, Python is able to decode them (but store 
undecodable bytes as surrogates, PEP 383).

> Or the problem applies equally when the
> program has got a unicode string (for example off the network in a
> defined encoding) and it is trying to use it to access the filesystem.

Hum, you can have the problem if you try to decompress a ZIP containing 
a Unicode filename. ZIP stores filenames are cp437 or UTF-8 depending on 
a flag (well, it's not exact: some buggy tools store filenames as a 
different encoding, the Windows ANSI code page...). If you try to 
decompress a ZIP containg non-ASCII filenames stored as UTF-8, whereas 
your locale encoding is ASCII, you will get a UnicodeEncodeError.

I would suggest to fix your environment: if you want to play with 
non-ASCII filenames, you should first fix your locale. Or other programs 
will also fail because of your locale.

(There is maybe something to do in the ZIP module to allow to create 
file names using the original raw bytes filename. See also issues #10614 
and #10972.)

>> If your locale encoding is ASCII, you cannot write such non-ASCII
>> filenames using the keyboard for example.
>
> Sure you can.  The user could enter a backslash-escaped name, which
> the program knows to decode to unicode.

How exactly? Users do usually not write backslash-escaped name. Users 
prefer to click on icons :-)

 > with user input, whereas it does not have as
> much control in Python of how filenames are encoded.

Ah? The application *can* control how filenames are encoded. Example:

Create a UTF-8 filename with a UTF-8 locale encoding.

$ python3
Python 3.2.1 (default, Jul 11 2011, 18:54:42)
 >>> import locale; print(locale.getpreferredencoding())
UTF-8
 >>> f=open("h?.txt", "w"); f.write("unicode!"); f.close()

Read the file content, even if the locale encoding is ASCII.

$ LANG=C python3
Python 3.2.1 (default, Jul 11 2011, 18:54:42)
 >>> import locale; print(locale.getpreferredencoding())
ANSI_X3.4-1968
 >>> f=open("h\xe9.txt", "r"); print(f.read()); f.close()
Traceback (most recent call last):
   ...
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in 
position 1: ordinal not in range(128)
 >>> f=open("h\xe9.txt".encode("utf-8"), "r"); print(f.read()); f.close()
unicode!

You cannot pass directly "h\xe9.txt", but if you know the "correct" file 
system encoding, you can encode it explicitly using str.encode("utf-8").

You are trying to do something complex (add hacks for filenames, for a 
specific configuration) for a simple problem: configure correctly 
locales. If you know and you are sure that your are using UTF-8, why not 
simply setting your locale to a UTF-8 locale?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 03:32:20 2011
From: report at bugs.python.org (Martin Pool)
Date: Thu, 22 Dec 2011 02:32:20 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <4EF2935A.8080502@haypocalc.com>
Message-ID: <CAA9uavBNuUTt=TEHnxd-JOfZ1C6tO5Adt3DxyixnkEfC5VzFhA@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 22 December 2011 13:15, STINNER Victor <report at bugs.python.org> wrote:
> You cannot pass directly "h\xe9.txt", but if you know the "correct" file system encoding, you can encode it explicitly using str.encode("utf-8").

My recollection was that there were some cases where you couldn't do
this, but perhaps I was wrong or perhaps they're all fixed in
python3.x, or at least perhaps they are better fixed as individual
bugs.  gz may know more.

> You are trying to do something complex (add hacks for filenames, for a specific configuration) for a simple problem: configure correctly locales.

I think you may be right.

> If you know and you are sure that your are using UTF-8, why not
> simply setting your locale to a UTF-8 locale?

_My_ locale is set properly.  The problem is all the other people in
the world who do not have their locale set to match their files on
disk; telling them each to fix it is tedious.  But perhaps the OS is
the best place to address that, when the incorrect locale is just
accidental not unavoidable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 05:05:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Dec 2011 04:05:35 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324526735.87.0.33078398812.issue13643@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

> _My_ locale is set properly.  The problem is all the other
> people in the world who do not have their locale set to match
> their files on disk; telling them each to fix it is tedious.
> But perhaps the OS is the best place to address that, when the
> incorrect locale is just accidental not unavoidable.

I fixed my locale back before my OS fully supported doing so.
It was painful, but it was *so* worth it.  There were many
tools that just worked better after I did that, and several
tools that I had to convince to use utf-8 through non-standard
means.

So I think Python is doing the right thing by using the locale
(the Standard Way), and that getting the OS vendors and/or
the users to fix their locale settings is indeed the right place
to fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 05:07:12 2011
From: report at bugs.python.org (th9)
Date: Thu, 22 Dec 2011 04:07:12 +0000
Subject: [issue13553] Tkinter doesn't set proper application name
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1324526832.76.0.959749835254.issue13553@psf.upfronthosting.co.za>


th9 <rei4dan at gmail.com> added the comment:

No, it apears as "Toplevel".

I'm not sure if the program.desktop file has something to do with that, but I didn't manage to get the application name from a desktop file to get used for Tkinter program. And I don't have any Tkinter or Tk app which would do what I'm trying to do.

For example, Firefox shows up as "Mozilla Firefox", but I don't see any X property with that value for Firefox window.. it might be something Mutter is doing.

Here is xprop for IDLE and Firefox:
$ sleep 5; xprop 
XKLAVIER_STATE(INTEGER) = 0, 0
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 23, 2
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
_NET_WM_STATE(ATOM) = 
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 1 by 1
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
_NET_WM_ICON_NAME(UTF8_STRING) = "Python Shell"
WM_ICON_NAME(STRING) = "Python Shell"
_NET_WM_NAME(UTF8_STRING) = "Python Shell"
WM_NAME(STRING) = "Python Shell"
WM_CLASS(STRING) = "42772672", "Toplevel"

$ sleep 5; xprop 
XKLAVIER_STATE(INTEGER) = 0, 0
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 24, 0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x1600094
		bitmap id # of mask for icon: 0x1600095
		window id # of group leader: 0x1600001
_NET_STARTUP_ID(UTF8_STRING) = "gnome-shell-17731-RD-OC-firefox-10_TIME71936264"
WM_WINDOW_ROLE(STRING) = "browser"
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
_NET_WM_ICON(CARDINAL) = 	Icon (16 x 16):
	 ?   ??????     
	 ??????  ????   
	???????  ?????  
	??????????????? 
	????????????? ??
	????????????? ??
	????????????? ??
	????????????? ??
	????????????? ??
	????????????????
	 ???????????????
	 ?????????????? 
	  ????????????  
	   ???????????  
	    ?????????   
	     ??????     

	Icon (32 x 32):
	            ?????????           
	          ????     ????         
	        ????         ????       
	    ?  ????           ?????     
	   ???????????        ??????    
	   ???????????       ????? ??   
	   ???????????     ???????? ??  
	  ???????????       ??????  ??? 
	  ??????????????     ?????  ??? 
	 ??????????????????????????   ? 
	 ???????????? ?????????????   ??
	 ???????????????????????????  ??
	 ???????????????????????????  ??
	 ?????????????????????????    ??
	 ?????????????????????????    ??
	?????????????????????????? ? ???
	 ????????????????????????? ? ???
	 ????????????????? ??????? ?????
	 ???????????????????????????????
	  ????????????????????????????? 
	  ????????????????????????????? 
	  ????????????????????????????? 
	   ???????????????????????????  
	    ??????????????????????????  
	    ?????????????????????????   
	     ???????????????????????    
	      ?????????????????????     
	      ?????????????????????     
	       ????????????????????     
	        ?????????????????       
	          ?????????????         
	                                

	Icon (48 x 48):
	                  ???????????                   
	               ???????    ??????                
	             ????             ????              
	           ?????               ?????            
	          ?????                ?? ???           
	    ??  ????????                ??  ???         
	    ?? ????????????             ???? ???        
	   ????????????????            ??????  ??       
	   ???????????????             ??????   ??      
	   ???????????????          ???????? ?   ??     
	   ???????????????          ????????     ??     
	   ???????????????           ????????     ??    
	   ???????????????????         ???????  ? ?     
	   ????????????????????      ?????????   ?      
	  ????????????????????????????????????          
	  ????????????????   ??????????????????         
	 ????????????????   ???????????????????     ?   
	 ????????????????????????????????????????   ??  
	 ???????????????????????????????????? ? ??  ??? 
	 ????????????????????????????????????   ??  ??? 
	 ????????????????????????????????????    ?  ??? 
	 ????????????????????????????????????       ??? 
	 ????????????????????????????????????   ?   ??? 
	??????????????????????????????????????  ?  ???? 
	?????????????????????????????????????? ?? ????? 
	??????????????????????????????????????  ??????  
	 ?????????????????????????  ??????????  ??????  
	 ????????????????????????????????????? ???????  
	 ????????????????????????????????????????????   
	  ???????????????????????????????????????????   
	  ???????????????????????????????????????????   
	   ??????????????????????????????????????????   
	   ?????????????????????????????????????????    
	    ????????????????????????????????????????    
	    ???????????????????????????????????????     
	     ?????????????????????????????????????      
	     ?????????????????????????????????????      
	      ???????????????????????????????????       
	       ?????????????????????????????????        
	        ???????????????????????????????         
	         ?????????????????????????????          
	         ??????????????????????????????         
	         ?????????????????????????????          
	          ???????????????????????????           
	            ????????????????????????            
	              ???????????????????               
	                  ???????????                   
	                                                


_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 23068819
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1600092
WM_CLIENT_LEADER(WINDOW): window id # 0x1600001
_NET_WM_PID(CARDINAL) = 24976
WM_LOCALE_NAME(STRING) = "lv_LV.utf8"
WM_CLIENT_MACHINE(STRING) = "RD-OC"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 0 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Navigator", "Firefox"
WM_ICON_NAME(STRING) = "Issue 13553: Tkinter doesn't set proper application name - Python tracker - Mozilla Firefox"
_NET_WM_ICON_NAME(UTF8_STRING) = "Issue 13553: Tkinter doesn't set proper application name - Python tracker - Mozilla Firefox"
WM_NAME(STRING) = "Issue 13553: Tkinter doesn't set proper application name - Python tracker - Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "Issue 13553: Tkinter doesn't set proper application name - Python tracker - Mozilla Firefox"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13553>
_______________________________________

From report at bugs.python.org  Thu Dec 22 06:14:56 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Dec 2011 05:14:56 +0000
Subject: [issue13585] Add contextlib.ContextStack
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324530896.77.0.861245854028.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, adding a "Recipes" section for contextlib2 is definitely on my to-do list (along with adding more examples in general).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Thu Dec 22 07:07:03 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 22 Dec 2011 06:07:03 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1324534023.08.0.427407463404.issue9922@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

getstatusoutput() is broken given that it doesn't work on windows yet it should.

I'd also recommend leaving the behavior as is and deprecating the function (and getoutput() while we're at it).

A related bug (#10197) also recommends deprecating getstatusoutput.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Dec 22 07:18:22 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 22 Dec 2011 06:18:22 +0000
Subject: [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1324534702.68.0.506027156315.issue8093@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> "Restart Shell" command leaves pythonw.exe processes running

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8093>
_______________________________________

From report at bugs.python.org  Thu Dec 22 07:23:22 2011
From: report at bugs.python.org (Martin Panter)
Date: Thu, 22 Dec 2011 06:23:22 +0000
Subject: [issue12922] StringIO and seek()
In-Reply-To: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za>
Message-ID: <1324535002.87.0.637196210678.issue12922@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12922>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:04:50 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 22 Dec 2011 07:04:50 +0000
Subject: [issue9925] Idle doesn't launch
In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>
Message-ID: <1324537490.48.0.487122156744.issue9925@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This bug looks almost identical to issue4625 which was fixed. The only difference is the French localization aspect.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9925>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:21:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2011 07:21:09 +0000
Subject: [issue11006] warnings with subprocess and pipe2
In-Reply-To: <1295965809.48.0.183733964181.issue11006@psf.upfronthosting.co.za>
Message-ID: <E1Rdcxg-0005Cr-AJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dc913f73a7fb by Ross Lagerwall in branch '3.2':
Issue #11006: Don't issue low level warning in subprocess when pipe2() fails.
http://hg.python.org/cpython/rev/dc913f73a7fb

New changeset b1b35583967a by Ross Lagerwall in branch 'default':
Merge with 3.2 for #11006.
http://hg.python.org/cpython/rev/b1b35583967a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11006>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:22:18 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 22 Dec 2011 07:22:18 +0000
Subject: [issue13532] In IDLE,
	sys.stdout.write and sys.stderr can write any pickleable object
In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za>
Message-ID: <1324538538.34.0.890619166158.issue13532@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This bug is related to #1757057.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13532>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:39:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 07:39:25 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324494231.58.0.0608670473314.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324539522.3373.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > By default the Python SSL/TLS Stack (client/server) expose
> > unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).
> 
> If there is a problem, it should not be fixed in Python, but in the
> underlying library (OpenSSL) or in applications. Python only exposes
> features of the OpenSSL library.

The ssl module's theoretical goal is to provide access to SSL features;
that it wraps OpenSSL APIs is mostly an implementation detail, although
it is true that the APIs resemble OpenSSL's in some places.

This is where we can have different policies: OpenSSL is a low-level
library with an exhaustive (if poorly documented) API; the ssl module is
more synthetic and slightly higher-level, and likely to be used by
crypto novices. As such, we can have a different set of default ciphers.

> You should not see Python as an application but as a language: Python
> doesn't know what is your use case, or if you write a client or a
> server.

This is why I would like to stay conservative when disabling ciphers:
disable the really weak ones, but avoid being too opinionated.

> If you consider that it is too complex to change the cipher list in a
> high level API (like http.client?), we may a ssl.DEFAULT_CIPHERS to
> allow an application to change the *default* cipher list.

Changing higher-level APIs means there are more places where the change
has to be done.

> SSLContext() requires a protocol, I suppose that the protocol is also
> by OpenSSL used in the negociation of the cipher list.

There are weak ciphers even in TLS1.

> If we change the default behaviour, we should allow the user to get
> back the old behaviour (e.g. mark ssl._DEFAULT_CIPHERS as public in
> default_ciphers.patch).

set_ciphers("something") is how you change ciphers. It is a public API.
But I wouldn't expect anyone to re-enable 56-bit DES ciphers: if we are
conservative with our choice of default ciphers, nobody should have
issues with it.

> IMO this issue is more a documentation issue: we should add a warning
> in the ssl module documentation, and maybe also in the documentation
> of modules using the ssl module (as we done for certificates for
> HTTPS).

Most ssl-using modules won't give the user access to such settings.
Besides, you can't expect someone using urllib.request() to know which
ciphers should be disabled. The library (either ssl or urllib or
http.client) should choose the right defaults.

I agree about documenting it in any case. But that doesn't mean we
shouldn't *also* set a reasonable default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:45:20 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 22 Dec 2011 07:45:20 +0000
Subject: [issue11006] warnings with subprocess and pipe2
In-Reply-To: <1295965809.48.0.183733964181.issue11006@psf.upfronthosting.co.za>
Message-ID: <1324539920.11.0.452765471519.issue11006@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Removed the warnings.

Thanks.

----------
assignee:  -> rosslagerwall
nosy: +rosslagerwall
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11006>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:50:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 07:50:24 +0000
Subject: [issue12922] StringIO and seek()
In-Reply-To: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za>
Message-ID: <1324540224.22.0.251810642823.issue12922@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would rather document it in TextIOBase:
http://docs.python.org/dev/library/io.html#io.TextIOBase

With text I/O streams, tell() returns an arbitrary "position cookie", meaning you can't meaningfully do arithmetic on it: this is why cur-relative seeking and end-relative seeking isn't supported.

Of course, on StringIO the "arbitrary position cookie" is a perfectly well-defined character offset, so we *could* specifically enhance StringIO.tell. Whether it's a good idea to do it (while arbitrary text files would still have the limitation) is left to debate.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
type: enhancement -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12922>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:44:18 2011
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 22 Dec 2011 08:44:18 +0000
Subject: [issue7883] CallTips.py _find_constructor does not work
In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za>
Message-ID: <1324543458.56.0.321083350591.issue7883@psf.upfronthosting.co.za>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

Attached is Lib/test/test_idlelib.py, containing a unit test for the issue.

----------
Added file: http://bugs.python.org/file24075/test_idlelib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7883>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:47:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 08:47:13 +0000
Subject: [issue13585] Add contextlib.ContextStack
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324543633.39.0.305509262673.issue13585@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>     with ContextStack() as stack:
>         files = [stack.enter_context(open(fname)) for fname in filenames]

I find this a bit distasteful. Cleaning up resources now needs something called a "ContextStack" and an "enter_context" method call. There's a bit too much terminology, and it looks like a poor man's equivalent of Go's "defer" statement:
http://blog.golang.org/2010/08/defer-panic-and-recover.html

I like unittest's addCleanup mechanism better.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:50:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 08:50:20 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324543820.19.0.420245668893.issue13636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, here are the default ciphers in our Windows OpenSSL build:

Z:\openssl-1.0.0a>out64\openssl.exe ciphers -v
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1 export
EXP-DES-CBC-SHA         SSLv3 Kx=RSA(512) Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-RC2-CBC-MD5         SSLv3 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:04:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2011 09:04:22 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <E1RdeZY-00041h-MQ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 33dea851f918 by Antoine Pitrou in branch 'default':
Issue #13626: Add support for SSL Diffie-Hellman key exchange, through the
http://hg.python.org/cpython/rev/33dea851f918

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:05:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 09:05:36 +0000
Subject: [issue13626] Python SSL stack doesn't support DH ciphers
In-Reply-To: <1324213627.05.0.342479471062.issue13626@psf.upfronthosting.co.za>
Message-ID: <1324544736.55.0.714265422609.issue13626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you Meador. I've committed an updated patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13626>
_______________________________________

From report at bugs.python.org  Thu Dec 22 11:10:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 10:10:19 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1324548619.65.0.0436475978737.issue8604@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm not sure about the best module to host this, though: os.path ?

os.path is mostly about path manipulation functions, although it also performs directory I/O (e.g. realpath()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu Dec 22 11:44:32 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 22 Dec 2011 10:44:32 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324550672.09.0.982103535628.issue5689@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

This failure seems to crop up often, but not on every run:

  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3941/steps/test/logs/stdio
  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3940/steps/test/logs/stdio
  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3937/steps/test/logs/stdio
  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3929/steps/test/logs/stdio
  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3921/steps/test/logs/stdio
  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3916/steps/test/logs/stdio
  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3914/steps/test/logs/stdio
  http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3906/steps/test/logs/stdio

I've been able to reproduce the failure on my own XP machine;
I'll investigate it over the weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Thu Dec 22 11:45:03 2011
From: report at bugs.python.org (akira)
Date: Thu, 22 Dec 2011 10:45:03 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324550703.1.0.814143486173.issue13643@psf.upfronthosting.co.za>


Changes by akira <4kir4.1i at gmail.com>:


----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Thu Dec 22 11:51:07 2011
From: report at bugs.python.org (naif)
Date: Thu, 22 Dec 2011 10:51:07 +0000
Subject: [issue13636] Python SSL Stack doesn't have a Secure Default set of
	ciphers
In-Reply-To: <1324292408.0.0.0336711576939.issue13636@psf.upfronthosting.co.za>
Message-ID: <1324551067.4.0.411551629216.issue13636@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Regarding the mainteneance i expect that, if we make a future-proof choice, it would take at least 5 years before that someone will need to have other ciphers added.

Consider that a new cipher is standardized once every X year, and typically, if it get diffused/adopted (and not abbandoned or marginally used), it will happen in few other years.

The new ciphers will get into OpenSSL, so the proposed approach to:
- Start from default
- Disable anything that's
  - Unsecure/Weak
  - Not used/widely used

Would still means that, when OpenSSL library will add a new cipher because a new RFC will get out, for sure it will not be unsecure/weak. There are chance that it will not get used/widely used, in that case in some other year, we'll update the default disabled ciphers.

But such approach would provide very "low maintenance" because "not doing anything" can only create a situation where "more ciphers" get added by default (included in newer OpenSSL / new TLS RFC).

But those new ciphers will not be weak, even if not maintained.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13636>
_______________________________________

From report at bugs.python.org  Thu Dec 22 11:51:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Dec 2011 10:51:27 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1324551087.71.0.326534828348.issue8604@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I prefer to write a "best-effort" function

I disagree. People who explicitely use an atomic file API want atomicity/persistency, otherwise they wouldn't use it. Exposing a function that may, or may not, be atomic is just plain wrong.
IMHO, the right thing to do on OSes that don't provide atomic rename (and I doubt there are many of them, see below) is to raise an exception, so that the user can fall back to whatever he thinks is best (bail out, rollback, etc).

> and so I consider that shutil is the best place for such function.

As noted by Jean-Paul, shutil stands for "shell utils": that would be a rather poor choice: atomicfile fits in shutil as much as tempfile would :-)

> Some OS don't provide atomic rename.

Which one?
See Antoine's message:
http://bugs.python.org/issue8828#msg146274

Apparently, Windows >= XP does have an atomic rename(), and every POSIX compliant OS rename(2) should be atomic.

> os.path is mostly about path manipulation functions

I agree.
I wish we had something like:
io.file
io.file.tempfile
io.file.path
io.file.atomicfile

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu Dec 22 11:54:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 10:54:25 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324551265.07.0.951134169827.issue5689@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps Paul can try to reproduce and diagnose the issue directly on the buildbot?

----------
nosy: +pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Thu Dec 22 12:51:57 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 22 Dec 2011 11:51:57 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324554717.4.0.268457044711.issue13644@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Well, I expect Python 3 to raise RuntimeError about recursion not to segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:01:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Dec 2011 12:01:55 +0000
Subject: [issue13585] Add contextlib.ContextStack
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324555315.05.0.320576908511.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

ContextStack is intended to be a building block that makes it easy to compose context managers and other callbacks, not necessarily an API you'd regularly use directly. For example, given ContextStack (as currently implemented in contextlib2), it's trivial to write your own higher level cleanup API:

    @contextmanager
    def cleanup(cb=None, *args, **kwds):
        with ContextStack() as stack:
            if cb is not None:
                stack.register(cb, *args, **kwds):
            yield stack

If you only have one callback, you could supply it directly as an argument to cleanup(), otherwise you could make multiple register() calls on the returned stack object.

The idea is to implement the necessary __exit__() logic that makes it feasible to compose context managers and other callbacks just once, then let people explore the possibilities in terms of the higher level APIs that it makes easy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:02:37 2011
From: report at bugs.python.org (Sacha Brants-Menard)
Date: Thu, 22 Dec 2011 12:02:37 +0000
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1324555357.7.0.630091789635.issue10296@psf.upfronthosting.co.za>


Changes by Sacha Brants-Menard <sacha at brants.fr>:


----------
nosy: +Sacha.Brants-Menard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10296>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:11:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 12:11:29 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1324555889.68.0.0819378686084.issue9922@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, getoutput and getstatusoutput are arguably ugly.

However, since they are very high-level functions meant to quickly execute commands, returning str makes sense. You can't do anything smart with the output anyway, since stdout and stderr are intermingled: any binary data will be ruined by accompanying stderr output (e.g. warnings).

If you want to process the output data instead of displaying it to the user, use check_call() instead.

We could perhaps use the "surrogateescape" error handler in getoutput and getstatusoutput, but that's really putting lipstick on a pig.

----------
nosy: +ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:23:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Dec 2011 12:23:16 +0000
Subject: [issue13585] Add contextlib.ContextStack
In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za>
Message-ID: <1324556596.68.0.701521354797.issue13585@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The comparison to Go's defer statement is interesting, though: ContextStack.register basically *is* the same as defer. While a nested with statement is a better option in Python, if we ignore that for the moment, you *could* write that simply copying example:

    with ContextStack() as stack:
        src = open(source)
        stack.register(src.close)
        dest = open(destination, 'w')
        stack.register(dest.close)
        copy(src, dest)

However, since ContextStack is just an ordinary context manager class, you have a lot of flexibility in what you do with it (particularly once I add the preserve() API to let you deliberately *skip* the cleanup steps by transferring them to a new ContextStack object)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13585>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:04:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Dec 2011 14:04:44 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1324562684.65.0.961551640894.issue9922@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It is indeed unfortunate that these two functions weren't killed off in the Py3k transition instead of being migrated from the commands module to subprocess (their current implementation runs counter to the entire subprocess security design by implicitly invoking the shell).

Probably the most straightforward way to make them better behaved is to move them over to being based on subprocess.Popen:

def getstatusoutput(cmd):
    try:
        data = check_output(cmd, shell=True, universal_newlines=True, stderr=STDOUT)
        status = 0
    except CalledProcessError as ex:
        data = ex.output
        status = ex.returncode
    return status, data

def getoutput(cmd):
    return getstatusoutput(cmd)[1]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:34:50 2011
From: report at bugs.python.org (naif)
Date: Thu, 22 Dec 2011 14:34:50 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
Message-ID: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>


New submission from naif <naif at globaleaks.org>:

It has been noticed by the well known security researcher Dan Kaminsky (
http://dankaminsky.com/) that Python SSL binding doesn't securely validate a digital certificate while used.

There is a new "match_hostname"http://pypi.python.org/pypi/backports.ssl_match_hostname/ that doesn't implement all the required, standard SSL/TLS Client security checks that should be done.

Dan suggestion to properly implement implement default SSL/TLS Client security check is as follow:

===
Encryption without authentication offers little value; it is the canonical "secure in the absence of an attacker" state.  
Python's SSL/TLS code presently does not authenticate the connection by default.  

There are of course reasons for this:

1) Collecting and maintaining the appropriate SSL/TLS roots is difficult, assuming people are even connecting to globally trusted resources
2) Changing authentication policy silently threatens to break production apps

These are real problems that can't just be waved away.  
In the long run, a more scalable trust distribution system needs to be supported (DNSSEC, most likely) but the present state of affairs remain ugly.  

This is what I would recommend:

A) Integrate the Mozilla CA pack into Python, updating it with each security release.

B) Make certificate validation tristate.  B
y default, it merely emits to stderr an error similar to what happens if deprecated content is included.  
This is vaguely heretical but whatever.  
Then add a couple of API calls:
   a) ValidateCerts, a single call that enables the Mozilla CA pack
   b) AddCert, a single call that declares a particular cert as trusted
   c) AddRoot, a single call that declares a particular root as trusted
   d) DisableValidation, a single call that removes the error
C) Integrate a hooking mechanism to add or replace the certificate validation process.  
Please send this API the name of the host you're attempting to validate, and be sure to allow it to return "I don't know, try your normal validation procedure".

Be sure you include all the necessary checks, including:
A) Expiration
B) SAN/CN
C) Basic Constraints checking
D) Name Constraints

Possibly a future version of Python should _actually_ deprecate non-validating SSL/TLS, but certainly not a security patch.
Too high a risk of breakage.
===

It would be valuable to provide the default SSL/TLS Client verification exactly like Mozilla/Chrome/Curl/Wget does.

----------
components: Library (Lib)
messages: 150094
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't securely validate certificate (as client)
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:46:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 22 Dec 2011 14:46:54 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324565214.28.0.900519805998.issue13644@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

There is no place for it to raise a RuntimeError which will continue to propogate!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:49:17 2011
From: report at bugs.python.org (Alexey)
Date: Thu, 22 Dec 2011 14:49:17 +0000
Subject: [issue13648] xml.sax.saxutils.escape does not escapes \x00
Message-ID: <1324565357.61.0.717954397145.issue13648@psf.upfronthosting.co.za>


New submission from Alexey <animus at wayround.org>:

function xml.sax.saxutils.escape('\x00qweqwe<') returns '\x00qweqwe&lt;'

\x00 did not escaped to &#0;

is this is a correct behavior?

this is influences tools like xmpppy, which sends \x00 not encoded and leads to xmpp error.

----------
messages: 150096
nosy: Animus
priority: normal
severity: normal
status: open
title: xml.sax.saxutils.escape does not escapes \x00
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/issue13648>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:51:20 2011
From: report at bugs.python.org (Alexey)
Date: Thu, 22 Dec 2011 14:51:20 +0000
Subject: [issue13648] xml.sax.saxutils.escape does not escapes \x00
In-Reply-To: <1324565357.61.0.717954397145.issue13648@psf.upfronthosting.co.za>
Message-ID: <1324565480.72.0.987843531265.issue13648@psf.upfronthosting.co.za>


Changes by Alexey <animus at wayround.org>:


----------
components: +XML

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13648>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:55:52 2011
From: report at bugs.python.org (Alexey)
Date: Thu, 22 Dec 2011 14:55:52 +0000
Subject: [issue13648] xml.sax.saxutils.escape does not escapes \x00
In-Reply-To: <1324565357.61.0.717954397145.issue13648@psf.upfronthosting.co.za>
Message-ID: <1324565752.85.0.993041602289.issue13648@psf.upfronthosting.co.za>


Alexey <animus at wayround.org> added the comment:

sorry, xmpppy uses it's own escape method, but anyway... :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13648>
_______________________________________

From report at bugs.python.org  Thu Dec 22 16:09:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 22 Dec 2011 15:09:46 +0000
Subject: [issue13649] termios.ICANON is not documented
Message-ID: <1324566585.96.0.744911903947.issue13649@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/termios.html is missing documentation for ICANON flag used to put terminal to "raw" mode.

It is also worth to place `termios` raw/canonical mode equivalent on `tty` pages, so that people porting C code to Python could understand the hidden magic.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 150098
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: termios.ICANON is not documented
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13649>
_______________________________________

From report at bugs.python.org  Thu Dec 22 16:45:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2011 15:45:18 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <E1RdkpY-0005Np-TL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c6880edaf6f3 by Senthil Kumaran in branch '2.7':
Issue13443 - Remove the functional module examples from 2.7 (as module is
http://hg.python.org/cpython/rev/c6880edaf6f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Thu Dec 22 16:46:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 22 Dec 2011 15:46:13 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1324568773.7.0.618908219843.issue13443@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed this in 2.7.

----------
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Thu Dec 22 17:01:59 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 22 Dec 2011 16:01:59 +0000
Subject: [issue13644] Python 3 crashes (segfaults) with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324569719.38.0.617105283476.issue13644@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

With Python 2, I can inspect the error to see where it occurred using traceback. With Python 3, I'd need to use gdb.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Thu Dec 22 17:14:51 2011
From: report at bugs.python.org (tom kel)
Date: Thu, 22 Dec 2011 16:14:51 +0000
Subject: [issue13650] urllib HTTPRedirectHandler does not implement documented
	behavior
Message-ID: <1324570491.43.0.0152501255866.issue13650@psf.upfronthosting.co.za>


New submission from tom kel <tomkel01 at gmail.com>:

Python 3.2.2, 
Here is a blokck of code from the HTTPRedirectHandler:

        m = req.get_method()
        if (not (code in (301, 302, 303, 307) and m in ("GET", "HEAD")
            or code in (301, 302, 303) and m == "POST")):
            raise HTTPError(req.full_url, code, msg, headers, fp)

        # Strictly (according to RFC 2616), 301 or 302 in response to
        # a POST MUST NOT cause a redirection without confirmation
        # from the user (of urllib.request, in this case).  In practice,
        # essentially all clients do redirect in this case, so we do
        # the same.

As you can see, the documentation and the implementation are contradictory.

----------
components: Library (Lib)
messages: 150102
nosy: tom.kel
priority: normal
severity: normal
status: open
title: urllib HTTPRedirectHandler does not implement documented behavior
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13650>
_______________________________________

From report at bugs.python.org  Thu Dec 22 17:25:19 2011
From: report at bugs.python.org (tom kel)
Date: Thu, 22 Dec 2011 16:25:19 +0000
Subject: [issue13650] urllib HTTPRedirectHandler does not implement documented
	behavior
In-Reply-To: <1324570491.43.0.0152501255866.issue13650@psf.upfronthosting.co.za>
Message-ID: <1324571119.97.0.942697146266.issue13650@psf.upfronthosting.co.za>


Changes by tom kel <tomkel01 at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13650>
_______________________________________

From report at bugs.python.org  Thu Dec 22 19:09:39 2011
From: report at bugs.python.org (tom kel)
Date: Thu, 22 Dec 2011 18:09:39 +0000
Subject: [issue13651] Improve redirection in urllib
Message-ID: <1324577379.51.0.5468672041.issue13651@psf.upfronthosting.co.za>


New submission from tom kel <tomkel01 at gmail.com>:

refer to patch for improvements

----------
components: Library (Lib)
files: http-redirect-3.2.diff
keywords: patch
messages: 150103
nosy: tom.kel
priority: normal
severity: normal
status: open
title: Improve redirection in urllib
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24076/http-redirect-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13651>
_______________________________________

From report at bugs.python.org  Thu Dec 22 19:11:38 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 22 Dec 2011 18:11:38 +0000
Subject: [issue13651] Improve redirection in urllib
In-Reply-To: <1324577379.51.0.5468672041.issue13651@psf.upfronthosting.co.za>
Message-ID: <1324577498.03.0.15607828109.issue13651@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Can you explain the patch and state why you would like that change included?

This would require a test.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13651>
_______________________________________

From report at bugs.python.org  Thu Dec 22 19:41:26 2011
From: report at bugs.python.org (tom kel)
Date: Thu, 22 Dec 2011 18:41:26 +0000
Subject: [issue13651] Improve redirection in urllib
In-Reply-To: <1324577379.51.0.5468672041.issue13651@psf.upfronthosting.co.za>
Message-ID: <1324579286.85.0.696694544221.issue13651@psf.upfronthosting.co.za>


tom kel <tomkel01 at gmail.com> added the comment:

I created this patch to further the functionality of redirection using the "location" header in the HTTPRedirectHandler class under urllib/request.py

Currently, the method http_error_302, which will handle code 302 redirection will parse the location header and build a Request accordingly. I encountered a website that only returned "index.php" as the Location header. When http_error_302 called on urlparse, it returned the following tuple: ParseResult(scheme='', netloc='', path='index.php', params='', query='', fragment='')

Then, http_error_302 will check if the scheme is equal to either http, https, or ftp. This is the part I changed in the patch. If it does not pass, an exception is thrown.

Afterwards, http_error_302 builds the target url. As long as the url passes the scheme check, the program will succeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13651>
_______________________________________

From report at bugs.python.org  Thu Dec 22 20:19:26 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 22 Dec 2011 19:19:26 +0000
Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux
In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za>
Message-ID: <1324581566.65.0.530937507434.issue5492@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The attached patch fixes the problem. The close method does not need to wait for poll_subprocess rescheduling to stop. The subprocess will be killed, which would cause the socket to timeout. With closing=True, poll_subprocess will return and not reschedule.

----------
keywords: +patch
Added file: http://bugs.python.org/file24077/issue5492.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5492>
_______________________________________

From report at bugs.python.org  Thu Dec 22 21:25:27 2011
From: report at bugs.python.org (WIl Hall)
Date: Thu, 22 Dec 2011 20:25:27 +0000
Subject: [issue13652] Creating lambda functions in a loop has unexpected
	results when resolving variables used as arguments
Message-ID: <1324585527.74.0.405253692661.issue13652@psf.upfronthosting.co.za>


New submission from WIl Hall <wil at wilhall.com>:

When creating lambda functions in a loop, variables involved in the lambda statements appear to not resolve until the loop finishes. This results in all of the defined lambda functions using the same variable to resolve to the last value of that variable.

For example, in my test program attached, I loop through a list of words: ["one", "two", "three", "four"] and create a function for each word, I.e: lambda: print_word(word). This results in every function having the word "four" as their argument. This doesn't seem like intended behavior.

Im my example program attached, I demonstrate both the intended and not intended behavior - creating the lambda functions in another function, versus creating them in a loop.

----------
components: Interpreter Core
files: lambda_tests.py
messages: 150107
nosy: wilhall
priority: normal
severity: normal
status: open
title: Creating lambda functions in a loop has unexpected results when resolving variables used as arguments
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file24078/lambda_tests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13652>
_______________________________________

From report at bugs.python.org  Thu Dec 22 21:49:43 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 22 Dec 2011 20:49:43 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1324586983.72.0.511673370388.issue13592@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I'm just adding this to the regex module and I've come up against a possible issue. The regex module supports named lists, which could be very big. Should the entire contents of those lists also be shown in the repr?They would have to be if the repr is to be a eval-able.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Thu Dec 22 21:59:59 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 22 Dec 2011 20:59:59 +0000
Subject: [issue13652] Creating lambda functions in a loop has unexpected
	results when resolving variables used as arguments
In-Reply-To: <1324585527.74.0.405253692661.issue13652@psf.upfronthosting.co.za>
Message-ID: <1324587599.84.0.834430342924.issue13652@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

That's not a bug.

This might help to explain what's going on:

What do (lambda) function closures capture in Python?
http://stackoverflow.com/questions/2295290/what-do-lambda-function-closures-capture-in-python

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13652>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:03:17 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 22 Dec 2011 21:03:17 +0000
Subject: [issue13652] Creating lambda functions in a loop has unexpected
	results when resolving variables used as arguments
In-Reply-To: <1324585527.74.0.405253692661.issue13652@psf.upfronthosting.co.za>
Message-ID: <1324587797.09.0.705516200558.issue13652@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13652>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:04:23 2011
From: report at bugs.python.org (WIl Hall)
Date: Thu, 22 Dec 2011 21:04:23 +0000
Subject: [issue13652] Creating lambda functions in a loop has unexpected
	results when resolving variables used as arguments
In-Reply-To: <1324585527.74.0.405253692661.issue13652@psf.upfronthosting.co.za>
Message-ID: <1324587863.92.0.934988810602.issue13652@psf.upfronthosting.co.za>


WIl Hall <wil at wilhall.com> added the comment:

Makes sense. Misunderstanding on my part, then. Closing as invalid (not a bug).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13652>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:12:21 2011
From: report at bugs.python.org (Paul Moore)
Date: Thu, 22 Dec 2011 21:12:21 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324588341.48.0.743143668903.issue5689@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

A simple rebuild and test run of that test in debug mode didn't fail...

I'll run the full test suite as a check, but that could take some time - that buildslave isn't the fastest in the world...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:20:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 21:20:09 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1324586983.72.0.511673370388.issue13592@psf.upfronthosting.co.za>
Message-ID: <1324588766.3331.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm just adding this to the regex module and I've come up against a
> possible issue. The regex module supports named lists, which could be
> very big. Should the entire contents of those lists also be shown in
> the repr?They would have to be if the repr is to be a eval-able.

I don't see how eval()able repr is a big deal. Most reprs aren't, and I
think a readable and informative representation is the real goal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:44:28 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Dec 2011 21:44:28 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1324590268.96.0.887950865535.issue13592@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

"I don't see how eval()able repr is a big deal. Most reprs aren't, ..."

Sometimes, I wonder if we're even talking about the same programming language.  Historically, a good deal of effort has gone into creating evalable reprs, if only because they accurately describe an object and because they teach users how to create similar objects.  

But it only takes one committer who doesn't care about evalable reprs to permanently break the pattern for everyone :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:57:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Dec 2011 21:57:24 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324591044.08.0.131179777474.issue13619@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+ encoding = locale.getpreferredencoding()

It should be locale.getpreferredencoding(False).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:57:51 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 22 Dec 2011 21:57:51 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1324591071.04.0.623493143168.issue13592@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Raymond, Antoine: I don't see your claims as contradictory, it's definitely true that the Python standardlib has historically tried to keep reprs as being eval-able, I think Antoine's correct that the vast majority of 3rd-party code does not keep with that trend.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Thu Dec 22 23:01:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Dec 2011 22:01:00 +0000
Subject: [issue13078] IDLE: Python Crashes When Saving Or Opening
In-Reply-To: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za>
Message-ID: <1324591260.84.0.781508867074.issue13078@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Python Crashes When Saving Or Opening -> IDLE: Python Crashes When Saving Or Opening

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13078>
_______________________________________

From report at bugs.python.org  Thu Dec 22 23:08:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 22:08:29 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1324590268.96.0.887950865535.issue13592@psf.upfronthosting.co.za>
Message-ID: <1324591666.3331.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But it only takes one committer who doesn't care about evalable reprs
> to permanently break the pattern for everyone :-(

So 95% of our datatypes were committed by a single person? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13592>
_______________________________________

From report at bugs.python.org  Thu Dec 22 23:41:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Dec 2011 22:41:00 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1324218130.95.0.816609152062.issue13555@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2LY6fncukVuO9r+LaZTpZPBnhE+aMfO5Ot8GrDRzR+sg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a new version with a test (untested).
Note that I'm absolutely not sure that the 'memsize' argument to
bigmemtest is correct.

----------
Added file: http://bugs.python.org/file24079/pickle_overflow-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/pickletester.py b/Lib/test/pickletester.py
--- a/Lib/test/pickletester.py
+++ b/Lib/test/pickletester.py
@@ -6,7 +6,8 @@
 import pickletools
 import copy_reg
 
-from test.test_support import TestFailed, have_unicode, TESTFN
+from test.test_support import (TestFailed, have_unicode, TESTFN, _2G,
+                               precisionbigmemtest)
 
 # Tests that try a number of pickle protocols should have a
 #     for proto in protocols:
@@ -14,6 +15,8 @@
 assert pickle.HIGHEST_PROTOCOL == cPickle.HIGHEST_PROTOCOL == 2
 protocols = range(pickle.HIGHEST_PROTOCOL + 1)
 
+ascii_char_size = 1
+
 # Copy of test.test_support.run_with_locale. This is needed to support Python
 # 2.4, which didn't include it. This is all to support test_xpickle, which
 # bounces pickled objects through older Python versions to test backwards
@@ -1280,3 +1283,21 @@
         f.write(pickled2)
         f.seek(0)
         self.assertEqual(unpickler.load(), data2)
+
+class BigmemPickleTests(unittest.TestCase):
+
+    # All protocols use 1-byte per printable ASCII character; we add another
+    # byte because the encoded form has to be copied into the internal buffer.
+
+    @precisionbigmemtest(size=_2G, memuse=3 + ascii_char_size)
+    def test_huge_str_32b(self, size):
+        data = "abcd" * (size // 4)
+        try:
+            for proto in protocols:
+                try:
+                    pickled = self.dumps(data, proto)
+                    self.loads(pickled)
+                finally:
+                    pickled = None
+        finally:
+            data = None
diff --git a/Lib/test/test_cpickle.py b/Lib/test/test_cpickle.py
--- a/Lib/test/test_cpickle.py
+++ b/Lib/test/test_cpickle.py
@@ -1,7 +1,9 @@
 import cPickle, unittest
 from cStringIO import StringIO
-from test.pickletester import AbstractPickleTests, AbstractPickleModuleTests
-from test.pickletester import AbstractPicklerUnpicklerObjectTests
+from test.pickletester import (AbstractPickleTests,
+                               AbstractPickleModuleTests,
+                               AbstractPicklerUnpicklerObjectTests,
+                               BigmemPickleTests)
 from test import test_support
 
 class cPickleTests(AbstractPickleTests, AbstractPickleModuleTests):
@@ -101,6 +103,16 @@
     pickler_class = cPickle.Pickler
     unpickler_class = cPickle.Unpickler
 
+class cPickleBigmemPickleTests(BigmemPickleTests):
+
+    def dumps(self, arg, proto=0, fast=0):
+        # Ignore fast
+        return cPickle.dumps(arg, proto)
+
+    def loads(self, buf):
+        # Ignore fast
+        return cPickle.loads(buf)
+
 
 class Node(object):
     pass
@@ -133,6 +145,7 @@
         cPickleFastPicklerTests,
         cPickleDeepRecursive,
         cPicklePicklerUnpicklerObjectTests,
+        cPickleBigmemPickleTests,
     )
 
 if __name__ == "__main__":
diff --git a/Lib/test/test_pickle.py b/Lib/test/test_pickle.py
--- a/Lib/test/test_pickle.py
+++ b/Lib/test/test_pickle.py
@@ -3,10 +3,11 @@
 
 from test import test_support
 
-from test.pickletester import AbstractPickleTests
-from test.pickletester import AbstractPickleModuleTests
-from test.pickletester import AbstractPersistentPicklerTests
-from test.pickletester import AbstractPicklerUnpicklerObjectTests
+from test.pickletester import (AbstractPickleTests,
+                               AbstractPickleModuleTests,
+                               AbstractPersistentPicklerTests,
+                               AbstractPicklerUnpicklerObjectTests,
+                               BigmemPickleTests)
 
 class PickleTests(AbstractPickleTests, AbstractPickleModuleTests):
 
@@ -66,6 +67,16 @@
     pickler_class = pickle.Pickler
     unpickler_class = pickle.Unpickler
 
+class PickleBigmemPickleTests(BigmemPickleTests):
+
+    def dumps(self, arg, proto=0, fast=0):
+        # Ignore fast
+        return pickle.dumps(arg, proto)
+
+    def loads(self, buf):
+        # Ignore fast
+        return pickle.loads(buf)
+
 
 def test_main():
     test_support.run_unittest(
@@ -73,6 +84,7 @@
         PicklerTests,
         PersPicklerTests,
         PicklerUnpicklerObjectTests,
+        PickleBigmemPickleTests,
     )
     test_support.run_doctest(pickle)
 
diff --git a/Modules/cPickle.c b/Modules/cPickle.c
--- a/Modules/cPickle.c
+++ b/Modules/cPickle.c
@@ -139,15 +139,15 @@
 
 typedef struct {
     PyObject_HEAD
-    int length;         /* number of initial slots in data currently used */
-    int size;           /* number of slots in data allocated */
+    Py_ssize_t length;  /* number of initial slots in data currently used */
+    Py_ssize_t size;    /* number of slots in data allocated */
     PyObject **data;
 } Pdata;
 
 static void
 Pdata_dealloc(Pdata *self)
 {
-    int i;
+    Py_ssize_t i;
     PyObject **p;
 
     for (i = self->length, p = self->data; --i >= 0; p++) {
@@ -193,9 +193,9 @@
  * number of items, this is a (non-erroneous) NOP.
  */
 static int
-Pdata_clear(Pdata *self, int clearto)
+Pdata_clear(Pdata *self, Py_ssize_t clearto)
 {
-    int i;
+    Py_ssize_t i;
     PyObject **p;
 
     if (clearto < 0) return stackUnderflow();
@@ -214,18 +214,17 @@
 static int
 Pdata_grow(Pdata *self)
 {
-    int bigger;
-    size_t nbytes;
+    Py_ssize_t bigger;
+    Py_ssize_t nbytes;
+
     PyObject **tmp;
 
+    if (self->size > (PY_SSIZE_T_MAX >> 1))
+        goto nomemory;
     bigger = self->size << 1;
-    if (bigger <= 0)            /* was 0, or new value overflows */
+    if (bigger > (PY_SSIZE_T_MAX / sizeof(PyObject *)))
         goto nomemory;
-    if ((int)(size_t)bigger != bigger)
-        goto nomemory;
-    nbytes = (size_t)bigger * sizeof(PyObject *);
-    if (nbytes / sizeof(PyObject *) != (size_t)bigger)
-        goto nomemory;
+    nbytes = bigger * sizeof(PyObject *);
     tmp = realloc(self->data, nbytes);
     if (tmp == NULL)
         goto nomemory;
@@ -280,10 +279,10 @@
 
 
 static PyObject *
-Pdata_popTuple(Pdata *self, int start)
+Pdata_popTuple(Pdata *self, Py_ssize_t start)
 {
     PyObject *r;
-    int i, j, l;
+    Py_ssize_t i, j, l;
 
     l = self->length-start;
     r = PyTuple_New(l);
@@ -297,10 +296,10 @@
 }
 
 static PyObject *
-Pdata_popList(Pdata *self, int start)
+Pdata_popList(Pdata *self, Py_ssize_t start)
 {
     PyObject *r;
-    int i, j, l;
+    Py_ssize_t i, j, l;
 
     l=self->length-start;
     if (!( r=PyList_New(l)))  return NULL;
@@ -347,9 +346,9 @@
     int bin;
 
     int fast; /* Fast mode doesn't save in memo, don't use if circ ref */
-    int (*write_func)(struct Picklerobject *, const char *, Py_ssize_t);
+    Py_ssize_t (*write_func)(struct Picklerobject *, const char *, Py_ssize_t);
     char *write_buf;
-    int buf_size;
+    Py_ssize_t buf_size;
     PyObject *dispatch_table;
     int fast_container; /* count nested container dumps */
     PyObject *fast_memo;
@@ -373,12 +372,12 @@
     PyObject *mark;
     PyObject *pers_func;
     PyObject *last_string;
-    int *marks;
-    int num_marks;
-    int marks_size;
+    Py_ssize_t *marks;
+    Py_ssize_t num_marks;
+    Py_ssize_t marks_size;
     Py_ssize_t (*read_func)(struct Unpicklerobject *, char **, Py_ssize_t);
     Py_ssize_t (*readline_func)(struct Unpicklerobject *, char **);
-    int buf_size;
+    Py_ssize_t buf_size;
     char *buf;
     PyObject *find_class;
 } Unpicklerobject;
@@ -424,7 +423,7 @@
     return NULL;
 }
 
-static int
+static Py_ssize_t
 write_file(Picklerobject *self, const char *s, Py_ssize_t  n)
 {
     size_t nbyteswritten;
@@ -433,11 +432,6 @@
         return 0;
     }
 
-    if (n > INT_MAX) {
-        /* String too large */
-        return -1;
-    }
-
     PyFile_IncUseCount((PyFileObject *)self->file);
     Py_BEGIN_ALLOW_THREADS
     nbyteswritten = fwrite(s, sizeof(char), n, self->fp);
@@ -448,10 +442,10 @@
         return -1;
     }
 
-    return (int)n;
+    return n;
 }
 
-static int
+static Py_ssize_t
 write_cStringIO(Picklerobject *self, const char *s, Py_ssize_t  n)
 {
     if (s == NULL) {
@@ -462,26 +456,21 @@
         return -1;
     }
 
-    return (int)n;
+    return n;
 }
 
-static int
+static Py_ssize_t
 write_none(Picklerobject *self, const char *s, Py_ssize_t  n)
 {
     if (s == NULL) return 0;
-    if (n > INT_MAX) return -1;
-    return (int)n;
+    return n;
 }
 
-static int
-write_other(Picklerobject *self, const char *s, Py_ssize_t  _n)
+static Py_ssize_t
+write_other(Picklerobject *self, const char *s, Py_ssize_t  n)
 {
     PyObject *py_str = 0, *junk = 0;
-    int n;
-
-    if (_n > INT_MAX)
-        return -1;
-    n = (int)_n;
+
     if (s == NULL) {
         if (!( self->buf_size ))  return 0;
         py_str = PyString_FromStringAndSize(self->write_buf,
@@ -531,7 +520,7 @@
     size_t nbytesread;
 
     if (self->buf_size == 0) {
-        int size;
+        Py_ssize_t size;
 
         size = ((n < 32) ? 32 : n);
         if (!( self->buf = (char *)malloc(size))) {
@@ -575,7 +564,7 @@
 static Py_ssize_t
 readline_file(Unpicklerobject *self, char **s)
 {
-    int i;
+    Py_ssize_t i;
 
     if (self->buf_size == 0) {
         if (!( self->buf = (char *)malloc(40))) {
@@ -587,7 +576,7 @@
 
     i = 0;
     while (1) {
-        int bigger;
+        Py_ssize_t bigger;
         char *newbuf;
         for (; i < (self->buf_size - 1); i++) {
             if (feof(self->fp) ||
@@ -597,13 +586,13 @@
                 return i + 1;
             }
         }
-        bigger = self->buf_size << 1;
-        if (bigger <= 0) {              /* overflow */
+        if (self->buf_size < (PY_SSIZE_T_MAX >> 1)) {
             PyErr_NoMemory();
             return -1;
         }
+        bigger = self->buf_size << 1;
         newbuf = (char *)realloc(self->buf, bigger);
-        if (!newbuf)  {
+        if (newbuf == NULL)  {
             PyErr_NoMemory();
             return -1;
         }
@@ -700,7 +689,7 @@
  * The caller is responsible for free()'ing the return value.
  */
 static char *
-pystrndup(const char *s, int n)
+pystrndup(const char *s, Py_ssize_t n)
 {
     char *r = (char *)malloc(n+1);
     if (r == NULL)
@@ -715,7 +704,7 @@
 get(Picklerobject *self, PyObject *id)
 {
     PyObject *value, *mv;
-    long c_value;
+    Py_ssize_t c_value;
     char s[30];
     size_t len;
 
@@ -735,7 +724,8 @@
 
     if (!self->bin) {
         s[0] = GET;
-        PyOS_snprintf(s + 1, sizeof(s) - 1, "%ld\n", c_value);
+        PyOS_snprintf(s + 1, sizeof(s) - 1,
+                      "%" PY_FORMAT_SIZE_T "d\n", c_value);
         len = strlen(s);
     }
     else if (Pdata_Check(self->file)) {
@@ -780,8 +770,7 @@
 put2(Picklerobject *self, PyObject *ob)
 {
     char c_str[30];
-    int p;
-    size_t len;
+    Py_ssize_t len, p;
     int res = -1;
     PyObject *py_ob_id = 0, *memo_len = 0, *t = 0;
 
@@ -994,7 +983,7 @@
 {
     char c_str[32];
     long l = PyInt_AS_LONG((PyIntObject *)args);
-    int len = 0;
+    Py_ssize_t len = 0;
 
     if (!self->bin
 #if SIZEOF_LONG > 4
@@ -1201,7 +1190,7 @@
 static int
 save_string(Picklerobject *self, PyObject *args, int doput)
 {
-    int size, len;
+    Py_ssize_t size, len;
     PyObject *repr=0;
 
     if ((size = PyString_Size(args)) < 0)
@@ -1448,7 +1437,7 @@
 static int
 store_tuple_elements(Picklerobject *self, PyObject *t, int len)
 {
-    int i;
+    Py_ssize_t i;
     int res = -1;       /* guilty until proved innocent */
 
     assert(PyTuple_Size(t) == len);
@@ -1477,7 +1466,7 @@
 save_tuple(Picklerobject *self, PyObject *args)
 {
     PyObject *py_tuple_id = NULL;
-    int len, i;
+    Py_ssize_t len, i;
     int res = -1;
 
     static char tuple = TUPLE;
@@ -1690,7 +1679,7 @@
 {
     int res = -1;
     char s[3];
-    int len;
+    Py_ssize_t len;
     PyObject *iter;
 
     if (self->fast && !fast_save_enter(self, args))
@@ -1943,7 +1932,7 @@
 {
     int res = -1;
     char s[3];
-    int len;
+    Py_ssize_t len;
 
     if (self->fast && !fast_save_enter(self, args))
         goto finally;
@@ -2027,7 +2016,7 @@
 
     if ((getinitargs_func = PyObject_GetAttr(args, __getinitargs___str))) {
         PyObject *element = 0;
-        int i, len;
+        Py_ssize_t i, len;
 
         if (!( class_args =
                PyObject_Call(getinitargs_func, empty_tuple, NULL)))
@@ -2289,7 +2278,8 @@
 save_pers(Picklerobject *self, PyObject *args, PyObject *f)
 {
     PyObject *pid = 0;
-    int size, res = -1;
+    Py_ssize_t size;
+    int res = -1;
 
     static char persid = PERSID, binpersid = BINPERSID;
 
@@ -2431,7 +2421,7 @@
     if (use_newobj) {
         PyObject *cls;
         PyObject *newargtup;
-        int n, i;
+        Py_ssize_t n, i;
 
         /* Sanity checks. */
         n = PyTuple_Size(argtup);
@@ -2815,7 +2805,7 @@
 static PyObject *
 Pickle_getvalue(Picklerobject *self, PyObject *args)
 {
-    int l, i, rsize, ssize, clear=1, lm;
+    Py_ssize_t l, i, rsize, ssize, clear=1, lm;
     long ik;
     PyObject *k, *r;
     char *s, *p, *have_get;
@@ -3314,7 +3304,7 @@
     return global;
 }
 
-static int
+static Py_ssize_t
 marker(Unpicklerobject *self)
 {
     if (self->num_marks < 1) {
@@ -3345,7 +3335,8 @@
 {
     PyObject *py_int = 0;
     char *endptr, *s;
-    int len, res = -1;
+    Py_ssize_t len;
+    int res = -1;
     long l;
 
     if ((len = self->readline_func(self, &s)) < 0) return -1;
@@ -3477,7 +3468,8 @@
 {
     PyObject *l = 0;
     char *end, *s;
-    int len, res = -1;
+    Py_ssize_t len;
+    int res = -1;
 
     if ((len = self->readline_func(self, &s)) < 0) return -1;
     if (len < 2) return bad_readline();
@@ -3541,7 +3533,8 @@
 {
     PyObject *py_float = 0;
     char *endptr, *s;
-    int len, res = -1;
+    Py_ssize_t len;
+    int res = -1;
     double d;
 
     if ((len = self->readline_func(self, &s)) < 0) return -1;
@@ -3597,7 +3590,8 @@
 load_string(Unpicklerobject *self)
 {
     PyObject *str = 0;
-    int len, res = -1;
+    Py_ssize_t len;
+    int res = -1;
     char *s, *p;
 
     if ((len = self->readline_func(self, &s)) < 0) return -1;
@@ -3639,7 +3633,7 @@
 load_binstring(Unpicklerobject *self)
 {
     PyObject *py_string = 0;
-    long l;
+    Py_ssize_t l;
     char *s;
 
     if (self->read_func(self, &s, 4) < 0) return -1;
@@ -3691,20 +3685,17 @@
 load_unicode(Unpicklerobject *self)
 {
     PyObject *str = 0;
-    int len, res = -1;
+    Py_ssize_t len;
     char *s;
 
     if ((len = self->readline_func(self, &s)) < 0) return -1;
     if (len < 1) return bad_readline();
 
     if (!( str = PyUnicode_DecodeRawUnicodeEscape(s, len - 1, NULL)))
-        goto finally;
+        return -1;
 
     PDATA_PUSH(self->stack, str, -1);
     return 0;
-
-  finally:
-    return res;
 }
 #endif
 
@@ -3714,7 +3705,7 @@
 load_binunicode(Unpicklerobject *self)
 {
     PyObject *unicode;
-    long l;
+    Py_ssize_t l;
     char *s;
 
     if (self->read_func(self, &s, 4) < 0) return -1;
@@ -3745,7 +3736,7 @@
 load_tuple(Unpicklerobject *self)
 {
     PyObject *tup;
-    int i;
+    Py_ssize_t i;
 
     if ((i = marker(self)) < 0) return -1;
     if (!( tup=Pdata_popTuple(self->stack, i)))  return -1;
@@ -3798,7 +3789,7 @@
 load_list(Unpicklerobject *self)
 {
     PyObject *list = 0;
-    int i;
+    Py_ssize_t i;
 
     if ((i = marker(self)) < 0) return -1;
     if (!( list=Pdata_popList(self->stack, i)))  return -1;
@@ -3810,7 +3801,7 @@
 load_dict(Unpicklerobject *self)
 {
     PyObject *dict, *key, *value;
-    int i, j, k;
+    Py_ssize_t i, j, k;
 
     if ((i = marker(self)) < 0) return -1;
     j=self->stack->length;
@@ -3886,7 +3877,7 @@
 load_obj(Unpicklerobject *self)
 {
     PyObject *class, *tup, *obj=0;
-    int i;
+    Py_ssize_t i;
 
     if ((i = marker(self)) < 0) return -1;
     if (!( tup=Pdata_popTuple(self->stack, i+1)))  return -1;
@@ -3907,7 +3898,7 @@
 load_inst(Unpicklerobject *self)
 {
     PyObject *tup, *class=0, *obj=0, *module_name, *class_name;
-    int i, len;
+    Py_ssize_t i, len;
     char *s;
 
     if ((i = marker(self)) < 0) return -1;
@@ -3993,7 +3984,7 @@
 load_global(Unpicklerobject *self)
 {
     PyObject *class = 0, *module_name = 0, *class_name = 0;
-    int len;
+    Py_ssize_t len;
     char *s;
 
     if ((len = self->readline_func(self, &s)) < 0) return -1;
@@ -4024,7 +4015,7 @@
 load_persid(Unpicklerobject *self)
 {
     PyObject *pid = 0;
-    int len;
+    Py_ssize_t len;
     char *s;
 
     if (self->pers_func) {
@@ -4102,7 +4093,7 @@
 static int
 load_pop(Unpicklerobject *self)
 {
-    int len = self->stack->length;
+    Py_ssize_t len = self->stack->length;
 
     /* Note that we split the (pickle.py) stack into two stacks,
        an object stack and a mark stack. We have to be clever and
@@ -4127,7 +4118,7 @@
 static int
 load_pop_mark(Unpicklerobject *self)
 {
-    int i;
+    Py_ssize_t i;
 
     if ((i = marker(self)) < 0)
         return -1;
@@ -4142,7 +4133,7 @@
 load_dup(Unpicklerobject *self)
 {
     PyObject *last;
-    int len;
+    Py_ssize_t len;
 
     if ((len = self->stack->length) <= 0) return stackUnderflow();
     last=self->stack->data[len-1];
@@ -4156,7 +4147,7 @@
 load_get(Unpicklerobject *self)
 {
     PyObject *py_str = 0, *value = 0;
-    int len;
+    Py_ssize_t len;
     char *s;
     int rc;
 
@@ -4214,7 +4205,7 @@
     PyObject *py_key = 0, *value = 0;
     unsigned char c;
     char *s;
-    long key;
+    Py_ssize_t key;
     int rc;
 
     if (self->read_func(self, &s, 4) < 0) return -1;
@@ -4317,7 +4308,7 @@
 load_put(Unpicklerobject *self)
 {
     PyObject *py_str = 0, *value = 0;
-    int len, l;
+    Py_ssize_t len, l;
     char *s;
 
     if ((l = self->readline_func(self, &s)) < 0) return -1;
@@ -4337,7 +4328,7 @@
     PyObject *py_key = 0, *value = 0;
     unsigned char key;
     char *s;
-    int len;
+    Py_ssize_t len;
 
     if (self->read_func(self, &s, 1) < 0) return -1;
     if (!( (len=self->stack->length) > 0 ))  return stackUnderflow();
@@ -4356,10 +4347,10 @@
 load_long_binput(Unpicklerobject *self)
 {
     PyObject *py_key = 0, *value = 0;
-    long key;
+    Py_ssize_t key;
     unsigned char c;
     char *s;
-    int len;
+    Py_ssize_t len;
 
     if (self->read_func(self, &s, 4) < 0) return -1;
     if (!( len=self->stack->length ))  return stackUnderflow();
@@ -4382,10 +4373,10 @@
 
 
 static int
-do_append(Unpicklerobject *self, int  x)
+do_append(Unpicklerobject *self, Py_ssize_t  x)
 {
     PyObject *value = 0, *list = 0, *append_method = 0;
-    int len, i;
+    Py_ssize_t len, i;
 
     len=self->stack->length;
     if (!( len >= x && x > 0 ))  return stackUnderflow();
@@ -4451,11 +4442,11 @@
 }
 
 
-static int
-do_setitems(Unpicklerobject *self, int  x)
+static Py_ssize_t
+do_setitems(Unpicklerobject *self, Py_ssize_t x)
 {
     PyObject *value = 0, *key = 0, *dict = 0;
-    int len, i, r=0;
+    Py_ssize_t len, i, r=0;
 
     if (!( (len=self->stack->length) >= x
            && x > 0 ))  return stackUnderflow();
@@ -4496,8 +4487,8 @@
     PyObject *state, *inst, *slotstate;
     PyObject *__setstate__;
     PyObject *d_key, *d_value;
+    int res = -1;
     Py_ssize_t i;
-    int res = -1;
 
     /* Stack is ... instance, state.  We want to leave instance at
      * the stack top, possibly mutated via instance.__setstate__(state).
@@ -4596,7 +4587,7 @@
 static int
 load_mark(Unpicklerobject *self)
 {
-    int s;
+    Py_ssize_t s;
 
     /* Note that we split the (pickle.py) stack into two stacks, an
        object stack and a mark stack. Here we push a mark onto the
@@ -4981,7 +4972,7 @@
 static int
 noload_obj(Unpicklerobject *self)
 {
-    int i;
+    Py_ssize_t i;
 
     if ((i = marker(self)) < 0) return -1;
     return Pdata_clear(self->stack, i+1);
@@ -4991,7 +4982,7 @@
 static int
 noload_inst(Unpicklerobject *self)
 {
-    int i;
+    Py_ssize_t i;
     char *s;
 
     if ((i = marker(self)) < 0) return -1;
@@ -5068,7 +5059,7 @@
 static int
 noload_appends(Unpicklerobject *self)
 {
-    int i;
+    Py_ssize_t i;
     if ((i = marker(self)) < 0) return -1;
     return Pdata_clear(self->stack, i);
 }
@@ -5082,7 +5073,7 @@
 static int
 noload_setitems(Unpicklerobject *self)
 {
-    int i;
+    Py_ssize_t i;
     if ((i = marker(self)) < 0) return -1;
     return Pdata_clear(self->stack, i);
 }

From report at bugs.python.org  Thu Dec 22 23:45:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 22:45:33 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324593933.28.0.35578581684.issue13647@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There is a new "match_hostname" that doesn't implement all the 
> required, standard SSL/TLS Client security checks that should be done.

Indeed, as the name indicates, it just checks the hostname.
Please detail what the other security checks are (bonus points if you provide a patch + tests).

> It has been noticed by the well known security researcher Dan Kaminsky

What's the URL for this?

> A) Integrate the Mozilla CA pack into Python, updating it with each
> security release.

I suggest you discuss this on python-dev:
http://mail.python.org/mailman/listinfo/python-dev

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Thu Dec 22 23:48:44 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 22 Dec 2011 22:48:44 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324594124.95.0.667691170817.issue5689@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Not to worry - as I said in my previous message, I can reproduce the error
on my own XP machine.

I also noticed that running test_tarfile alone doesn't trigger the errors,
which leads me to suspect that the failure is due to some interaction with
another test getting run before test_tarfile. I'm currently trying to
determine what this test is.

I suspect that the problem is at least partially caused by the fact that
tarfile uses a default compresslevel of 9 for .tar.xz archives (rather
than the recommended value of 6). According to the man page for the xz
tool <http://manpages.ubuntu.com/manpages/lucid/man1/xz.1.html>, using a
compresslevel of 9 can result in memory usage of up to 800MB during
compression, which is a significant fraction of the bot's 2GB of RAM.
(I suppose it would be a good idea to mention this in the documentation
for the lzma module, so users won't get bitten by this...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Fri Dec 23 00:01:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Dec 2011 23:01:15 +0000
Subject: [issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64
	Snow Leopard 02 03.x"
In-Reply-To: <1323435539.17.0.162534043929.issue13565@psf.upfronthosting.co.za>
Message-ID: <1324594875.15.0.892732768011.issue13565@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Victor, could you try the attached script on FreeBSD, to see if you get ECONNREFUSED?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13565>
_______________________________________

From report at bugs.python.org  Fri Dec 23 01:43:38 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 23 Dec 2011 00:43:38 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1324601018.86.0.946058927407.issue13052@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

issue13052.patch against 3.3a0 fixes the replace dialog. It also stops "Replace All" from closing the dialog. (What other application actually does this?)

When 'Regular Expression' is not checked, the find and the replace dialogs treat the fields as raw strings. This is consistent with Terry's description of "Normal".

When checked, the find field is treated as a RE and the replace field has "expand" applied.

I think this behavior is a good compromise as it allows for the basic effect of "Extended" when 'Regular Expression' is checked.

Also, I can not reproduce the beeping issue as being exclusive to '\'. I know it's caused by "text.bell()", but the bell occurs at appropriate times based on where it's located in the code (i.e. no more search results, find-again returns previous match, etc).

----------
Added file: http://bugs.python.org/file24080/issue13052.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13052>
_______________________________________

From report at bugs.python.org  Fri Dec 23 01:46:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 00:46:59 +0000
Subject: [issue13619] Add a new codec: "locale", the current locale encoding
In-Reply-To: <1324102425.92.0.741478756596.issue13619@psf.upfronthosting.co.za>
Message-ID: <1324601219.44.0.419753594295.issue13619@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure I like this idea. I think it would be nice to see it discussed on python-dev.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13619>
_______________________________________

From report at bugs.python.org  Fri Dec 23 01:50:44 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 23 Dec 2011 00:50:44 +0000
Subject: [issue9039] IDLE and module Doc
In-Reply-To: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>
Message-ID: <1324601444.31.0.696707318517.issue9039@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Is this still an issue?

----------
nosy: +serwy
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9039>
_______________________________________

From report at bugs.python.org  Fri Dec 23 01:54:14 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Fri, 23 Dec 2011 00:54:14 +0000
Subject: [issue13653] reorder set.intersection parameters for better
	performance
Message-ID: <1324601653.94.0.248406097539.issue13653@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

In Issue3069, Arnaud Delobelle proposed support for multiple values to set.intersection() and set.union(), writing "Intersection is optimized by sorting all sets/frozensets/dicts in increasing order of size and only iterating over elements in the smallest."

Raymond Hettinger commented therein that he had just added support for multiple parameters. However, he did not pick up the proposed change in the attached patch which attempts to improve the intersection performance.

Consider the attached benchmark, which constructs an inverted index mapping a letter to the set of words which contain that letter. (Rather, to word index.) Here's the output:

## Example output:
# a has 144900 words
# j has 3035 words
# m has 62626 words
# amj takes 5.902/1000 (verify: 289)
# ajm takes 0.292/1000 (verify: 289)
# jma takes 0.132/1000 (verify: 289)


Searching set.intersection(inverted_index["j"], inverted_index["m"], inverted_index["a"]) is fully 44 times faster than searching "a", "m", "j"!

Of course, the set.intersection() supports any iterable, so would only be an optimization for when all of the inputs are set types.

BTW, my own experiments suggest that sorting isn't critical. It's more important to find the most anti-correlated set to the smallest set, and the following does that dynamically by preferentially choosing sets which are likely to not match elements of the smallest set:

def set_intersection(*input_sets):
    N = len(input_sets)
    min_index = min(range(len(input_sets)), key=lambda x: len(input_sets[x]))
    best_mismatch = (min_index+1)%N

    new_set = set()
    for element in input_sets[min_index]:
        # This failed to match last time; perhaps it's a mismatch this time?
        if element not in input_sets[best_mismatch]:
            continue

        # Scan through the other sets
        for i in range(best_mismatch+1, best_mismatch+N):
            j = i % N
            if j == min_index:
                continue
            # If the element isn't in the set then perhaps this
            # set is a better rejection test for the next input element
            if element not in input_sets[j]:
                best_mismatch = j
                break
        else:
            # The element is in all of the other sets
            new_set.add(element)
    return new_set


Using this in the benchmark gives

amj takes 0.972/1000 (verify: 289)
ajm takes 0.972/1000 (verify: 289)
jma takes 0.892/1000 (verify: 289)

which clearly shows that this Python algorithm is still 6 times faster (for the worst case) than the CPython code.

However, the simple sort solution:


def set_intersection_sorted(*input_sets):
    input_sets = sorted(input_sets, key=len)
    new_set = set()
    for element in input_sets[0]:
        if element in input_sets[1]:
            if element in input_sets[2]:
                new_set.add(element)
    return new_set

gives times of 

amj takes 0.492/1000 (verify: 289)
ajm takes 0.492/1000 (verify: 289)
jma takes 0.422/1000 (verify: 289)

no doubt because there's much less Python overhead than my experimental algorithm.

----------
components: Interpreter Core
files: set_intersection_benchmark.py
messages: 150124
nosy: dalke
priority: normal
severity: normal
status: open
title: reorder set.intersection parameters for better performance
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file24081/set_intersection_benchmark.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13653>
_______________________________________

From report at bugs.python.org  Fri Dec 23 01:56:01 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Dec 2011 00:56:01 +0000
Subject: [issue13653] reorder set.intersection parameters for better
	performance
In-Reply-To: <1324601653.94.0.248406097539.issue13653@psf.upfronthosting.co.za>
Message-ID: <1324601761.44.0.149471931473.issue13653@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/issue13653>
_______________________________________

From report at bugs.python.org  Fri Dec 23 02:23:33 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Fri, 23 Dec 2011 01:23:33 +0000
Subject: [issue13654] IDLE: Freezes and/or crash on SyntaxWarning... is used
	prior to global declaration
Message-ID: <1324603413.15.0.70120207617.issue13654@psf.upfronthosting.co.za>


New submission from Marco Scataglini <atlantide at gmx.com>:

Writing the following code in the IDLE module/scriptneditor and then running it (F5) will momentarily freeze without giving the expected warning message ("SyntaxWarning: name 'GLOBAL1' is used prior to global declaration") and it will crash all IDLE windows instances if ran multiple times after it.

------------------
start code snippet:
------------------
GLOBAL1=10

def test_chnge_val_1(a=1):
##    global GLOBAL1
    b=GLOBAL1
    print GLOBAL1, b
    global GLOBAL1
    GLOBAL1 += a
    b= 100
    print GLOBAL1, b
 

if __name__ == '__main__':
    test_chnge_val_1()
----------------
end code snippet:
----------------

The desired behavior is to not crash but run the code with output and shoot the expected message to STOUT/shell console like regular python shell would.


-----
Notes:
-----
issue_global_crash.py code-file attached.

----------
components: IDLE
files: issue_global_crash.py
messages: 150125
nosy: marco
priority: normal
severity: normal
status: open
title: IDLE: Freezes and/or crash on SyntaxWarning... is used prior to global declaration
versions: Python 2.7
Added file: http://bugs.python.org/file24082/issue_global_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13654>
_______________________________________

From report at bugs.python.org  Fri Dec 23 02:40:16 2011
From: report at bugs.python.org (Michael P. Reilly)
Date: Fri, 23 Dec 2011 01:40:16 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1324604416.88.0.643544303607.issue12463@psf.upfronthosting.co.za>


Michael P. Reilly <arcege at gmail.com> added the comment:

I'm seeing that shutdown does have a race condition just using BaseHTTPServer.HTTPServer.  See the attached simple script.  Then access http://localhost:8081.  This is using both Python 2.6.6 (r266:84292, May 22 2011, 16:47:42) on Oracle Linux Server 6.1 and Python 2.7.2+ (default, Oct 4, 2011, 20:03:08) on Ubuntu 11.10.  I have applied the socketserver.patch dated 2011-07-25 18:43, with the same result.

The problem is that shutdown() waits for the event, which is never triggered since there is no thread to set the event.  I'll see if I can come up with a patch myself later this weekend.  I suspect the same might happen with ForkingMixIn.

----------
nosy: +Arcege
versions: +Python 2.6 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24083/simple.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Fri Dec 23 03:20:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Dec 2011 02:20:01 +0000
Subject: [issue9039] IDLE and module Doc
In-Reply-To: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>
Message-ID: <1324606801.21.0.867774576084.issue9039@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9039>
_______________________________________

From report at bugs.python.org  Fri Dec 23 03:32:04 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 23 Dec 2011 02:32:04 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1324607524.87.0.53475097696.issue8313@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

http://pypi.python.org/pypi/unittest2 says 

"There are several places in unittest2 (and unittest) that call str(...) on exceptions to get the exception message. This can fail if the exception was created with non-ascii unicode. This is rare and I won't address it unless it is actually reported as a problem for someone."

It is a problem for us now that we've re-rooted all our TestCases on top of unittest2 at work. :)

The solution I'm leaning towards is monkey-patching the new traceback._some_str implementation in at unittest2 import time.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8313>
_______________________________________

From report at bugs.python.org  Fri Dec 23 03:32:50 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 23 Dec 2011 02:32:50 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1324607570.87.0.896339132339.issue8313@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

We're on python 2.6, otherwise this would be a moot point.  but you might want to include something like that in a new unittest2 backport release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8313>
_______________________________________

From report at bugs.python.org  Fri Dec 23 03:54:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 02:54:35 +0000
Subject: [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <E1RdvHF-0005jQ-9T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aef79ff1bc9b by Senthil Kumaran in branch '3.2':
Issue12798 - Update mimetypes documentation. Correct the doc section where
http://hg.python.org/cpython/rev/aef79ff1bc9b

New changeset 4b306aee21a4 by Senthil Kumaran in branch 'default':
Merge changes from 3.2
http://hg.python.org/cpython/rev/4b306aee21a4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12798>
_______________________________________

From report at bugs.python.org  Fri Dec 23 04:08:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 03:08:49 +0000
Subject: [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <E1RdvV2-0007EQ-D6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cfa3fe9d7b1f by Senthil Kumaran in branch '2.7':
porting mimetype doc changes from 3.2.
http://hg.python.org/cpython/rev/cfa3fe9d7b1f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12798>
_______________________________________

From report at bugs.python.org  Fri Dec 23 04:15:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 03:15:25 +0000
Subject: [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <E1RdvbQ-0007kh-Dj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9c19df6c8ea0 by Senthil Kumaran in branch '3.2':
News entry for Issue12798
http://hg.python.org/cpython/rev/9c19df6c8ea0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12798>
_______________________________________

From report at bugs.python.org  Fri Dec 23 04:15:35 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 23 Dec 2011 03:15:35 +0000
Subject: [issue13654] IDLE: Freezes and/or crash on SyntaxWarning... is used
	prior to global declaration
In-Reply-To: <1324603413.15.0.70120207617.issue13654@psf.upfronthosting.co.za>
Message-ID: <1324610135.12.0.137013664456.issue13654@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I ran IDLE with a console and then ran your script against the latest release. The error message is due to a bug in idle_showwarning. 

Your script works with the development version, however. This is a duplicate of issue12438 which was fixed in e9c406a53972, but not yet released.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13654>
_______________________________________

From report at bugs.python.org  Fri Dec 23 04:21:54 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 23 Dec 2011 03:21:54 +0000
Subject: [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <1324610514.24.0.428510749969.issue12798@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Updated the doc with Sandro Tosi's suggested changes in all the codelines.

----------
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12798>
_______________________________________

From report at bugs.python.org  Fri Dec 23 08:04:20 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 23 Dec 2011 07:04:20 +0000
Subject: [issue13654] IDLE: Freezes and/or crash on SyntaxWarning... is used
	prior to global declaration
In-Reply-To: <1324603413.15.0.70120207617.issue13654@psf.upfronthosting.co.za>
Message-ID: <1324623860.88.0.734305084596.issue13654@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The fix has been released in Python 3.2.2.  It will be in Python 2.7.3 when released.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IDLE problem displaying warning message

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13654>
_______________________________________

From report at bugs.python.org  Fri Dec 23 08:09:02 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 23 Dec 2011 07:09:02 +0000
Subject: [issue13653] reorder set.intersection parameters for better
	performance
In-Reply-To: <1324601653.94.0.248406097539.issue13653@psf.upfronthosting.co.za>
Message-ID: <1324624142.49.0.634809970474.issue13653@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks guys.  I'll look at this in detail when I get a chance.  Offhand, it seems like a good idea though it may rarely be of benefit.  The only downsides I see are that it overrides the user's ability to specify the application order and that it would be at odds with proposals to implement ordered sets (including a guaranteed order of application in intersection, union, difference, etc).

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13653>
_______________________________________

From report at bugs.python.org  Fri Dec 23 09:36:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 23 Dec 2011 08:36:30 +0000
Subject: [issue13648] xml.sax.saxutils.escape does not escapes \x00
In-Reply-To: <1324565357.61.0.717954397145.issue13648@psf.upfronthosting.co.za>
Message-ID: <1324629390.63.0.390028023656.issue13648@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is correct behavior. \x00 is not supported in XML: not in raw form, and not in escaped form. To transmit binary data in XML, use base64.

----------
nosy: +loewis
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13648>
_______________________________________

From report at bugs.python.org  Fri Dec 23 09:54:59 2011
From: report at bugs.python.org (Dan Kaminsky)
Date: Fri, 23 Dec 2011 08:54:59 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324630499.9.0.850229895403.issue13647@psf.upfronthosting.co.za>


Dan Kaminsky <dan at doxpara.com> added the comment:

>> There is a new "match_hostname" that doesn't implement all the 
>> required, standard SSL/TLS Client security checks that should be done.

>Indeed, as the name indicates, it just checks the hostname.
>Please detail what the other security checks are (bonus points if you >provide a patch + tests).

You need to check expiration date of the cert in question, and I suppose invocation date as well.
You need to look at each of the CNs in the subject name, as well as each of the DNSname types in the SAN extension.
You *absolutely must* make sure that each of the intermediate certificates has Basic Constraints: CA set to True.  Otherwise a certificate for foo.com can sign for bar.com (this keeps happening).
You should support the Name Constraints extension, that allows certificates to sign for a subset of names.  Nobody really uses this, because reliability is so low though.


> > It has been noticed by the well known security researcher Dan Kaminsky

> What's the URL for this?

I'll see your URL and raise you a submitted bug report with recommendations.  It seems to get better results than posting random whining on a web page somewhere :)

> > A) Integrate the Mozilla CA pack into Python, updating it with each
> > security release.

> I suggest you discuss this on python-dev:
> http://mail.python.org/mailman/listinfo/python-dev

It's an ugly dependency, I know.  X.509 suffers from a "false coherence" design, in which a couple of parties actively work to make it look like it has a coherent trust model.  The best you can do is try to borrow/leverage the work of one of those parties.

----------
nosy: +Dan.Kaminsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 10:09:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 09:09:58 +0000
Subject: [issue13294] http.server: HEAD request should not return a body
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <E1Re18X-0006PJ-DU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2c1720468dbb by Senthil Kumaran in branch '3.2':
Minor code style improvements in http.server suggested in Issue13294.
http://hg.python.org/cpython/rev/2c1720468dbb

New changeset 0466ee1816b1 by Senthil Kumaran in branch 'default':
merge from 3.2.  Minor code style improvements in http.server suggested in Issue13294.
http://hg.python.org/cpython/rev/0466ee1816b1

New changeset 1b1818fee351 by Senthil Kumaran in branch '2.7':
port to 2.7 - Minor code style improvements in http.server suggested in Issue13294.
http://hg.python.org/cpython/rev/1b1818fee351

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Fri Dec 23 10:14:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 09:14:54 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324630499.9.0.850229895403.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324631648.3388.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> You need to check expiration date of the cert in question, and I
> suppose invocation date as well.
> You need to look at each of the CNs in the subject name, as well as
> each of the DNSname types in the SAN extension.
> You *absolutely must* make sure that each of the intermediate
> certificates has Basic Constraints: CA set to True.  Otherwise a
> certificate for foo.com can sign for bar.com (this keeps happening).

I'm confident this is already done by OpenSSL (if requested by user,
which means using CERT_REQUIRED or CERT_OPTIONAL in Python's ssl module
- these map to OpenSSL's SSL_VERIFY_PEER).

I guess it would be easy to check this by providing an outdated
certificate - perhaps I'll give it a try.

> > > A) Integrate the Mozilla CA pack into Python, updating it with each
> > > security release.
> 
> > I suggest you discuss this on python-dev:
> > http://mail.python.org/mailman/listinfo/python-dev
> 
> It's an ugly dependency, I know.  X.509 suffers from a "false
> coherence" design, in which a couple of parties actively work to make
> it look like it has a coherent trust model.  The best you can do is
> try to borrow/leverage the work of one of those parties.

I suppose distributing CA certificates is a practical solution for the
user, *if* we are dedicated enough (e.g. release managers would have to
agree with the burden of tracking changes, and possibly making emergency
releases when a cert must be removed). That's the reason I suggest
asking on python-dev; I don't feel like making that decision alone.

That said, system OpenSSL builds on Linux (and perhaps OS X) should have
been compiled against a well-known system location of CA certificates
maintained by the OS vendor. In this case, you can simply use
SSLContext.set_default_verify_paths
(http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths )
That doesn't help under Windows, though (where we build OpenSSL
ourselves so that the ssl module can be bundled in installers).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 10:17:56 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 23 Dec 2011 09:17:56 +0000
Subject: [issue13294] http.server: minor code style changes.
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1324631876.28.0.675850584404.issue13294@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The original issue was invalid. 
Incorporated Michele Orr?'s code style changes into the trunk and other codelines.

----------
resolution:  -> fixed
status: open -> closed
title: http.server: HEAD request should not return a body -> http.server: minor code style changes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Fri Dec 23 10:26:03 2011
From: report at bugs.python.org (Dan Kaminsky)
Date: Fri, 23 Dec 2011 09:26:03 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324631648.3388.14.camel@localhost.localdomain>
Message-ID: <CAEW7ACm_xX4qAbY=LTLrMk4SFXi-mDX4ZF=Dt3F1X7MHpypAsA@mail.gmail.com>


Dan Kaminsky <dan at doxpara.com> added the comment:

On Fri, Dec 23, 2011 at 4:14 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > You need to check expiration date of the cert in question, and I
> > suppose invocation date as well.
> > You need to look at each of the CNs in the subject name, as well as
> > each of the DNSname types in the SAN extension.
> > You *absolutely must* make sure that each of the intermediate
> > certificates has Basic Constraints: CA set to True.  Otherwise a
> > certificate for foo.com can sign for bar.com (this keeps happening).
>
> I'm confident this is already done by OpenSSL (if requested by user,
> which means using CERT_REQUIRED or CERT_OPTIONAL in Python's ssl module
> - these map to OpenSSL's SSL_VERIFY_PEER).
>
> I guess it would be easy to check this by providing an outdated
> certificate - perhaps I'll give it a try.
>

Be sure to support SAN.  People forget that, and the API makes it a pain in
the butt (the validator doesn't even know who you're validating for).

>
> > > > A) Integrate the Mozilla CA pack into Python, updating it with each
> > > > security release.
> >
> > > I suggest you discuss this on python-dev:
> > > http://mail.python.org/mailman/listinfo/python-dev
> >
> > It's an ugly dependency, I know.  X.509 suffers from a "false
> > coherence" design, in which a couple of parties actively work to make
> > it look like it has a coherent trust model.  The best you can do is
> > try to borrow/leverage the work of one of those parties.
>
> I suppose distributing CA certificates is a practical solution for the
> user, *if* we are dedicated enough (e.g. release managers would have to
> agree with the burden of tracking changes, and possibly making emergency
> releases when a cert must be removed). That's the reason I suggest
> asking on python-dev; I don't feel like making that decision alone.
>

The CA set doesn't change *often*, but it does shift from time to time.

The right thing would be to use the in-built cert set if and only if the
system certs couldn't be checked.

>
> That said, system OpenSSL builds on Linux (and perhaps OS X) should have
> been compiled against a well-known system location of CA certificates
> maintained by the OS vendor. In this case, you can simply use
> SSLContext.set_default_verify_paths
> (
> http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths)
> That doesn't help under Windows, though (where we build OpenSSL
> ourselves so that the ssl module can be bundled in installers).
>

Whatever you've got right now isn't good enough to either be on by default,
or warn by default.  I wouldn't even recommend warning if you didn't ship
with certs.

Technically, you could check the Windows certificate stores too, if you
wanted to write that code.

Before going to python-dev, what do you think is feasible,
implementation-wise?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:18:54 2011
From: report at bugs.python.org (naif)
Date: Fri, 23 Dec 2011 10:18:54 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
Message-ID: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>


New submission from naif <naif at globaleaks.org>:

For the certificate store:

Can we eventually agree to bind a default CA-store to a Mozilla verified one?
Mozilla in handling Firefox does a great job in keeping CA-store up-to-date.

Integrating default mozilla CA-store with Python builds could be a nice way, it's just a matter of integrating into the build-system the download/fetching of default Mozilla store.

At least the language base it's default on a trusted entity to manage, cross-platform, the CA-store for TLS/SSL.

The mainteinance of the CA-store would be delegated to Mozilla that has been demonstrated to be independent and very security conscious, removing dirty CA-store (like Diginotar after Iranian compromise).

That way 90% of case of of SSL/TLS certificate validation will be managed and by default it would be possible to enable secure SSL/TLS client checking like described in http://bugs.python.org/issue13647 .

----------
components: Library (Lib)
messages: 150142
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't have a default CA Store
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:20:03 2011
From: report at bugs.python.org (naif)
Date: Fri, 23 Dec 2011 10:20:03 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324635603.3.0.223942460278.issue13647@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Hi all,

i added a ticket on setting up a default CA-store for Python, eliminating the need of CA-Store mainteinance:
http://bugs.python.org/issue13655

This feature is a pre-requisite to implement by default SSL/TLS Client secure certificate verification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:20:30 2011
From: report at bugs.python.org (naif)
Date: Fri, 23 Dec 2011 10:20:30 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1324635630.22.0.204591584542.issue13655@psf.upfronthosting.co.za>


Changes by naif <naif at globaleaks.org>:


----------
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:22:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 10:22:46 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324635766.08.0.721676150674.issue13647@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Be sure to support SAN.  People forget that, and the API makes it a pain in
> the butt (the validator doesn't even know who you're validating for).

Right, that's why we added the match_hostname() function. It knows about subjectAltName, except for raw IP addresses.
The tests for it can be found here:
http://hg.python.org/cpython/file/0466ee1816b1/Lib/test/test_ssl.py#l265

> Technically, you could check the Windows certificate stores too, if you
> wanted to write that code.

Well, I don't know how to interface them with OpenSSL.

> Before going to python-dev, what do you think is feasible,
> implementation-wise?

Technically, shipping certificates shouldn't be difficult. The final install location is defined at "./configure" time, so loading the certs shouldn't be a problem either.
Whether or not we enable them by default is a matter of policy. I think enabling them by default could be a nasty surprise for users who currently rely on a narrower set of trusted certs.

> The right thing would be to use the in-built cert set if and only if the
> system certs couldn't be checked.

That might not be easy. OpenSSL's SSL_CTX_set_default_verify_paths() deliberately doesn't report errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:27:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 10:27:37 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1324636057.39.0.662047788116.issue8604@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I wish we had something like:
> io.file
> io.file.tempfile
> io.file.path
> io.file.atomicfile

I adhere to "flat is better than nested". e.g. it always irks me to type "urllib.request" instead of "urllib". A 3-level deep nesting in the stdlib would certainly shock many people :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:36:53 2011
From: report at bugs.python.org (naif)
Date: Fri, 23 Dec 2011 10:36:53 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324636613.64.0.168908913208.issue13647@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

mmmm looking at OpenSSL command line, there is the "verify" that does a lot of checks on it's own:
http://www.openssl.org/docs/apps/verify.html

Dan, do you think that this apps does all the "best practice" verificati or it's missing something?

Antoine, in case it's useful, do you think that it would be possible to have something exactly-like the OpenSSL verify command?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:39:59 2011
From: report at bugs.python.org (naif)
Date: Fri, 23 Dec 2011 10:39:59 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1324636799.0.0.398632394015.issue13655@psf.upfronthosting.co.za>


naif <naif at globaleaks.org> added the comment:

Mozilla CA are available on:

https://www.mozilla.org/projects/security/certs/

The warranty and security process of Mozilla handling of SSL CA root certs is described on:

https://wiki.mozilla.org/CA

I think that Python language could reasonably base it's default root CA on the Mozilla ones that are the most recognized for security and transparency in the world.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:43:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 10:43:08 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324636613.64.0.168908913208.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324636943.3388.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, in case it's useful, do you think that it would be possible
> to have something exactly-like the OpenSSL verify command?

Well, to quote the page you mentioned:
?The verify program uses the same functions as the internal SSL and
S/MIME verification, therefore this description applies to these verify
operations too.?

So these checks are exactly the ones performed when using CERT_OPTIONAL
or CERT_REQUIRED.
Note that it is cursorily mentioned (or hinted at) at
http://docs.python.org/dev/library/ssl.html#verifying-certificates

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:05:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 11:05:32 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324638332.73.0.572042868043.issue8828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So how about providing a new public `os` module function doing a rename-with-overwrite on all platforms?
We could name it e.g. os.replace().
os.rename_overwrite() is another possibility, more explicit but also longer.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:35:38 2011
From: report at bugs.python.org (Stef Walter)
Date: Fri, 23 Dec 2011 11:35:38 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1321799934.36.0.700052939026.issue6983@psf.upfronthosting.co.za>
Message-ID: <4EF46785.8060201@memberwebs.com>


Stef Walter <stef at memberwebs.com> added the comment:

Good plan.

So the issue is:

 * Platform specific eggs are built containing a path that has the full
   patch level of the freebsd kernel, like "8.2-RELEASE-p2". The "-p2"
   part is updated for every security patch of FreeBSD.
 * Thus when you apply a security patch to FreeBSD, platform specific
   eggs built for that version of FreeBSD (before the security patch
   was applied) are no longer considered compatible.

FYI, FreeBSD has an unwritten policy of keeping all 8.x releases
backwards compatible with one another. So platform specific eggs built
for 8.1 would work without inherent problems on 8.2 or 8.3.

But at the very least, platform specific eggs should not be dependent on
the patch level of the FreeBSD kernel.

On 11/20/2011 03:38 PM, ?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
>> This is still a bothersome issue, but we've taken to patching every version of python
>> downstream before deploying them. All for a simple three line patch.
> 
> Sorry about the unsatisfactory situation.  Could we start anew and define exactly what the problem is, so that distutils2 can be free of it?  (I?m afraid distutils can?t be changed: even undocumented, the platform string used for FreeBSD is certainly used by tools out there that we don?t want to break.  I second the suggestion to bring up the issue to the projects responsible for eggs, i.e. setuptools and distribute, not distutils.)
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6983>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:37:06 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 23 Dec 2011 11:37:06 +0000
Subject: [issue13656] Document ctypes.util and ctypes.wintypes.
Message-ID: <1324640225.55.0.0772852885981.issue13656@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

Document ctypes.util and ctypes.wintypes.

----------
assignee: docs at python
components: Documentation
messages: 150151
nosy: docs at python, maniram.maniram
priority: normal
severity: normal
status: open
title: Document ctypes.util and ctypes.wintypes.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13656>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:38:03 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 23 Dec 2011 11:38:03 +0000
Subject: [issue13656] Document ctypes.util and ctypes.wintypes.
In-Reply-To: <1324640225.55.0.0772852885981.issue13656@psf.upfronthosting.co.za>
Message-ID: <1324640283.19.0.972903646211.issue13656@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13656>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:41:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 11:41:07 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <E1Re3Uo-0000SO-0s@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7a7b698f6f21 by Antoine Pitrou in branch 'default':
Issue #13577: Built-in methods and functions now have a __qualname__.
http://hg.python.org/cpython/rev/7a7b698f6f21

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:42:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 11:42:04 +0000
Subject: [issue13577] __qualname__ is not present on builtin methods and
	functions
In-Reply-To: <1323577625.41.0.637168954085.issue13577@psf.upfronthosting.co.za>
Message-ID: <1324640524.98.0.769580745508.issue13577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is committed, thank you!

----------
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13577>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:45:42 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 23 Dec 2011 11:45:42 +0000
Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2.
Message-ID: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

IDLE doesn't support nor set sys.ps1 and sys.ps2.
>>> sys.ps1
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    sys.ps1
AttributeError: 'module' object has no attribute 'ps1'
>>> sys.ps1 = "Test " #The next prompt doesn't start with Test
>>>

----------
components: IDLE
messages: 150154
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: IDLE doesn't support sys.ps1 and sys.ps2.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13657>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:50:41 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 11:50:41 +0000
Subject: [issue1730372] Mesa with NPTL makes Python extensions crash with
	std::cerr
Message-ID: <1324641041.16.0.760001369736.issue1730372@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I assume this was due to the following bug:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
http://lists.freedesktop.org/archives/mesa-dev/2011-March/006180.html

In short, MESA didn't use the correct TLS model for thread-local variables, which ended up in some libstdc++ thread-local variables not being initialized when called from a dynamically loaded libraries (such as spam).

I couldn't reproduce the problem on Debian testing (which has a mesa version containing the patch posted on mesa-dev).

----------
nosy: +neologix
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730372>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:57:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 11:57:15 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1324636057.39.0.662047788116.issue8604@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1MjRYGs2uA7us441=4UGwc0dOkVeO5V-180NR4gsEO+w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I adhere to "flat is better than nested". e.g. it always irks me to type
> "urllib.request" instead of "urllib".

Well, that's what (selective) imports are for, no ?
from urllib import request
from file.path import exists
import xml.etree.cElementTree as ET

Anyway, my "thoughts?" wasn't referring to this namespace hierarchy
"proposal" (which really isn't one), but rather to the best module
which could host an AtomicFile class.
Still shutil?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:09:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 12:09:06 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <CAH_1eM1MjRYGs2uA7us441=4UGwc0dOkVeO5V-180NR4gsEO+w@mail.gmail.com>
Message-ID: <1324642101.3388.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Anyway, my "thoughts?" wasn't referring to this namespace hierarchy
> "proposal" (which really isn't one), but rather to the best module
> which could host an AtomicFile class.

Does it have to be a class? What would be the operations apart from
write()?

> Still shutil?

I think that's our best compromise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:54:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 12:54:20 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1324642101.3388.24.camel@localhost.localdomain>
Message-ID: <CAH_1eM3tqdvuQw1dF4RfpKt_hUWVKTSvVVYPT5y5T87DzFob3A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Does it have to be a class? What would be the operations apart from
> write()?

Well, I thought that making it a file-like object could be useful:
that way, one could pass it to pickle.dump(), logging.StreamHandler or
any method expecting a file-like object, and would gain atomicity
(persistency) transparently, without refactoring.
My quick and dirty AtomicFile implementation reused the
_TemporaryFileWrapper attribute delagation trick:
"""
    def __getattr__(self, name):
        # Attribute lookups are delegated to the underlying file
        # and cached for non-numeric results
        # (i.e. methods are cached, closed and friends are not)
        file = self.__dict__['file']
        a = getattr(file, name)
        if not issubclass(type(a), type(0)):
            setattr(self, name, a)
        return a
"""

>> Still shutil?
>
> I think that's our best compromise.

OK.
I don't have a strong opinion about this, and you've got much more
experience than me, so I trust your judgement ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:58:14 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Fri, 23 Dec 2011 12:58:14 +0000
Subject: [issue13653] reorder set.intersection parameters for better
	performance
In-Reply-To: <1324601653.94.0.248406097539.issue13653@psf.upfronthosting.co.za>
Message-ID: <1324645094.27.0.39891919407.issue13653@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

My belief is that the people who use set.intersection with more than two terms are 1) going to pass in a list of sets, and 2) don't care about the specific order.

To check the validity of my belief, I did a Google Code Search to find cases of people using set intersection in Python. I searched for "set\.intersection\(\*" and "\.intersection\(.*\, lang:^python$", among others.

I am sad to report that the most common way to compute set.intersection(*list) is by using reduce, like:

    possible = (set(index[c]) for c in set(otp))
    possible = reduce(lambda a, b: a.intersection(b), possible)


That comes from:
  git://github.com/Kami/python-yubico-client.git /yubico/modhex.py
and similar uses are in:
  git://github.com/sburns/PyCap.git /redcap/rc.py
  http://hltdi-l3.googlecode.com/hg//xdg/languages/morpho/fst.py
  http://dsniff.googlecode.com/svn/trunk/dsniff/lib/fcap.py


As well as in the Rosetta Code example for a simple inverted index, at:
  http://rosettacode.org/wiki/Inverted_index#Python

This was also implemented more verbosely in:

http://eats.googlecode.com/svn/trunk/server/eats/views/main.py
    intersected_set = sets[0]
    for i in range(1, len(sets)):
        intersected_set = intersected_set.intersection(sets[i])

and 

http://iocbio.googlecode.com/svn/trunk/iocbio/microscope/cluster_tools.py
        s = set (range (len (data[0])))
        for d in zip(*data):
            s = s.intersection(set(find_outliers(d, zoffset=zoffset)))
        return sorted(s)

In other words, 7 codebases use manual pairwise reduction rather than use the equivalent code in Python. (I have not checked for which are due to backwards compatibility requirements.)

On the other hand, if someone really wants to have a specific intersection order, this shows that it's very easy to write.


I found 4 other code bases where set intersection was used for something other than binary intersection, and used the built-in intersection().



git://github.com/valda/wryebash.git/experimental/bait/bait/presenter/impl/filters.py
    def get_visible_node_ids(self, filterId):
        if filterId in self.idMask:
            visibleNodeIdSets = [f.get_visible_node_ids(filterId) for f in self._filters]
            return set.intersection(*[v for v in visibleNodeIdSets if v is not None])
        return None



http://wallproxy.googlecode.com/svn/trunk/local/proxy.py
                if threads[ct].intersection(*threads.itervalues()):
                    raise ValueError('All threads failed')
(here, threads' values contain sets)



git://github.com/argriffing/xgcode.git/20100623a.py
    header_sets = [set(x) for x in header_list]
    header_intersection = set.intersection(*header_sets)




http://pyvenn.googlecode.com/hg//venn.py
            to_exclude = set()
            for ii in xrange(0, len(self.sets)):
                if (i & (2**ii)):
                    sets_to_intersect.append(sets_by_power_of_two[i & (2**ii)])
                else:
                    to_exclude = to_exclude.union(sets_by_power_of_two[(2**ii)])
            final = set.intersection(*sets_to_intersect) - to_exclude



These all find the intersection of sets (not iterators), and the order of evaluation does not appear like it will affect the result.

I do not know though if there will be a performance advantage in these cases to reordering. I do know that in my code, and any inverted index, there is an advantage.

And I do know that the current CPython implementation has bad worst-case performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13653>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:13:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 13:13:23 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <CAH_1eM3tqdvuQw1dF4RfpKt_hUWVKTSvVVYPT5y5T87DzFob3A@mail.gmail.com>
Message-ID: <1324645958.3388.26.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Does it have to be a class? What would be the operations apart from
> > write()?
> 
> Well, I thought that making it a file-like object could be useful:
> that way, one could pass it to pickle.dump(), logging.StreamHandler or
> any method expecting a file-like object, and would gain atomicity
> (persistency) transparently, without refactoring.

Mmmh... I might have misunderstood the proposal then. I thought this
"atomic write" API was about writing the file contents in one go and
immediately closing the file. If you want atomicity to apply to logging,
you must instead guarantee the durability of each write() call, meaning
calling fsync() on each logging call, which would be very expensive.

Am I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:56:41 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 23 Dec 2011 13:56:41 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324648601.04.0.220002295125.issue5689@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Wouldn't it be better then to use a default compresslevel of 6 in tarfile? I used level 9 in my patch without a particular reason, just because I thought 9 must be better than 6 ;-)

----------
Added file: http://bugs.python.org/file24084/lzma-preset.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:05:09 2011
From: report at bugs.python.org (Florent Viard)
Date: Fri, 23 Dec 2011 14:05:09 +0000
Subject: [issue10513] sqlite3.InterfaceError after commit
In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>
Message-ID: <1324649109.51.0.362360139629.issue10513@psf.upfronthosting.co.za>


Florent Viard <fviard at lacie.com> added the comment:

Hi,

I encountered the same regression with python 2.7.
I added a new testcase (testcase2) with another effect of the same problem. It is a model of what does python-storm when I try to do:

for item in TableA.findall():
  TableB.new_item(name=item.name)
  connection.commit()

As you can see in the result:
-- One iter --
(0,)
-- One iter --
(1,)
-- One iter --
(0,)
-- One iter --
(1,)
-- One iter --
(2,)

Inside the for loop, there is a reset, but only one time. So entries returned by "for" are inconsistents as there could be some duplicated results.


After studying the code, I understood that this regression is caused by the addition of function call:
        pysqlite_do_all_statements(self, ACTION_RESET, 0);
in connection.c: in function: pysqlite_connection_commit

Removing this line, fixes the problem and bring back the old correct behavior.


For the explanation of my case, I understood that:
For the "statement" of my query, the "in_use" flag is first set to 1, the first fetchmany call ran, then the commit triggered the reset of all the statements that have  the in_use flag == 1 and set this flag to 0. So the next fetchmany call return results from the beginning again without care for the state of the "in_use" flag. Then, the next commit don't reset again the statement as its "in_use" flag is still == 0.

I think, that the first intention of this modification was more to use the following call:
pysqlite_do_all_statements(self, ACTION_RESET, 1);
to have the cursor->reset set and so, at next fetch call, triggering exception: "sqlite3.InterfaceError: Cursor needed to be reset because of commit/rollback and can no longer be fetched from."

But as for using it in rollback, I'm not sure that this behavior is really useful as sqlite3 looks to be able to correctly handle modifications and cursor return values.
As an example, the following test with the previous code :
    cursor = conn.cursor()
    cursorBis = conn.cursor()
    cursor.execute('create table first(id primary key);')
    for i in range(5):
        cursor.execute('insert or replace into first(id) values(?);', (i,))

    results = cursor.execute(' select id from first;')
    while True:
        print "-- One iter --"
        results = cursor.fetchmany()
        if not results:
            break
        for result in results:
            print str(result)
            cursorBis.execute(' delete from first where id == ?;', (3,))
        conn.commit()

That correctly printed:
-- One iter --
(0,)
-- One iter --
(1,)
-- One iter --
(2,)
-- One iter --
(4,)
-- One iter --


So my suggestion is to remove in "pysql_connection_commit" the call to :
pysqlite_do_all_statements(self, ACTION_RESET, 0);
to bring back the correct old behavior.

And also eventually to remove in "pysqlite_connection_rollback" the call to :
pysqlite_do_all_statements(self, ACTION_RESET, 1);


What do you think about it?

----------
nosy: +fviard
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24085/test_bug_pysql_for.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10513>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:28:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 14:28:37 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1324645958.3388.26.camel@localhost.localdomain>
Message-ID: <CAH_1eM2HvVYGEf5-T7Oh9vwpjxD9rBws4_-jagokyw1MBJED9Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> If you want atomicity to apply to logging,
> you must instead guarantee the durability of each write() call, meaning
> calling fsync() on each logging call

Why so?
There's no point in calling fsync() after each write, since data is
written to a temporary file which won't be visible before rename():
even if you call fsync() after each write, if the file is not properly
closed, it won't be committed (i.e.renamed).
You just need to call fsync() once before closing the file, and then
rename it, to ensure that the committed file version is consistent.
In the meantime, you could do whatever you want with the stream (the
hypothetical AtomicFile): seek(), read(), etc. I'm not sure many
methods besides write will be useful, but for example one could easily
imagine that the library expects the passed object to have a fileno()
method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:40:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 14:40:42 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <CAH_1eM2HvVYGEf5-T7Oh9vwpjxD9rBws4_-jagokyw1MBJED9Q@mail.gmail.com>
Message-ID: <1324651196.3388.34.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There's no point in calling fsync() after each write, since data is
> written to a temporary file which won't be visible before rename():
> even if you call fsync() after each write, if the file is not properly
> closed, it won't be committed (i.e.renamed).

Ah, it's a temporary file indeed.
But does that mean you can't inspect your logs in real time? All log
files I have ever seen are available under their final name while they
are still being written to.

> In the meantime, you could do whatever you want with the stream (the
> hypothetical AtomicFile): seek(), read(), etc.

I see. Yes, then an AtomicFile class makes sense (not for logging
though, IMHO :-)).

And I understand your point about it being available in io or some io
submodule (not a 3-level deep one though :-)). Perhaps you want to ask
on python-dev?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:51:19 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 23 Dec 2011 14:51:19 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324651879.14.0.0622390311203.issue5689@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Yes, that's a good idea. I've been testing a similar change, and it seems
to drop the peak memory usage for test_tarfile from around 810MB down to
under 200MB. It looks like 2GB genuinely isn't enough to reliably use LZMA
compression with preset=9.

You might want to use preset=None instead of explicitly saying preset=6,
though. This tells LZMAFile to use the default preset, and will allow you
to get rid of the if-statement on lines 1821-1823.

Something unrelated that I noticed in the surrounding code: gzopen and
bz2open validate the mode by testing 'len(mode) > 1 or mode not in "rw"'.
This would be simpler as 'mode not in ("r", "w")' (like you've done in
xzopen), and it would accept only "r" and "w" (but not "" or "rw").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:51:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 14:51:49 +0000
Subject: [issue13651] Improve redirection in urllib
In-Reply-To: <1324577379.51.0.5468672041.issue13651@psf.upfronthosting.co.za>
Message-ID: <1324651909.48.0.561535355438.issue13651@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
versions: +Python 2.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13651>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:21:13 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 23 Dec 2011 15:21:13 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324653673.84.0.945763716904.issue5689@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


Removed file: http://bugs.python.org/file24084/lzma-preset.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:22:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2011 15:22:47 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324653767.23.0.661572551015.issue8828@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What is the motivation for providing a new function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:22:48 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 23 Dec 2011 15:22:48 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324653768.51.0.407314733346.issue5689@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Yes, that's much better. Thanks for the tip.

----------
Added file: http://bugs.python.org/file24086/lzma-preset.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:28:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 15:28:01 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1324653767.23.0.661572551015.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324654035.3388.35.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What is the motivation for providing a new function?

Because changing os.rename would break compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:31:54 2011
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 23 Dec 2011 15:31:54 +0000
Subject: [issue13658] Extra clause in class grammar documentation
Message-ID: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>


New submission from Joshua Landau <joshua.landau.ws at gmail.com>:

Inside the grammar for classes[1], the documentation states that the inheritance list can be of type:
"(" [argument_list [","] | comprehension] ")"

The "comprehension" part seems to be superfluous, especially as it is valid grammar without the clause.

The 2.7 docs state just "[expression list]", so either the addition should be justified or the extra clause removed.

[1] http://docs.python.org/py3k/reference/compound_stmts.html#grammar-token-classdef

Please see http://mail.python.org/pipermail/python-list/2011-December/1284989.html for discussion.

----------
assignee: docs at python
components: Documentation
messages: 150169
nosy: Joshua.Landau, docs at python
priority: normal
severity: normal
status: open
title: Extra clause in class grammar documentation
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13658>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:39:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2011 15:39:07 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324654747.17.0.989918755432.issue8828@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I see, people may be depending on rename on Windows not overwriting.

I suppose a new function (and eventually deprecating the old?) would be the most straightforward way forward, though I dislike the necessity :)

An alternative might be a flag on rename: overwrite=['always', 'os_default'], with a warning and a switch of the default in a subsequent release.  That's ugly too, of course.  The existing per-platform variation in behavior of rename gives us a mess to deal with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:45:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 15:45:13 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <E1Re7J1-0004JL-PC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 683a1b1ff15d by Charles-Fran?ois Natali in branch 'default':
Issue #8623: Fix some strict-aliasing warnings. Patch by David Watson.
http://hg.python.org/cpython/rev/683a1b1ff15d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8623>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:45:18 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 23 Dec 2011 15:45:18 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1324655118.21.0.207003799005.issue8313@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

traceback patch looks good. Thanks for the unittest2 patch as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8313>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:48:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 15:48:09 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1324655289.75.0.313814094929.issue8623@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks for your patches, David.
I've only applied the first one: looking at the second one, I don't think they are really problems (-Wstrict-aliasing=2 is know for generating a lot of false positives).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8623>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:50:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 15:50:58 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1324651196.3388.34.camel@localhost.localdomain>
Message-ID: <CAH_1eM2oswUg9phzjboywpq_=yJZd35u8TXUe5Pm5fbP2LCsJA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Ah, it's a temporary file indeed.
> But does that mean you can't inspect your logs in real time? All log
> files I have ever seen are available under their final name while they
> are still being written to.
>

Yes, logging was a poor example :-)

> And I understand your point about it being available in io or some io
> submodule (not a 3-level deep one though :-)). Perhaps you want to ask
> on python-dev?

OK, I'll try that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:53:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 15:53:57 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324655637.21.0.542781097972.issue8828@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'd prefer an optional flag to rename() too.
I really don't like having different functions that achieve the same thing.
It's not obvious to infer from 'replace' its real intent, since it
doesn't match any standard syscall/library.
Ideally, this should be made an option to rename(), especially since
on Unix this will just perform a standard rename.
Another advantage of options over new functions is that it reduces
boilerplate code (i.e. argument parsing, addition to posix_methods,
repeating OS idiosyncrasies/conditional compilation blocks, docstring,
documentation block...).
But I remember Martin thinks that the os module should just be a thin wrapper around underlying syscalls/libraries (but we already have listdir() and friends).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 16:58:42 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Dec 2011 15:58:42 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324655922.99.0.758014581359.issue8828@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

os.rename(overwrite=True) to produce consistent cross-platform behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:08:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 16:08:47 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1324654747.17.0.989918755432.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324656480.3388.38.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> An alternative might be a flag on rename: overwrite=['always', 'os_default']

How about overwrite=[None, True] with None meaning "OS default"?

> with a warning and a switch of the default in a subsequent release.

I think we should be conservative with warnings and
compatibility-breaking changes. In this case there's no pressing need to
change behaviour: the default isn't less secure or less efficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:12:38 2011
From: report at bugs.python.org (Ray)
Date: Fri, 23 Dec 2011 16:12:38 +0000
Subject: [issue13511] Specifying multiple lib and include directories on linux
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1324656758.86.0.899937549668.issue13511@psf.upfronthosting.co.za>


Ray <rpqpro at hotmail.com> added the comment:

Whether or not includedir and libdir are supposed to allow multiple packages is beyond me at this point so I'll change the topic to more reflect the problem I am having.  More importantly (and possibly related to includedir and libdir) is the fact that python 2.7 does not allow specifying multiple lib and include directories in linux.  Is there one way to do this that I overlooked? I included the bit about includedir, libdir, CFLAGS, and LDFLAGS in my original post to show what I tried.  

Is it a standard for CFLAGS AND LDFLAGS to accept multiple directories? I would think so.  With the current python 2.7 and linux, that simply does not work.  But it does for darwin platforms?

>From setup.py:

>         if platform == 'darwin':
>             # This should work on any unixy platform ;-)
>             # If the user has bothered specifying additional -I and -L flags
>             # in OPT and LDFLAGS we might as well use them here.

----------
title: Let ./configure accept multiple --includedir and --libdir options -> Specifying multiple lib and include directories on linux
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13511>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:15:14 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Dec 2011 16:15:14 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324656914.56.0.938540539765.issue8828@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

One of the Python advantages is providing predictable cross-platform behavior.  If we can't introduce nice API without BC break, it is not a reason to introduce ulgy API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:22:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2011 16:22:25 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324657345.3.0.348606871931.issue8828@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm good with None/True, but that would imply that for posix rename we'll need to implement the overwrite=False option...which would be a nice thing (the shell mv command has -i for that).

I think a warning would be good, because a unix programmer will assume rename will work the same on windows as it does on posix, and vice versa for a windows programmer.  I suppose the fact that we haven't gotten many (any?) complaints about it means it isn't that common a problem, though, so I don't feel strongly about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:30:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 16:30:43 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1324657345.3.0.348606871931.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324657797.3388.49.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm good with None/True, but that would imply that for posix rename
> we'll need to implement the overwrite=False option...which would be a
> nice thing (the shell mv command has -i for that).

My point was rather to forbid False as a value (on all OSes) :)

> I think a warning would be good, because a unix programmer will assume
> rename will work the same on windows as it does on posix, and vice
> versa for a windows programmer.

It is already documented. I don't think we want to add a warning for
every documented peculiar piece of behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:30:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 16:30:55 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324657855.68.0.175662338942.issue8828@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> How about overwrite=[None, True] with None meaning "OS default"?

+1.

> One of the Python advantages is providing predictable cross-platform 
> behavior. If we can't introduce nice API without BC break, it is not
> a reason to introduce ulgy API.

We cannot make rename() overwrite existing files by default (on Windows).
It's out of question, too much code might rely on this, and this may very well introduce security flaws.
If you're concerned with the semantics difference between platforms, well, there's not much we can do about it now. Java behaves in the same way, for example.

> I'm good with None/True, but that would imply that for posix rename 
> we'll need to implement the overwrite=False option...which would be a 
> nice thing (the shell mv command has -i for that).

Why?
The problem is that it's simply impossible to implement reliably.
I didn't check mv source code, but it must be using something like:

if '-i' and os.path.exists(target_path):
    continue
os.rename(src_path, target_path).

But there's a TOCTTOU race.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:46:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2011 16:46:51 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324658811.04.0.206521648602.issue8828@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, you are right about the race of course.  So yes, I agree with your proposal.  It's a weird API, but probably the best we can do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:53:52 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Dec 2011 16:53:52 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1324659232.9.0.928346803656.issue13647@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/issue13647>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:54:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Dec 2011 16:54:33 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1324659273.42.0.668011531797.issue13655@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/issue13655>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:15:05 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 23 Dec 2011 17:15:05 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1324660505.83.0.529745482563.issue5689@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:17:57 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Dec 2011 17:17:57 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1324660677.47.0.672646059471.issue8623@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

This change probably should be backported to 3.2 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8623>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:26:03 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Dec 2011 17:26:03 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1324657855.68.0.175662338942.issue8828@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+Ro167g3Bact4RaPjPMKhKcGkcMrbcGQ5usqNG6PH_qg@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

2011/12/23 Charles-Fran?ois Natali <report at bugs.python.org>
>
> > One of the Python advantages is providing predictable cross-platform
> > behavior. If we can't introduce nice API without BC break, it is not
> > a reason to introduce ulgy API.
>
> We cannot make rename() overwrite existing files by default (on Windows).
> It's out of question, too much code might rely on this, and this may very
> well introduce security flaws.
> If you're concerned with the semantics difference between platforms, well,
> there's not much we can do about it now. Java behaves in the same way, for
> example.
>

I propose quite the opposite. rename() should not overwrite existing files
by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:29:46 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Dec 2011 17:29:46 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1324661386.57.0.975005237143.issue13655@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm not sure Python should be in the business of distributing CA certificates. I think it's better left to the application or Linux distribution.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:32:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 17:32:06 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324661526.62.0.617398808228.issue8828@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I propose quite the opposite. rename() should not overwrite existing
> files by default.

1. That's not what I understood from:
> os.rename(overwrite=True) to produce consistent cross-platform 
> behavior.

2. The above argument on backward incompatible change applies in exactly the same way (just exchange Windows for POSIX).

3. As explained above, it can not be done reliably on POSIX (TOCTTOU race).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:49:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Dec 2011 17:49:35 +0000
Subject: [issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64
	Snow Leopard 02 03.x"
In-Reply-To: <1323435539.17.0.162534043929.issue13565@psf.upfronthosting.co.za>
Message-ID: <1324662575.88.0.908644081303.issue13565@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, could you try the attached script on FreeBSD,
> to see if you get ECONNREFUSED?

Yes, I get a ECONNREFUSED. I tested backlog.py on FreeBSD 8.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13565>
_______________________________________

From report at bugs.python.org  Fri Dec 23 19:10:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 18:10:53 +0000
Subject: [issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64
	Snow Leopard 02 03.x"
In-Reply-To: <1323435539.17.0.162534043929.issue13565@psf.upfronthosting.co.za>
Message-ID: <E1Re9a0-0007ij-96@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 94494a779c20 by Charles-Fran?ois Natali in branch '2.7':
Issue #13565: Increase multiprocessing's server socket backlog, to avoid
http://hg.python.org/cpython/rev/94494a779c20

New changeset 9b99adef3c78 by Charles-Fran?ois Natali in branch '3.2':
Issue #13565: Increase multiprocessing's server socket backlog, to avoid
http://hg.python.org/cpython/rev/9b99adef3c78

New changeset 29cad1ac828c by Charles-Fran?ois Natali in branch 'default':
Issue #13565: Increase multiprocessing's server socket backlog, to avoid
http://hg.python.org/cpython/rev/29cad1ac828c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13565>
_______________________________________

From report at bugs.python.org  Fri Dec 23 19:23:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Dec 2011 18:23:05 +0000
Subject: [issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64
	Snow Leopard 02 03.x"
In-Reply-To: <1323435539.17.0.162534043929.issue13565@psf.upfronthosting.co.za>
Message-ID: <1324664585.22.0.252643286709.issue13565@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Yes, I get a ECONNREFUSED. I tested backlog.py on FreeBSD 8.2.

Thanks.
I bumped the backlog, I hope it will fix this.
We can leave this report open for a couple days, to see how the buildbots behave.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13565>
_______________________________________

From report at bugs.python.org  Fri Dec 23 20:29:06 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Dec 2011 19:29:06 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1324661526.62.0.617398808228.issue8828@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xK_GvRps1CXHPUb2=wYExpy0pHxNUoh6NqnYg7h8qzpfg@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

2011/12/23 Charles-Fran?ois Natali <report at bugs.python.org>

>
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
>
> > I propose quite the opposite. rename() should not overwrite existing
> > files by default.
>
> 1. That's not what I understood from:
> > os.rename(overwrite=True) to produce consistent cross-platform
> > behavior.
>
> 2. The above argument on backward incompatible change applies in exactly
> the same way (just exchange Windows for POSIX).
>
> 3. As explained above, it can not be done reliably on POSIX (TOCTTOU race).

os.rename(overwrite=False) by default will do less harm than the opposite,
so I'd say it is a way to go even if it can not be reliably done on POSIX.
But I believe correct file system that supports transactions will make it
possible to do reliably on POSIX too.

Then I believe that having a small chance of overwriting file just created
at exactly the same moment on a POSIX is a small price to pay for function
that does safety check before rename on a platform that doesn't have such
functionality at all. If you need this functionality - you will still do
'if exists ... rename' and the TOCTTOU race will affect you. So, the only
exit is to place a little sign "in some extreme cases Linux suffers from
TOCTTOU problem when renaming files without overwriting, so keep that in
mind".

BUT let me remind you that this bug is about "Atomic rename" which should
rollback in case of errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 20:35:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 19:35:54 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <CAPkN8xK_GvRps1CXHPUb2=wYExpy0pHxNUoh6NqnYg7h8qzpfg@mail.gmail.com>
Message-ID: <1324668907.3388.54.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> os.rename(overwrite=False) by default will do less harm than the opposite,

Disagreed.

> Then I believe that having a small chance of overwriting file just created
> at exactly the same moment on a POSIX is a small price to pay for function
> that does safety check before rename on a platform that doesn't have such
> functionality at all.

Disagreed.
If you need the functionality, it's *one* additional line of code. Not
every trivial function deserves to be in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 20:51:11 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Dec 2011 19:51:11 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1324668907.3388.54.camel@localhost.localdomain>
Message-ID: <CAPkN8xJ2hPmnrMg9VRKVfBBjN2yDZGrF27XMF-DLUNvLopnCug@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Fri, Dec 23, 2011 at 10:35 PM, Antoine Pitrou <report at bugs.python.org>wrote:

> > os.rename(overwrite=False) by default will do less harm than the
> opposite,
>
> Disagreed.
>

Fine. No arguments == no consensus.

> > Then I believe that having a small chance of overwriting file just
> created
> > at exactly the same moment on a POSIX is a small price to pay for
> function
> > that does safety check before rename on a platform that doesn't have such
> > functionality at all.
>
> Disagreed.
> If you need the functionality, it's *one* additional line of code. Not
> every trivial function deserves to be in the stdlib.

As a Windows programmer I am quite surprised to read this thread with
information that on Linux os.rename() overwrites files without questions,
so as I Windows programmer I want os.rename() to stop that. I always guard
my code against accidental rewrite by catching the exception. EAFP and all
that stuff. But there is no way I can ask forgiveness when files are
already overwritten.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 21:04:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2011 20:04:28 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1324670668.55.0.655853819059.issue8828@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So maybe my warning idea isn't such a bad idea :)

As a unix programmer, I was very surprised to read in this thread that Windows doesn't overwrite the file on rename.  As a unix programmer, I don't check for errors on a rename, because I expect it to just work.  I'd like the windows rename call to stop throwing errors if the file exists, it breaks my programs if they run on windows.

(Actually, very few of my programs ever get run on Windows, but you get the idea.)

Thus, the only possible course is to maintain backward compatibility, and allow the programmers who care to specify the desired behavior.  Since one of the important aspects of 'rename' in unix programmers' minds is that it is atomic, a race condition is not acceptable, therefore overwrite=False is not an acceptable option for os.rename.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 21:09:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Dec 2011 20:09:41 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <CAPkN8xJ2hPmnrMg9VRKVfBBjN2yDZGrF27XMF-DLUNvLopnCug@mail.gmail.com>
Message-ID: <1324670934.3388.58.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As a Windows programmer I am quite surprised to read this thread with
> information that on Linux os.rename() overwrites files without questions,
> so as I Windows programmer I want os.rename() to stop that.

As a Windows programmer, you are not really qualified to criticize the
behaviour of Unix systems.
As a Linux programmer, I don't want to see the default behaviour
changed.

> No arguments == no consensus.

We don't strive to achieve consensus. Agreement among the majority of
core developers is enough, and you aren't part of the population anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Fri Dec 23 21:13:30 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 23 Dec 2011 20:13:30 +0000
Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2.
In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za>
Message-ID: <1324671210.81.0.760279763985.issue13657@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This would make the IDLE shell interface more consistent with the original interpreter. 

Presently, the ">>> " prompt is faked by "showprompt" in PyShell.py. It relies on "sys" from the IDLE gui process and not from the "sys" in the subprocess, so mimicking the changed prompt would require querying the subprocess for its sys.ps1 and sys.ps2. The "enter_callback" method will need modification to remove sys.ps2 from the text buffer before execution. Also, EditorWindow.py has code for handling sys.ps1 in "smart_backspace_event" and "newline_and_indent_event". 

If anything, this shell-specific, prompt-handling code needs some refactoring as it should only be in PyShell.py, not in EditorWindow.py.
Issue13039 is a result of prompt code side-effects in EditorWindow.py.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13657>
_______________________________________

From report at bugs.python.org  Fri Dec 23 22:23:31 2011
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 23 Dec 2011 21:23:31 +0000
Subject: [issue13658] Extra clause in class grammar documentation
In-Reply-To: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>
Message-ID: <1324675411.71.0.129119481704.issue13658@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13658>
_______________________________________

From report at bugs.python.org  Fri Dec 23 23:03:09 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 23 Dec 2011 22:03:09 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324677789.63.0.490011785524.issue13644@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

@OP: As you yourself wrote, this is an abort, not a segfault.  It is not a crash; it is a controlled exit of the Python executable.

@Benjamin: I don't really understand your reasoning: what is preventing Python to raise the error during the except clause?

----------
nosy: +georg.brandl
title: Python 3 crashes (segfaults) with this code. -> Python 3 aborts with this code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Fri Dec 23 23:40:22 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Dec 2011 22:40:22 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324680022.92.0.147830525823.issue13644@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Nothing, but that would be pointless; the recursion would just start again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 01:19:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 00:19:42 +0000
Subject: [issue13658] Extra clause in class grammar documentation
In-Reply-To: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>
Message-ID: <1324685982.11.0.52840376882.issue13658@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13658>
_______________________________________

From report at bugs.python.org  Sat Dec 24 02:29:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 01:29:01 +0000
Subject: [issue13615] `setup.py register` fails with -r argument
In-Reply-To: <1324070497.95.0.248126770194.issue13615@psf.upfronthosting.co.za>
Message-ID: <1324690141.96.0.305732393545.issue13615@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does it do the same with http instead of https?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13615>
_______________________________________

From report at bugs.python.org  Sat Dec 24 02:36:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 01:36:35 +0000
Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box
	is open
In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za>
Message-ID: <1324690595.15.0.434650271261.issue13630@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13630>
_______________________________________

From report at bugs.python.org  Sat Dec 24 02:42:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 01:42:26 +0000
Subject: [issue13632] Update token documentation to reflect actual token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <1324690946.51.0.444367572147.issue13632@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Looks good to me.
help(token) already has the corrections. - BACKQUOTE, + RARROW, ELLIPSIS

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13632>
_______________________________________

From report at bugs.python.org  Sat Dec 24 02:42:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 01:42:52 +0000
Subject: [issue13632] Update token documentation to reflect actual token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <1324690972.55.0.124954996809.issue13632@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13632>
_______________________________________

From report at bugs.python.org  Sat Dec 24 03:02:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2011 02:02:27 +0000
Subject: [issue13658] Extra clause in class grammar documentation
In-Reply-To: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>
Message-ID: <E1ReGwK-0002od-JD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b65007ef59c0 by Benjamin Peterson in branch '3.2':
kill superfluous 'comprehension' case (closes #13658)
http://hg.python.org/cpython/rev/b65007ef59c0

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13658>
_______________________________________

From report at bugs.python.org  Sat Dec 24 03:10:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 02:10:47 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324692647.17.0.237580913224.issue13639@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.7 is closed to new features. This looks like it mignt be one. The 2.7 doc for tarfile.open says "Return a TarFile object for the pathname name." Does the meaning of 'pathname' in 2.7 generally include unicode as well as str objects? (It is not in the Glossary.) 

> The error does not occur under Python 3 (even with non-ascii characters), so it should be possible to create a tarfile with a unicode filename on Python 2.7.

Python 3 has many new features that are not in 2.7, so 'possible' is not exactly the point ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:01:38 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 03:01:38 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1324695698.75.0.606403743311.issue13643@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Martin, after reading most all of the unusually large sequence of messages, I am closing this because three of the core developers with the most experience in this area are dead-set against your proposal. That does not make it 'wrong', but does mean that it will not be approved and implemented without new data and more persuasive arguments than those presented so far. I do not see that continued repetition of what has been said so far will change anything.

----------
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> test needed
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:28:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 03:28:50 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324697330.68.0.803919211839.issue13644@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

When I run this with 3.2.2 IDLE, from an edit window, I get an MSVC++ Runtime Library window: "Runtime Error! .../pythonw This application has requested termination in an unusual way...". When I close that, IDLE continues. So I would say that this is not a crash and not even a bug, but a particular choice of undefined behavior given infinite loop code. So we have no obligation to change it. I presume the change from 2.x is a side-effect of a change to improve something else.

def recurse(): recurse()
recurse()

does print "RuntimeError: maximum recursion depth exceeded" but only after printing a    l  o  n  g    traceback. So for running from IDLE, I at least half prefer the immediate error box with no traceback.

----------
nosy: +terry.reedy
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:48:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 03:48:22 +0000
Subject: [issue13653] reorder set.intersection parameters for better
	performance
In-Reply-To: <1324601653.94.0.248406097539.issue13653@psf.upfronthosting.co.za>
Message-ID: <1324698502.02.0.549742906044.issue13653@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given that equality is not identify, order does matter, although in 3.2.2 the results are the opposite of what one might expect.

a = set((1,2,3))
b = set((1.0, 3.0, 5.0))
print(a&b, b&a)
print(a.intersection(b), b.intersection(a))
a &= b
print(a)
>>> 
{1.0, 3.0} {1, 3}
{1.0, 3.0} {1, 3}
{1.0, 3.0}

In my view, a &= b should remove the members of a that are not in b, rather than deleting all and replacing some with equal members of b.

That glitch aside, & remains and remains binary for exact control of order. The doc should just say that intersection may re-order the intersection for efficiency.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13653>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:49:16 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 24 Dec 2011 03:49:16 +0000
Subject: [issue3974] collections.namedtuple uses exec to create new classes
In-Reply-To: <1222430514.93.0.950826754089.issue3974@psf.upfronthosting.co.za>
Message-ID: <1324698556.65.0.871828607432.issue3974@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/issue3974>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:03:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 04:03:39 +0000
Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2.
In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za>
Message-ID: <1324699419.42.0.00270424460145.issue13657@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> so mimicking the changed prompt would require querying the subprocess for its sys.ps1 and sys.ps2.

Is that sensibly possible? Any line of code can change those, so IDLE would have to do the equivalent of
idle.ps1,idle.ps2 = sys.ps1, sys.ps2 before every new ps1 statement prompt. A configuration option might work better.
  
I would rather remove the prompts from the entry window itself, and use 4 char indents instead of 8, so that cutting does not pick up the prompts.  IDLE does not have to exactly imitate the Command Window interface. It could also give the user a choice.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13657>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:12:38 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 04:12:38 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324699958.77.0.600704486194.issue13644@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

@Terry
IDLE restarts python (like in the menu entry "Restart Shell") when the Python process dies no matter how the Python process dies.
So this issue is a valid bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:16:06 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 24 Dec 2011 04:16:06 +0000
Subject: [issue6092] Changed Shortcuts don't show up in menu
In-Reply-To: <1243060734.82.0.446246510061.issue6092@psf.upfronthosting.co.za>
Message-ID: <1324700166.51.0.29816829926.issue6092@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This only applies to menu items from extensions (in this case, ScriptBinding.py). Other events (Copy, Cut, Paste, etc) update the menu shortcut properly.

IDLE handles bindings for extensions separately from built-in functions. As a consequence, bindings for extensions do not get saved with custom key maps in ~/.idlerc/config-keys.cfg, but instead in ~/.idlerc/config-extensions.cfg.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6092>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:36:03 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 24 Dec 2011 04:36:03 +0000
Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2.
In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za>
Message-ID: <1324701363.75.0.115399066917.issue13657@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

> Is that sensibly possible? Any line of code can change those, so IDLE would have to do the equivalent of idle.ps1,idle.ps2 = sys.ps1, sys.ps2 before every new ps1 statement prompt.

It may be possible if the code gets refactored such that the subprocess handles the prompt and has stdin/stdout/stderr through RPCProxy treat the PyShell text widget as a dumb terminal.

> I would rather remove the prompts from the entry window itself, and use 4 char indents instead of 8, so that cutting does not pick up the prompts.  IDLE does not have to exactly imitate the Command Window interface. It could also give the user a choice.

This is #11838 and #1178.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13657>
_______________________________________

From report at bugs.python.org  Sat Dec 24 06:14:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2011 05:14:31 +0000
Subject: [issue13632] Update token documentation to reflect actual token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <E1ReJwD-00052v-V5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b7d099e8c136 by Meador Inge in branch '3.2':
Issue #13632: Update token documentation to reflect actual token types
http://hg.python.org/cpython/rev/b7d099e8c136

New changeset 1461327e63b5 by Meador Inge in branch 'default':
Issue #13632: Update token documentation to reflect actual token types
http://hg.python.org/cpython/rev/1461327e63b5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13632>
_______________________________________

From report at bugs.python.org  Sat Dec 24 06:18:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 24 Dec 2011 05:18:23 +0000
Subject: [issue13632] Update token documentation to reflect actual token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <1324703903.88.0.673444537906.issue13632@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Committed.  Thanks for the review Terry.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13632>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:05:28 2011
From: report at bugs.python.org (Ron Adam)
Date: Sat, 24 Dec 2011 06:05:28 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324706728.92.0.133246119415.issue13607@psf.upfronthosting.co.za>


Changes by Ron Adam <ron3200 at gmail.com>:


Removed file: http://bugs.python.org/file24047/f_why1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:17:06 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Dec 2011 06:17:06 +0000
Subject: [issue13615] `setup.py register` fails with -r argument
In-Reply-To: <1324070497.95.0.248126770194.issue13615@psf.upfronthosting.co.za>
Message-ID: <1324707426.16.0.083497119948.issue13615@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Can't test right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13615>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:23:35 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 06:23:35 +0000
Subject: [issue13659] Add a help() viewer for IDLE's Shell.
Message-ID: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

If you call help() a few times on some objects, due to help()'s output IDLE's Shell Window becomes very long and it becomes difficult to scroll through the window.

I suggest a new window should be opened when help() is called in IDLE so that no help output comes in the IDLE Shell Window.

This bug doesn't affect the Python command-line on Linux (and I think Mac OS X) since help() uses the less program to display the help output.

----------
components: IDLE
messages: 150214
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: Add a help() viewer for IDLE's Shell.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13659>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:24:44 2011
From: report at bugs.python.org (Martin Pool)
Date: Sat, 24 Dec 2011 06:24:44 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324695698.75.0.606403743311.issue13643@psf.upfronthosting.co.za>
Message-ID: <CAA9uavAcFQJdHUZ8+OSoUrCKd4owbRcJtF_qX3apqyavK1nTqQ@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

Terry, that's fine.  Thanks to everyone who contributed to the discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:41:02 2011
From: report at bugs.python.org (Ron Adam)
Date: Sat, 24 Dec 2011 06:41:02 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1324708862.82.0.694935092257.issue13607@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

Updated patch with suggested changes.

It also has a cleaned up fast_block_end section.

Concerning speed. What happens is (as Tim and Raymond have pointed out) that we can make some things a little faster, in exchange for other things being a little slower.  You can play around with the order of the why cases in the fast_block_end section and see that effect.

By using a switch instead of if-else's, that should result in more consistent balance between the block exit cases.  The order I currently have gives a little more priority for exceptions and that seems to help a tiny bit with the ccbench scores.  I think that is a better bench mark than the small micro tests like pybench does.  The problem with pybench is, it doesn't test deeper nesting where these particular changes will have a greater effect.

----------
Added file: http://bugs.python.org/file24087/f_why2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:25:25 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 24 Dec 2011 07:25:25 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324711525.23.0.146063004577.issue13644@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This is identical to issue6028 and may be related to issue3555.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:26:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 07:26:50 +0000
Subject: [issue6092] IDLE: Changed Shortcuts don't show up in menu
In-Reply-To: <1243060734.82.0.446246510061.issue6092@psf.upfronthosting.co.za>
Message-ID: <1324711610.66.0.0396343583181.issue6092@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Changed Shortcuts don't show up in menu -> IDLE: Changed Shortcuts don't show up in menu
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6092>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:34:43 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 07:34:43 +0000
Subject: [issue13659] Add a help() viewer for IDLE's Shell.
In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za>
Message-ID: <1324712083.59.0.0670535005141.issue13659@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Sorry, new window in "I suggest a new window" should be a new read-only editor window.
It could be implemented through a wrapper around help.
IDLE could have a configuration option whether to use the traditional help() or the new help() which opens a new window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13659>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:44:45 2011
From: report at bugs.python.org (mani and ram)
Date: Sat, 24 Dec 2011 07:44:45 +0000
Subject: [issue13660] maniandram maniandram wants to chat
Message-ID: <CAExgZOgNvv-h1cur3qVvB+xJ38OCwrjSwCR5S7xtweikb8_NLA@mail.gmail.com>


New submission from mani and ram <maniandram01 at gmail.com>:

-----------------------------------------------------------------------

maniandram maniandram wants to stay in touch better using some of
Google's great new products. If you already have Gmail or Google Talk,
visit: http://mail.google.com/mail/b-a8ddcdef74-d9b3235799-jT0tC3HAEHyo_AwNuC2Pc1oJ4P0
You'll need to click this link to be able to chat with maniandram
maniandram. To get Gmail - a free email account from Google with over
2,800 megabytes of storage - and chat with maniandram maniandram,
visit: http://mail.google.com/mail/a-a8ddcdef74-d9b3235799-jT0tC3HAEHyo_AwNuC2Pc1oJ4P0
Gmail offers: - Instant messaging directly inside Gmail - Powerful
spam protection - Built-in search for finding your messages and a
helpful way of organising emails into "conversations" - No pop-up ads
or untargeted banners - just text ads and related information that are
relevant to the content of your messages All this, and it's yours for
free. But wait, there's more! By opening a Gmail account, you also
have access to Google Talk, Google's instant messaging service:
http://www.google.com/talk/intl/en-GB/ Google Talk offers: - Web-based
chat that you can use anywhere, without a download - A contact list
that's synchronised with your Gmail account - Free, high-quality
PC-to-PC voice calls when you download the Google Talk client We're
working hard to add new features and make improvements, so we may also
ask for your comments and suggestions periodically. We appreciate your
help in making our products even better! Thanks, The Google Team To
learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/intl/en_GB/about.html
http://www.google.com/talk/intl/en-GB/about.html (If clicking the URLs
in this message does not work, copy and paste them into the address
bar of your browser).

----------
messages: 150219
nosy: maniandram
priority: normal
severity: normal
status: open
title: maniandram maniandram wants to chat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13660>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:44:46 2011
From: report at bugs.python.org (mani and ram)
Date: Sat, 24 Dec 2011 07:44:46 +0000
Subject: [issue13661] maniandram maniandram wants to chat
Message-ID: <CAExgZOiRTZh7vhxZEfjA2z+rYiHNEhz4YyMLmsAsHDaoowN86w@mail.gmail.com>


New submission from mani and ram <maniandram01 at gmail.com>:

-----------------------------------------------------------------------

maniandram maniandram wants to stay in touch better using some of
Google's great new products. If you already have Gmail or Google Talk,
visit: http://mail.google.com/mail/b-a8ddcdef74-00d3fc0b9c-JWXaXVhq1RAj9Ddx82oOpmk1-4Y
You'll need to click this link to be able to chat with maniandram
maniandram. To get Gmail - a free email account from Google with over
2,800 megabytes of storage - and chat with maniandram maniandram,
visit: http://mail.google.com/mail/a-a8ddcdef74-00d3fc0b9c-JWXaXVhq1RAj9Ddx82oOpmk1-4Y
Gmail offers: - Instant messaging directly inside Gmail - Powerful
spam protection - Built-in search for finding your messages and a
helpful way of organising emails into "conversations" - No pop-up ads
or untargeted banners - just text ads and related information that are
relevant to the content of your messages All this, and it's yours for
free. But wait, there's more! By opening a Gmail account, you also
have access to Google Talk, Google's instant messaging service:
http://www.google.com/talk/intl/en-GB/ Google Talk offers: - Web-based
chat that you can use anywhere, without a download - A contact list
that's synchronised with your Gmail account - Free, high-quality
PC-to-PC voice calls when you download the Google Talk client We're
working hard to add new features and make improvements, so we may also
ask for your comments and suggestions periodically. We appreciate your
help in making our products even better! Thanks, The Google Team To
learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/intl/en_GB/about.html
http://www.google.com/talk/intl/en-GB/about.html (If clicking the URLs
in this message does not work, copy and paste them into the address
bar of your browser).

----------
messages: 150220
nosy: maniandram
priority: normal
severity: normal
status: open
title: maniandram maniandram wants to chat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13661>
_______________________________________

From report at bugs.python.org  Sat Dec 24 09:22:00 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 08:22:00 +0000
Subject: [issue13661] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOiRTZh7vhxZEfjA2z+rYiHNEhz4YyMLmsAsHDaoowN86w@mail.gmail.com>
Message-ID: <1324714920.62.0.886071903731.issue13661@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Sorry, accident.
Please delete.

----------
nosy: +maniram.maniram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13661>
_______________________________________

From report at bugs.python.org  Sat Dec 24 09:22:38 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 08:22:38 +0000
Subject: [issue13660] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOgNvv-h1cur3qVvB+xJ38OCwrjSwCR5S7xtweikb8_NLA@mail.gmail.com>
Message-ID: <1324714958.33.0.555749333943.issue13660@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
nosy: +maniram.maniram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13660>
_______________________________________

From report at bugs.python.org  Sat Dec 24 09:23:02 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 08:23:02 +0000
Subject: [issue13660] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOgNvv-h1cur3qVvB+xJ38OCwrjSwCR5S7xtweikb8_NLA@mail.gmail.com>
Message-ID: <1324714982.94.0.375599581415.issue13660@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Sorry, accident.
Please delete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13660>
_______________________________________

From report at bugs.python.org  Sat Dec 24 09:24:08 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 08:24:08 +0000
Subject: [issue13661] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOiRTZh7vhxZEfjA2z+rYiHNEhz4YyMLmsAsHDaoowN86w@mail.gmail.com>
Message-ID: <1324715048.49.0.84520305984.issue13661@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Please close this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13661>
_______________________________________

From report at bugs.python.org  Sat Dec 24 09:25:14 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 08:25:14 +0000
Subject: [issue13660] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOgNvv-h1cur3qVvB+xJ38OCwrjSwCR5S7xtweikb8_NLA@mail.gmail.com>
Message-ID: <1324715114.55.0.350713444223.issue13660@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Please close this bug as invalid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13660>
_______________________________________

From report at bugs.python.org  Sat Dec 24 09:26:05 2011
From: report at bugs.python.org (maniram maniram)
Date: Sat, 24 Dec 2011 08:26:05 +0000
Subject: [issue13660] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOgNvv-h1cur3qVvB+xJ38OCwrjSwCR5S7xtweikb8_NLA@mail.gmail.com>
Message-ID: <1324715165.56.0.713872553606.issue13660@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

I can't edit this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13660>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:32:46 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Dec 2011 09:32:46 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324719166.02.0.255127595019.issue13644@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:33:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Dec 2011 09:33:25 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324719205.1.0.320399947449.issue13644@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
Removed message: http://bugs.python.org/msg150226

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:33:41 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Dec 2011 09:33:41 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324719221.64.0.751168636781.issue13644@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> Nothing, but that would be pointless; the recursion would just start again.

Why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 11:16:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Dec 2011 10:16:26 +0000
Subject: [issue13660] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOgNvv-h1cur3qVvB+xJ38OCwrjSwCR5S7xtweikb8_NLA@mail.gmail.com>
Message-ID: <1324721786.92.0.990185078026.issue13660@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13660>
_______________________________________

From report at bugs.python.org  Sat Dec 24 11:16:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Dec 2011 10:16:35 +0000
Subject: [issue13661] maniandram maniandram wants to chat
In-Reply-To: <CAExgZOiRTZh7vhxZEfjA2z+rYiHNEhz4YyMLmsAsHDaoowN86w@mail.gmail.com>
Message-ID: <1324721795.58.0.976770703238.issue13661@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13661>
_______________________________________

From report at bugs.python.org  Sat Dec 24 12:13:00 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 24 Dec 2011 11:13:00 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324725180.95.0.421405208422.issue13639@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I thought about that myself, too. It is clearly no new feature, it is really more some kind of a fix.

Unicode pathnames given to tarfile.open() are just passed through to the open() function, which is why this always has been working, except for this particular case. There are 6 different possible write modes: "w:", "w:gz", "w:bz2", "w|", "w|gz" and "w|bz2". And the only one not working with a unicode pathname is "w|gz". Although admittedly tarfile.open() is not supposed to be used with a unicode path, people do it anyway, because they don't care, and because it works. The patch does not add a new broad functionality, it merely harmonises the way the six write modes work.

Neither can we retroactively enforce using string pathnames at this point, nor should we let a user run into this strange error. The patch is very small and minimally invasive. The error message you get without the patch is completely incomprehensible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Sat Dec 24 15:50:17 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Dec 2011 14:50:17 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324719221.64.0.751168636781.issue13644@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o9o3ijNXD0Z8vU-aCO9_LMVdPvXjW7m=agEfVwwg8ch1g@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/12/24 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl <georg at python.org> added the comment:
>
>> Nothing, but that would be pointless; the recursion would just start again.

Because it would be caught in the function call above in the stack?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 15:51:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Dec 2011 14:51:22 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324738282.28.0.640923811212.issue13644@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Would it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 15:52:46 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Dec 2011 14:52:46 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324738282.28.0.640923811212.issue13644@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o8NFbkvPRPeosvmcZp34Ct_GmXsRF0Qb7xpp0aG5oz_pQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/12/24 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl <georg at python.org> added the comment:
>
> Would it?

(<class 'Exception'>,)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 15:54:09 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Dec 2011 14:54:09 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324738449.8.0.150578251711.issue13644@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Basically forget my last 3 messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 19:53:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Dec 2011 18:53:33 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1324752813.12.0.304548090878.issue11105@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +None
stage:  -> test needed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11105>
_______________________________________

From report at bugs.python.org  Sat Dec 24 19:57:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Dec 2011 18:57:45 +0000
Subject: [issue7338] recursive __attribute__ -> Fatal Python error: Cannot
	recover from stack overflow.
In-Reply-To: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>
Message-ID: <1324753065.53.0.0964606848373.issue7338@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> This is normal.

Can this be closed then?

----------
nosy: +ezio.melotti
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7338>
_______________________________________

From report at bugs.python.org  Sat Dec 24 19:58:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Dec 2011 18:58:48 +0000
Subject: [issue1953] Compact int and float freelists
In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za>
Message-ID: <1324753128.59.0.670610069057.issue1953@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -BreamoreBoy
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1953>
_______________________________________

From report at bugs.python.org  Sat Dec 24 20:00:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Dec 2011 19:00:07 +0000
Subject: [issue13413] time.daylight incorrect behavior in linux glibc
In-Reply-To: <1321429764.54.0.0162746927464.issue13413@psf.upfronthosting.co.za>
Message-ID: <1324753207.89.0.711935009057.issue13413@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13413>
_______________________________________

From report at bugs.python.org  Sat Dec 24 20:20:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Dec 2011 19:20:37 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1324754437.33.0.864896716594.issue11977@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Isn't there a way to specify multiple targets for the same entry?
The doc could say that int, float and complex all share some methods/attributes and then either list e.g. int.conjugate, float.conjugate, complex.conjugate with a single description or use just int (or even numbers.Number) and create targets for float and complex too in some other way, so that float.conjugate automatically links to the description of Number.conjugate.
I don't think it's necessary to document all methods/attributes in the same place.  These methods/attributes are not so common, so it's ok to have them documented in the numbers.Number page, for example.  A simple link to the page can then be added to the int/float/complex docs.
See also #4966 for a discussion about the reorganization of the stdtypes page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11977>
_______________________________________

From report at bugs.python.org  Sat Dec 24 20:22:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Dec 2011 19:22:24 +0000
Subject: [issue7098] g formatting for decimal types should always strip
	trailing zeros.
In-Reply-To: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
Message-ID: <1324754544.84.0.0942453566283.issue7098@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7098>
_______________________________________

From report at bugs.python.org  Sat Dec 24 20:54:47 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 24 Dec 2011 19:54:47 +0000
Subject: [issue7098] g formatting for decimal types should always strip
	trailing zeros.
In-Reply-To: <1255198932.03.0.979291900289.issue7098@psf.upfronthosting.co.za>
Message-ID: <1324756487.7.0.338613146953.issue7098@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would like to think about this one for a bit before it moves forward.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7098>
_______________________________________

From report at bugs.python.org  Sat Dec 24 21:32:45 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 24 Dec 2011 20:32:45 +0000
Subject: [issue7338] recursive __attribute__ -> Fatal Python error: Cannot
	recover from stack overflow.
In-Reply-To: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>
Message-ID: <1324758765.75.0.952220242314.issue7338@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This is related to #13644.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7338>
_______________________________________

From report at bugs.python.org  Sat Dec 24 22:42:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 21:42:54 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324762974.88.0.234061759722.issue13639@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With that explanation, that it is one case out of six that fails, for whatever reason, I agree.

That leaves the issue of whether the fix is the right one. I currently agree with Victor that we should do what the rest of Python does and what is most universally useful. That fact that an old standard requires a *storage* encoding for a nearly unused field for .gz files that (I believe) only works for Western Europe, does not mean we should use it for *opening* .tar files. WestEuro-centrism is as bad as Anglo-centrism. If the unicode filename cannot be Latin-1 encoded, the filename field should be left blank. But it seems to me that the filename should be converted to the bytes that the user wants, expects, and can use.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Sat Dec 24 23:45:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 22:45:47 +0000
Subject: [issue13644] Python 3 aborts with this code.
In-Reply-To: <1324446892.84.0.339950093932.issue13644@psf.upfronthosting.co.za>
Message-ID: <1324766747.98.0.434226583087.issue13644@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

@maniram I know what IDLE does. For the tracker, a 'bug' is a discrepancy between doc and behavior. According to the doc, a recursion loop should continue forever, just like an iteration loop ;=).

Anyway, Roger is right, this is a duplicate of #6028, which has at least a preliminary patch.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Interpreter crashes when chaining an infinite number of exceptions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13644>
_______________________________________

From report at bugs.python.org  Sat Dec 24 23:47:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 22:47:37 +0000
Subject: [issue7338] recursive __attribute__ -> Fatal Python error: Cannot
	recover from stack overflow.
In-Reply-To: <1258455694.17.0.877793280726.issue7338@psf.upfronthosting.co.za>
Message-ID: <1324766857.38.0.0850726527474.issue7338@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This seems to be a duplicate of 3555 and 6028. I am redirecting to the latter because is has a proposed patch.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Interpreter crashes when chaining an infinite number of exceptions
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7338>
_______________________________________

From report at bugs.python.org  Sat Dec 24 23:52:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 22:52:20 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1324767140.71.0.124303770143.issue3555@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is one of four essentially duplicate issues #6028, #7338, #13644.
#6028 has a proposed patch.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
versions: +Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________

From report at bugs.python.org  Sun Dec 25 00:07:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 23:07:50 +0000
Subject: [issue6028] Interpreter aborts when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1324768070.71.0.978471220055.issue6028@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe #3555, #7338, and *13644 are basically duplicates of this issue. I have left this one open because it has a try at a patch. I think any patch should be tested with the other examples.

I agree with Antoine that an intentional exit is not a crash.
I also agree that the current procedure is not really a bug either. According to the language spec, the interpreter should recurse forever;-), just like "while True: pass" iterates 'forever'. Given that it does not due to finite limitations, the exact alternate behavior is undefined.

Now, if someone can find a way to better handle infinite recursion mixed with exceptions, without re-introducing real crashes or eliminating the benefits of the 3.0 changes, great.

Yury, I think Antoine's point is that gracefully handling all the different kinds of programming mistakes in a finite system is a delicate and difficult balancing act.

----------
nosy: +terry.reedy
stage:  -> patch review
title: Interpreter crashes when chaining an infinite number of exceptions -> Interpreter aborts when chaining an infinite number of exceptions
type: crash -> behavior
versions: +Python 3.2, Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sun Dec 25 00:28:39 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 24 Dec 2011 23:28:39 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324769319.6.0.884522580528.issue2134@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> The cmdoption directive should be used with a program directive.

Ah, nice.  Thanks for the tip ?ric.

Updated patch attached along with a patch for the 2.7/3.2 doc update attached.

----------
Added file: http://bugs.python.org/file24088/tokenize-exact-type-v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Sun Dec 25 00:28:57 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 24 Dec 2011 23:28:57 +0000
Subject: [issue2134] Add new attribute to TokenInfo to report specific token
	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324769337.74.0.313223440943.issue2134@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


Added file: http://bugs.python.org/file24089/tokenize-docs-2.7-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Sun Dec 25 00:42:43 2011
From: report at bugs.python.org (Yury)
Date: Sat, 24 Dec 2011 23:42:43 +0000
Subject: [issue6028] Interpreter aborts when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1324770163.84.0.320350555879.issue6028@psf.upfronthosting.co.za>


Yury <yury.sobolev at gmail.com> added the comment:

Rather than aborting with a stack overflow, I feel it is more natural to raise an exception. If it is not too difficult to implement, perhaps another type of exception should be raised. Since chained exceptions are new to 3.x, there should be a new exception to describe errors that happen in chaining. Perhaps stopping chaining at a certain depth and truncating all further exceptions with a blanket "ChainingException" exception. Or perhaps truncating the chain and wrapping it in another exception before returning it to user code.

While this is my proposed solution, I apologize I cannot volunteer to write the patch. The time investment on my part would involve learning most of the working of the interpreter. Perhaps someone who is already familiar with it would be interested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Sun Dec 25 03:37:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Dec 2011 02:37:32 +0000
Subject: [issue13294] http.server: minor code style changes.
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1324780652.4.0.204537109336.issue13294@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The first chunk of the patch (the use of strip) changes the behavior as discussed in the previous comments, so it should probably be reverted.  The rest of the changes are OK.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Sun Dec 25 04:19:14 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Dec 2011 03:19:14 +0000
Subject: [issue6028] Interpreter aborts when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1324783154.18.0.760289730156.issue6028@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/issue6028>
_______________________________________

From report at bugs.python.org  Sun Dec 25 04:50:47 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 25 Dec 2011 03:50:47 +0000
Subject: [issue13642] urllib incorrectly quotes username and password in https
	basic auth
In-Reply-To: <1324393425.24.0.243026081887.issue13642@psf.upfronthosting.co.za>
Message-ID: <1324785047.89.0.866811474607.issue13642@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Joonas, this issue seems easy to solve. Do you want to try to post a patch?. Extra credits for patching testsuite too :).

If you work in 2.7, I promise to up-port the patch to 3.x.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13642>
_______________________________________

From report at bugs.python.org  Sun Dec 25 07:16:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 25 Dec 2011 06:16:55 +0000
Subject: [issue13294] http.server: minor code style changes.
In-Reply-To: <1324780652.4.0.204537109336.issue13294@psf.upfronthosting.co.za>
Message-ID: <20111225061647.GA1891@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The concern here is if the request line had something like this.

    Method SP Request-URI SP HTTP-Version <ANY_\r_\n_\r\n_Combination>\r\n

The previous behavior would have resulted in 

    Method SP Request-URI SP HTTP-Version <ANY_\r_\n_\r\n_Combination>

That is removing only the final \r\n, whereas the current change would make it

    Method SP Request-URI SP HTTP-Version 

That is removes all the trailing \r\n combination.

BTW, thing to note this, this is only for request line and not the header
lines.  And for request-line, both HTTP 1.0 and HTTP 1.1 spec has this in section
5.1

    5.1  Request-Line

       The Request-Line begins with a method token, followed by the
       Request-URI and the protocol version, and ending with CRLF. The
       elements are separated by SP characters. No CR or LF are allowed
       except in the final CRLF sequence.

       Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Which leads me to believe that, removing all the trailing \r\n is a fine thing
to do and should not be harmful.

Just to augment this with few other things I found while (re-)reading the spec.
This advise is different from Header's trailing whitespace, which is called
Linear White space (LWS).  If the Host Header looks like, e.g.  "Host:
www.foo.com \r\n" (notice the trailing white space), 

According to RFC 2616 (HTTP 1.1), section 4.2 Message Headers:

   The field-content does not include any leading or trailing LWS:
   linear white space occurring before the first non-whitespace
   character of the field-value or after the last non-whitespace
   character of the field-value. Such leading or trailing LWS MAY be
   removed without changing the semantics of the field value.

RFC 1945 (HTTP 1.0), section 4.2 Message Headers does not make such an explicit
statement.

My guess on the former behavior in http/server.py is that it was thought that
Request-Line was following something like section 4.2 on HTTP 1.0 spec and only
the last two characters were removed. But actually, the request-line as per
spec should have only one CRLF as end char. In the Docstring of the
BaseHTTPServer class, there is a mention about preserving the trailing
white-space, but it does not point to any authoritative reference, so I am sure
taking docstring as reference to preserve the behavior is a good idea.

Before dwelling to find the reason, I was thinking if reverting the patch in
2.7 and 3.1 would be a good idea.  But give that change has support from older
specs to new ones, I am inclined to think that leave the change as such
(without reverting) should be fine as well. 

Only if we find a stronger backwards compatibility argument for leaving
trailing \r\n in request-line, then we should remove it in 2.7 and 3.2,
otherwise we can leave it as such.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Sun Dec 25 11:25:55 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Dec 2011 10:25:55 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1324808755.37.0.247661731988.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Any comments on the last patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Sun Dec 25 12:26:26 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 25 Dec 2011 11:26:26 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324812386.49.0.433530613029.issue13639@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I think we should wrap this up as soon as possible, because it has already absorbed too much of our time. The issue we discuss here is a tiny glitch triggered by a corner-case. My original idea was to fix it in a minimal sort of way that is backwards-compatible.

There are at least 4 different solutions now:

1. Keep the patch.
2. Revert the patch, leave everything as it was as wontfix.
3. Don't write an FNAME field at all if the filename that is passed is a unicode string.
4. Rewrite the FNAME code the way Terry suggests. This seems to me like the most complex solution, because we have to fix gzip.py as well, because the code in question was originally taken from the gzip module. (BTW, both the tarfile and gzip module discard the FNAME field when a file is opened for reading.)

My favorites are 1 and 3 ;-)

----------
assignee:  -> lars.gustaebel
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Sun Dec 25 18:00:47 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 25 Dec 2011 17:00:47 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324812386.49.0.433530613029.issue13639@psf.upfronthosting.co.za>
Message-ID: <7E79234E600438479EC119BD241B48D6A5D707@CH1PRD0602MB098.namprd06.prod.outlook.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I also feel (1) or (3) is best for this issue. If there is a _better_ 
implementation, it should be reserved for a separate improvement to Python 
3.2+.

I lean slightly toward (3) because it would support filenames with Unicode 
characters other than latin-1 (as long as the file system allows it to be 
saved), because I suspect it would enable tests such as this to pass: 
https://bitbucket.org/jaraco/cpython-issue11638/changeset/9e9ea96eb0dd#chg-Lib/distutils/tests/test_archive_util.py

----------
Added file: http://bugs.python.org/file24090/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6662 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20111225/6c9d9d8d/attachment.bin>

From report at bugs.python.org  Mon Dec 26 01:13:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Dec 2011 00:13:06 +0000
Subject: [issue6028] Interpreter aborts when chaining an infinite number of
	exceptions
In-Reply-To: <1242376180.99.0.271687505005.issue6028@psf.upfronthosting.co.za>
Message-ID: <1324858386.96.0.0326305920704.issue6028@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I concur with Antoine on this one.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6028>
_______________________________________

From report at bugs.python.org  Mon Dec 26 02:16:21 2011
From: report at bugs.python.org (Tigger Level-5)
Date: Mon, 26 Dec 2011 01:16:21 +0000
Subject: [issue13033] Add shutil.chowntree
In-Reply-To: <1320508901.06.0.340386288538.issue13033@psf.upfronthosting.co.za>
Message-ID: <CAOp_GPgDw8a6TFBhrkOdBn-=-=DE73SZn-o7C_C6J4u=HF5xAQ@mail.gmail.com>


Tigger Level-5 <a.wild.tigger at gmail.com> added the comment:

Hi ?ric,

Apologies for the late response, attached is the patch. Let me know if
I need any changes or anything else.

Best,
Tigger

On Sat, Nov 5, 2011 at 11:01 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Tigger: Could you provide a patch for Python 3.3? (more info at http://docs.python.org/devguide/)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13033>
> _______________________________________

----------
keywords: +patch
Added file: http://bugs.python.org/file24091/chowntree.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13033>
_______________________________________
-------------- next part --------------
diff -r 2b47f0146639 Doc/library/shutil.rst
--- a/Doc/library/shutil.rst	Sun Sep 25 17:36:31 2011 +0200
+++ b/Doc/library/shutil.rst	Mon Sep 26 17:18:43 2011 -0500
@@ -196,6 +196,33 @@
 
    .. versionadded:: 3.3
 
+.. function:: chowntree(path, user=None, group=None, followlinks=False)
+
+   Change owner *user* and/or *group* of the given *path* and all contents recursively.
+
+   *user* can be a system user name or a uid; the same applies to *group*. At
+   least one argument is required.
+
+   See also :func:`os.chown` and :func:`os.walk`, the underlying functions.
+
+   By default, :func:`walk` will not walk down into symbolic links that resolve to
+   directories. Set *followlinks* to ``True`` to visit directories pointed to by
+   symlinks, on systems that support them.
+
+   .. note::
+
+      Be aware that setting *followlinks* to ``True`` can lead to infinite recursion if a
+      link points to a parent directory of itself. This is due to the fact that the underlying
+      function :func:`os.walk` does not keep track of
+      the directories it visited already.
+
+   .. note::
+
+      If there is an error with the underlying :func:`os.walk` method, then any files whose
+      ownership was successfully changed will be reverted back to the original ownership.
+
+   Availability: Unix.
+
 
 .. exception:: Error
 
diff -r 2b47f0146639 Lib/shutil.py
--- a/Lib/shutil.py	Sun Sep 25 17:36:31 2011 +0200
+++ b/Lib/shutil.py	Mon Sep 26 17:18:43 2011 -0500
@@ -822,3 +822,57 @@
             raise LookupError("no such group: {!r}".format(group))
 
     os.chown(path, _user, _group)
+
+
+def chowntree(path, user=None, group=None, followlinks=False):
+    """Change owner user and group of the given path and all contents recursively.
+
+    user and group can be the uid/gid or the user/group names, and in that case,
+    they are converted to their respective uid/gid. followlinks tells us whether we should
+    follow symlinks. This may lead to infinite recursion if links loop back.
+
+    The dictionary _modified_items, will keep track of the old ownership details,
+    with keys being the full path, and values being tuples where the first element is
+    the uid and the second element is the gid. This way if there are any errors that
+    arise, we can undo any ownership changes to the old state.
+
+    """
+
+    if user is None and group is None:
+        raise ValueError("user and/or group must be set")
+
+    _user = user
+    _group = group
+
+    # -1 means don't change it
+    if user is None:
+        _user = -1
+    # user can either be an int (the uid) or a string (the system username)
+    elif isinstance(user, str):
+        _user = _get_uid(user)
+        if _user is None:
+            raise LookupError("no such user: {!r}".format(user))
+
+    if group is None:
+        _group = -1
+    elif not isinstance(group, int):
+        _group = _get_gid(group)
+        if _group is None:
+            raise LookupError("no such group: {!r}".format(group))
+
+
+    _modified_items = dict()
+    def _listdir_errorhandler(oserror):
+        for path, stat in _modified_items.items():
+            os.chown(path, stat.st_uid, stat.st_gid)
+        raise oserror
+
+    if(os.path.isdir(path)):
+        for root, dirs, files in os.walk(path, onerror = _listdir_errorhandler, followlinks = followlinks):
+            for item in (files + dirs):
+                _full_file_path = os.path.join(root, item)
+
+                stat_info = os.stat(_full_file_path)
+                os.chown(_full_file_path, _user, _group)
+                _modified_items[_full_file_path] = (stat_info.st_uid, stat_info.st_gid)
+
+    os.chown(path, _user, _group)
diff -r 2b47f0146639 Lib/test/test_shutil.py
--- a/Lib/test/test_shutil.py	Sun Sep 25 17:36:31 2011 +0200
+++ b/Lib/test/test_shutil.py	Mon Sep 26 17:18:43 2011 -0500
@@ -770,6 +770,50 @@
         check_chown(filename, uid, gid)
         shutil.chown(dirname, user, group)
         check_chown(dirname, uid, gid)
+    
+    
+    @unittest.skipUnless(UID_GID_SUPPORT, "Requires grp and pwd support")
+    @unittest.skipUnless(hasattr(os, 'chown'), 'requires os.chown')
+    def test_chowntree(self):
+
+        # cleaned-up automatically by TestShutil.tearDown method
+        dirname = self.mkdtemp()
+        filename = tempfile.mktemp(dir=dirname)
+        write_file(filename, 'testing chown function')
+
+        with self.assertRaises(ValueError):
+            shutil.chowntree(filename)
+
+        with self.assertRaises(LookupError):
+            shutil.chowntree(filename, user='non-exising username')
+
+        with self.assertRaises(LookupError):
+            shutil.chowntree(filename, group='non-exising groupname')
+
+        with self.assertRaises(TypeError):
+            shutil.chowntree(filename, b'spam')
+
+        with self.assertRaises(TypeError):
+            shutil.chowntree(filename, 3.14)
+
+        uid = os.getuid()
+        gid = os.getgid()
+
+        def check_chown(path, uid=None, gid=None):
+            s = os.stat(filename)
+            if uid is not None:
+                self.assertEqual(uid, s.st_uid)
+            if gid is not None:
+                self.assertEqual(gid, s.st_gid)
+
+        shutil.chowntree(filename, uid, gid)
+        check_chown(filename, uid, gid)
+        shutil.chowntree(filename, uid)
+        check_chown(filename, uid)
+        shutil.chowntree(filename, user=uid)
+        check_chown(filename, uid)
+        shutil.chowntree(filename, group=gid)
+        check_chown(filename, gid=gid)
 
 
 class TestMove(unittest.TestCase):

From report at bugs.python.org  Mon Dec 26 06:28:36 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 05:28:36 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324877316.25.0.0251266684431.issue11638@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24092/774933cf7775.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:38:47 2011
From: report at bugs.python.org (wang)
Date: Mon, 26 Dec 2011 05:38:47 +0000
Subject: [issue13662] os.listdir bug
Message-ID: <1324877927.54.0.312022215502.issue13662@psf.upfronthosting.co.za>


New submission from wang <zevboy at gmail.com>:

when I use os.list the return value is like this:
['some.xml', '\ufeff9158.xml']
but the file name have not the '\ufeff'.
because this problem the script can't runing.

----------
messages: 150252
nosy: guxianminer
priority: normal
severity: normal
status: open
title: os.listdir bug
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13662>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:39:30 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 05:39:30 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324877970.1.0.754580260686.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks to Lars for suggesting the fix, replacing 'w|gz' with 'w:gz'. I attempted this change in the latest revision of my fork (774933cf7775.diff). While this change does address the issue if a unicode string is passed which can be encoded using the default encoding. However, if a latin-1 string is passed or another multi-byte unicode character is passed, a UnicodeDecodeError still occurs (though now in gzip.py). Here's the test results and tracebacks:

PS C:\Users\jaraco\projects\public\cpython> python .\lib\distutils\tests\test_archive_util.py
test_check_archive_formats (__main__.ArchiveUtilTestCase) ... ok
test_compress_deprecated (__main__.ArchiveUtilTestCase) ... skipped 'The compress program is required'
test_make_archive (__main__.ArchiveUtilTestCase) ... ok
test_make_archive_cwd (__main__.ArchiveUtilTestCase) ... ok
test_make_archive_owner_group (__main__.ArchiveUtilTestCase) ... ok
test_make_tarball (__main__.ArchiveUtilTestCase) ... ok
test_make_tarball_unicode (__main__.ArchiveUtilTestCase) ... ok
test_make_tarball_unicode_extended (__main__.ArchiveUtilTestCase) ... ERROR
test_make_tarball_unicode_latin1 (__main__.ArchiveUtilTestCase) ... ERROR
test_make_zipfile (__main__.ArchiveUtilTestCase) ... ok
test_tarfile_root_owner (__main__.ArchiveUtilTestCase) ... skipped 'Requires grp and pwd support'
test_tarfile_vs_tar (__main__.ArchiveUtilTestCase) ... skipped 'Need the tar command to run'

======================================================================
ERROR: test_make_tarball_unicode_extended (__main__.ArchiveUtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".\lib\distutils\tests\test_archive_util.py", line 305, in test_make_tarball_unicode_extended
    self._make_tarball(u'??????????????????') # japanese for archive
  File ".\lib\distutils\tests\test_archive_util.py", line 64, in _make_tarball
    make_tarball(splitdrive(base_name)[1], '.')
  File "C:\Users\jaraco\projects\public\cpython\Lib\distutils\archive_util.py",
line 101, in make_tarball
    tar = tarfile.open(archive_name, 'w:%s' % tar_compression[compress])
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 1676, in open
    return func(name, filemode, fileobj, **kwargs)
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 1724, in gzopen
    gzip.GzipFile(name, mode, compresslevel, fileobj),
  File "C:\Users\jaraco\projects\public\cpython\Lib\gzip.py", line 127, in __init__
    self._write_gzip_header()
  File "C:\Users\jaraco\projects\public\cpython\Lib\gzip.py", line 172, in _write_gzip_header
    self.fileobj.write(fname + '\000')
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-5: ordinal not in range(128)

======================================================================
ERROR: test_make_tarball_unicode_latin1 (__main__.ArchiveUtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".\lib\distutils\tests\test_archive_util.py", line 297, in test_make_tarball_unicode_latin1
    self._make_tarball(u'??rchiv') # note this isn't a real word
  File ".\lib\distutils\tests\test_archive_util.py", line 64, in _make_tarball
    make_tarball(splitdrive(base_name)[1], '.')
  File "C:\Users\jaraco\projects\public\cpython\Lib\distutils\archive_util.py",
line 101, in make_tarball
    tar = tarfile.open(archive_name, 'w:%s' % tar_compression[compress])
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 1676, in open
    return func(name, filemode, fileobj, **kwargs)
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 1724, in gzopen
    gzip.GzipFile(name, mode, compresslevel, fileobj),
  File "C:\Users\jaraco\projects\public\cpython\Lib\gzip.py", line 127, in __init__
    self._write_gzip_header()
  File "C:\Users\jaraco\projects\public\cpython\Lib\gzip.py", line 172, in _write_gzip_header
    self.fileobj.write(fname + '\000')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 0:
ordinal not in range(128)

----------------------------------------------------------------------
Ran 12 tests in 0.058s

FAILED (errors=2, skipped=3)
Traceback (most recent call last):
  File ".\lib\distutils\tests\test_archive_util.py", line 311, in <module>
    run_unittest(test_suite())
  File "C:\Users\jaraco\projects\public\cpython\Lib\test\test_support.py", line
1094, in run_unittest
    _run_suite(suite)
  File "C:\Users\jaraco\projects\public\cpython\Lib\test\test_support.py", line
1077, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:48:41 2011
From: report at bugs.python.org (wang)
Date: Mon, 26 Dec 2011 05:48:41 +0000
Subject: [issue13662] os.listdir bug
In-Reply-To: <1324877927.54.0.312022215502.issue13662@psf.upfronthosting.co.za>
Message-ID: <1324878521.55.0.0738708521927.issue13662@psf.upfronthosting.co.za>


wang <zevboy at gmail.com> added the comment:

only I double click the script file generate this problem.
in IDE not this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13662>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:54:34 2011
From: report at bugs.python.org (wang)
Date: Mon, 26 Dec 2011 05:54:34 +0000
Subject: [issue13662] os.listdir bug
In-Reply-To: <1324877927.54.0.312022215502.issue13662@psf.upfronthosting.co.za>
Message-ID: <1324878874.41.0.8036530829.issue13662@psf.upfronthosting.co.za>


wang <zevboy at gmail.com> added the comment:

I mean in IDLE can run ok.
the '\ufeff' is still have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13662>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:54:37 2011
From: report at bugs.python.org (wang)
Date: Mon, 26 Dec 2011 05:54:37 +0000
Subject: [issue13662] os.listdir bug
In-Reply-To: <1324877927.54.0.312022215502.issue13662@psf.upfronthosting.co.za>
Message-ID: <1324878877.83.0.365871455851.issue13662@psf.upfronthosting.co.za>


wang <zevboy at gmail.com> added the comment:

I mean in IDLE can run ok.
the '\ufeff' is still have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13662>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:56:10 2011
From: report at bugs.python.org (wang)
Date: Mon, 26 Dec 2011 05:56:10 +0000
Subject: [issue13662] os.listdir bug
In-Reply-To: <1324877927.54.0.312022215502.issue13662@psf.upfronthosting.co.za>
Message-ID: <1324878970.65.0.590776950082.issue13662@psf.upfronthosting.co.za>


Changes by wang <zevboy at gmail.com>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13662>
_______________________________________

From report at bugs.python.org  Mon Dec 26 07:05:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Dec 2011 06:05:35 +0000
Subject: [issue13662] os.listdir bug
In-Reply-To: <1324877927.54.0.312022215502.issue13662@psf.upfronthosting.co.za>
Message-ID: <1324879535.31.0.785064796503.issue13662@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

U+FFEF is a Unicode ZERO WIDTH NO-BREAK SPACE / BYTE ORDER MARK.  I'm not sure what is it doing in the file name but this doesn't seem a bug in os.listdir.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13662>
_______________________________________

From report at bugs.python.org  Mon Dec 26 07:08:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Dec 2011 06:08:02 +0000
Subject: [issue13662] os.listdir bug
In-Reply-To: <1324877927.54.0.312022215502.issue13662@psf.upfronthosting.co.za>
Message-ID: <1324879682.21.0.457435199843.issue13662@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

s/U+FFEF/U+FEFF/
See also http://unicode.org/faq/utf_bom.html#bom1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13662>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:26:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Dec 2011 07:26:24 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324884384.82.0.750465844317.issue13639@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As I understand the patched code, it only fixes the issue for unicode names that can be latin-1 encoded and that other unicode names will raise the same exception with 'latin-1' (or equivalent) substituted for 'ascii'. So it is easy for me to anticipate a new issue reporting such someday.

I would prefer a more complete fix. If 3 is easier than 4, fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:46:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Dec 2011 07:46:51 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <1324885611.67.0.916792501152.issue13639@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I just took a look as the 3.2 tarfile code and see that it always (because self.name is always unicode) does the same encoding, with 'replace', referencing RFC1952. Although there are a few other differences, they appear inconsequential, so that the code otherwise should behave the same. Reading further on codec error handling, I gather that my previously understanding was off; non-Latin1 chars will just all appear as '?' instead of raising an exception. While that is normally useless, it does not matter since the result is not used. So I agree to call this fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Mon Dec 26 13:50:09 2011
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2011 12:50:09 +0000
Subject: [issue13663] pootle.python.org is outdated.
Message-ID: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

I am one of Japanese translate of Python documents.
We have done translating Python 2.7 document and will start
translating Python 3.2 or 3.3.

I want to use sphinx-i18n and pootle to translate.
But http://pootle.python.org/ is very outdated.
Anyone can update the site?
If nobody maintain the site, could I create Python Document project at http://pootle.locamotion.org/ ?

----------
assignee: docs at python
components: Documentation
messages: 150261
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: pootle.python.org is outdated.
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:55:25 2011
From: report at bugs.python.org (Stefano Rivera)
Date: Mon, 26 Dec 2011 14:55:25 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1324911325.76.0.194745027976.issue13508@psf.upfronthosting.co.za>


Changes by Stefano Rivera <python at rivera.za.net>:


----------
nosy: +stefanor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:42:39 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 26 Dec 2011 15:42:39 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1324914159.3.0.975247939198.issue12760@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

C11 uses 'x' for this, for what it's worth.

This is not a "duplicate issue". The openat solution is no easier than the os.open solution.

----------
nosy: +Devin Jeanpierre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:46:40 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 26 Dec 2011 15:46:40 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1324914400.99.0.59041064628.issue13508@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:48:47 2011
From: report at bugs.python.org (Michael P. Reilly)
Date: Mon, 26 Dec 2011 15:48:47 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1324914527.39.0.446707819144.issue12463@psf.upfronthosting.co.za>


Michael P. Reilly <arcege at gmail.com> added the comment:

Here is a patch to socketserver.py which can be applied to 2.6, 2.7 and 3.2.  The fix is for BaseServer, ForkingMixIn and ThreadingMixIn.  All three now correctly respond to the shutdown method.  I have no way of testing Windows or MacOSX (based on docs, MacOSX should work without changes); the ForkingMixIn will raise an AssertionError on non-POSIX systems.  There may be a better way of handling non-POSIX systems, but again, I'm not able to test or develop at this time.  I'll also update the simpletest.py script.

----------
versions: +Python 3.2
Added file: http://bugs.python.org/file24093/socketserver.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:52:19 2011
From: report at bugs.python.org (Michael P. Reilly)
Date: Mon, 26 Dec 2011 15:52:19 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1324914739.95.0.367664376305.issue12463@psf.upfronthosting.co.za>


Michael P. Reilly <arcege at gmail.com> added the comment:

An update test program.  Execute with appropriate PYTHONPATH (to dir to patched module and explicit interpreter executable: PYTHONPATH=$PWD/2.7/b/Lib python2.7 $PWD/simpletest.py

----------
Added file: http://bugs.python.org/file24094/simpletest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:55:32 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 15:55:32 +0000
Subject: [issue13664] UnicodeEncodeError in gzip when filename contains
	non-ascii
Message-ID: <1324914932.64.0.469258692044.issue13664@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

While investigating #11638, I encountered another encoding issue related to tarballs. Consider this command:

python -c "import gzip; gzip.GzipFile(u'\xe5rchive', 'w', fileobj=open(u'\xe5rchive', 'wb'))"

When run, it triggers the following traceback:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\python\lib\gzip.py", line 127, in __init__
    self._write_gzip_header()
  File "c:\python\lib\gzip.py", line 172, in _write_gzip_header
    self.fileobj.write(fname + '\000')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 0: ordinal not in range(128)

Based on the resolution of #13639, I believe the recommended fix is to handle unicode here much like Python 3 does--specifically, detect unicode, encode to 'latin-1' if possible or leave the filename blank if not.

----------
messages: 150265
nosy: jason.coombs
priority: low
severity: normal
status: open
title: UnicodeEncodeError in gzip when filename contains non-ascii
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13664>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:55:42 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 15:55:42 +0000
Subject: [issue13664] UnicodeEncodeError in gzip when filename contains
	non-ascii
In-Reply-To: <1324914932.64.0.469258692044.issue13664@psf.upfronthosting.co.za>
Message-ID: <1324914942.83.0.14354585334.issue13664@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13664>
_______________________________________

From report at bugs.python.org  Mon Dec 26 17:03:01 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 16:03:01 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324915381.13.0.021911248491.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've captured the cause of the UnicodeEncodeErrors as #13664.

After rebasing the changes to include the fix for #13639, I found that the tests were still failing until I also reverted the patch to call tarfile.open with 'w:gz'. Now all the new tests pass (with no other changes to the code).

This latest patch only contains tests to capture the errors encountered. I plan to push this changeset and also port the test changes the default (Python 3.3) branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 26 17:03:23 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 16:03:23 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324915403.16.0.339484398359.issue11638@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file24095/dc1045d08bd8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:22:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Dec 2011 17:22:38 +0000
Subject: [issue13639] UnicodeDecodeError when creating tar.gz with unicode name
In-Reply-To: <1324344204.12.0.0255632574169.issue13639@psf.upfronthosting.co.za>
Message-ID: <E1RfEFu-0007VK-Vc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dc1045d08bd8 by Jason R. Coombs in branch '2.7':
Issue #11638: Adding test to ensure .tar.gz files can be generated by sdist command with unicode metadata, based on David Barnett's patch.
http://hg.python.org/cpython/rev/dc1045d08bd8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13639>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:22:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Dec 2011 17:22:38 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <E1RfEFu-0007VK-VL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dc1045d08bd8 by Jason R. Coombs in branch '2.7':
Issue #11638: Adding test to ensure .tar.gz files can be generated by sdist command with unicode metadata, based on David Barnett's patch.
http://hg.python.org/cpython/rev/dc1045d08bd8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:22:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Dec 2011 17:22:51 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <E1RfEG9-0007Vj-JO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f0fcb82a88e9 by Jason R. Coombs in branch 'default':
Ported some test cases from 2.7 for #11638
http://hg.python.org/cpython/rev/f0fcb82a88e9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:30:29 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 17:30:29 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1324920629.59.0.634971676931.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Since the tests now pass, and the only changes were to the tests, I've pushed them to the master. And with that I'm marking this ticket as closed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:50:34 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 17:50:34 +0000
Subject: [issue13665] TypeError: string or integer address expected instead of
	str instance
Message-ID: <1324921834.92.0.644281007494.issue13665@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

When constructing a ctypes.c_char_p with a unicode string, a confusing error message is reported:

> python -c "import ctypes; ctypes.c_char_p('foo')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: string or integer address expected instead of str instance

Since "string" and "str" seem like essentially the same thing, the error message doesn't make sense.

This message is obviously due to the change to unicode as the default string instance in Python 3. The error message should probably be updated to read "bytes or integer address expected instead of a str instance".

It's probably also worth scanning through the ctypes codebase for similar messages.

----------
components: ctypes
messages: 150271
nosy: jason.coombs
priority: low
severity: normal
status: open
title: TypeError: string or integer address expected instead of str instance
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13665>
_______________________________________

From report at bugs.python.org  Mon Dec 26 23:01:53 2011
From: report at bugs.python.org (Stephen Kelly)
Date: Mon, 26 Dec 2011 22:01:53 +0000
Subject: [issue13666] datetime documentation typos
Message-ID: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za>


New submission from Stephen Kelly <steveire at gmail.com>:

There are several bugs on 

http://docs.python.org/library/datetime.html

Section 8.1.6 references the method rzinfo.dst(), which does not exist. Presumably this should be tzinfo.dst().

Section 8.1.4 contains an implementation of a GMT2 timezone. There seems to be a bug in the utcoffset() and dst() implementations. The timedelta(hours=2) is in the dst() implementation, but it should be in the uctoffset() implementation. 

The docs for tzinfo.utcoffset() start with 'Return offset of local time from UTC, in minutes east of UTC'. Other methods (eg dst()) also document that the unit to return should be 'minutes'. However, all code samples instead return a timedelta. The documentation I quoted should instead read 'Return offset of local time from UTC as a timedelta, or None'.

----------
assignee: docs at python
components: Documentation
messages: 150272
nosy: docs at python, steveire
priority: normal
severity: normal
status: open
title: datetime documentation typos
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13666>
_______________________________________

From report at bugs.python.org  Tue Dec 27 18:11:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Dec 2011 17:11:35 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325005895.16.0.187521489854.issue12760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> C11 uses 'x' for this, for what it's worth.
> 
> This is not a "duplicate issue". The openat solution is no easier than 
> the os.open solution.

Ok, let's re-open then. I'm not sold on the feature, but the fact C11 adds a dedicated letter mode for it could be a good excuse for us to mimick it :)

----------
resolution: duplicate -> 
status: closed -> open
superseder: io.FileIO and io.open should support openat -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Tue Dec 27 20:02:59 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 27 Dec 2011 19:02:59 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1325012579.25.0.136625041753.issue12857@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Tue Dec 27 20:04:30 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 27 Dec 2011 19:04:30 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325012670.42.0.41424797046.issue12760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Tue Dec 27 20:07:00 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 27 Dec 2011 19:07:00 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1325012820.57.0.553165360798.issue9922@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Tue Dec 27 20:08:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Dec 2011 19:08:59 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325012939.46.0.976940245955.issue13663@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Tue Dec 27 22:20:25 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Dec 2011 21:20:25 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1325020825.56.0.314217686948.issue11638@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

f0fcb82a88e9 broke bots. See http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/1374/steps/test/logs/stdio

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Tue Dec 27 22:50:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Dec 2011 21:50:45 +0000
Subject: [issue1953] Compact int and float freelists
In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za>
Message-ID: <1325022645.74.0.878603026209.issue1953@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know what the purpose of this feature is nor who the target users are. Trying to micro-manage the interpreter's resource allocation from Python code is certainly a losing battle, and does not warrant relying on implementation-specific APIs. Moreover, these days gc.collect() implicitly collects the freelists.

I therefore recommend rejecting this patch.

----------
nosy: +pitrou
resolution: accepted -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1953>
_______________________________________

From report at bugs.python.org  Wed Dec 28 00:34:34 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 27 Dec 2011 23:34:34 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1325028874.16.0.11538983827.issue12857@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Wed Dec 28 01:02:54 2011
From: report at bugs.python.org (Frank Wierzbicki)
Date: Wed, 28 Dec 2011 00:02:54 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>
Message-ID: <1325030574.5.0.0768311181337.issue13465@psf.upfronthosting.co.za>


Frank Wierzbicki <fwierzbicki at gmail.com> added the comment:

I have forked the devguide into http://hg.python.org/jython-docs/devguide/ -- this way I can merge changes from the main devguide as they make sense. DVCS FTW :) -- I guess this issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Wed Dec 28 01:03:45 2011
From: report at bugs.python.org (Frank Wierzbicki)
Date: Wed, 28 Dec 2011 00:03:45 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>
Message-ID: <1325030625.45.0.523826898061.issue13465@psf.upfronthosting.co.za>


Changes by Frank Wierzbicki <fwierzbicki at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:04:37 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 28 Dec 2011 02:04:37 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if
	version	is unicode
In-Reply-To: <1325020825.56.0.314217686948.issue11638@psf.upfronthosting.co.za>
Message-ID: <A810E6CA-C978-4308-9384-4D28CF8BAC36@jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> That's a shame. I tested it in advance. I'll correct or revert tonight or tomorrow.

----------
title: python setup.py sdist --formats tar* crashes if version is unicode -> python setup.py sdist --formats tar* crashes if version	is unicode
Added file: http://bugs.python.org/file24096/smime.p7m

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________
-------------- next part --------------
Content-Type: multipart/signed; micalg=sha1;
	boundary="Apple-Mail-FA56491B-2C01-4E22-9020-A26B2780291D";
	protocol="application/pkcs7-signature"

--Apple-Mail-FA56491B-2C01-4E22-9020-A26B2780291D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> That's a shame. I tested it in advance. I'll correct or revert tonight or t=
omorrow.

--Apple-Mail-FA56491B-2C01-4E22-9020-A26B2780291D
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVrjCCBjQw
ggQcoAMCAQICASIwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDMzM1oX
DTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeLZOVfItiuP1aRHL530E7QUc9icCwL33+P
H+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72jtzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+
PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBf
W/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBot
ehAX6DbDOuYoJtVxmGof6GuVGcPo98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcC
y3T8LvSs3DLl8zAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAABznBL1seNF
AhfG5hdukfQLzqsDJ452dB9CVqgUeTobh4x55PngizYKZ6+ieVlDtPd2MB7U2ck6L7tyMxMpvRoa
74Sokhl5ZgwTQZb7xB9rKoUPxygFX2biNm+r+l04+COmJGb02iLSPR9OFgqhk5qNK83IpT8QJD5V
XP7heTH3TdHGFWXimRYGXBmuVOXEpXYaZjn7syQuXr7k4RZuFp32FOzfzTBrZWDgixjJB+OJkMfp
yu6GvEXeYWrks+ILjHt78VUj8DHxB2i6JTkmA51vR181KEiAYtZbiDK21UgncNxEIeU3b0vhpE4c
KT5kcZaXFK58fLRthoHae6br4lQsZIMEbHhScnzH9uAg3qL7AGBILDwu6iasejOhkoSp6opZDeUS
UfEPE0tHwKFur3Ts1K52EyXBAr1aA67ECgL9ka2yPt1YA/mj7frpI9li/F311dn7+pHT1C3lFPRR
zOc6i9gAXjBOWJq+Yl0dSubTn2xVdS+swwfjR0uLWqoSH9Hra4sXDHxslb/KaDXJw8g1EvBzgP0Z
UHolzyrDgvwL/WOuLWek6koXP89CRPuWtC0iC/vZ4IcCgGuhniwYV4XhrdAW9FKlKdRi8SEBGYpV
QiCPVhC5wF2oQvsEs6szAThCuamfAmZnFCUBdCcVTXQuX/OXoQe4Fl70ePaZhjS6MIIHpTCCBo2g
AwIBAgICALswDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MTExMjQwODIzMjZaFw0xMzExMjUwMTQ2NDBaMIGfMSAwHgYDVQQNExc1NzQwMDMtZENER0JlOGhC
NVQ1UTVWcjELMAkGA1UEBhMCVVMxHTAbBgNVBAgTFERpc3RyaWN0IG9mIENvbHVtYmlhMRMwEQYD
VQQHEwpXYXNoaW5ndG9uMRgwFgYDVQQDEw9KYXNvbiBSLiBDb29tYnMxIDAeBgkqhkiG9w0BCQEW
EWphcmFjb0BqYXJhY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtIz2vssW
Ao03XQ0a/2nhvrtEXgzBiIorvVjpqug/KtFOCmfQUTf6Syvx3YVcALdVWoSPR9ZVJr9MlcatsqYi
5uEUX+k3x7fTYzcnK43GFIEnr16ahIfXO/Gm6WzxzRFvku+6fxzj9Eogutvk1nPd7GviModadzjO
jYxDcq9ZeFFc8QvUxp1gUwv8Bp8KQsWDTM25G6P/I8k+9p9mSnRVWcBpY9QkAOPK/wKFJcxle+sj
xcdbV6hwHZMRzMfzeouD6+OWyYfkDplII0RLFCrWgrOnAX5gufkQLcm+M0a/hedZLhkHP9/P/IVj
txcotoyqOTOJnJihfxOoASWpq0rb6QIDAQABo4ID+jCCA/YwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHApdr6WTS4rXR9eil
zbBGH8yIpDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zBqBgNVHREEYzBhgRFqYXJh
Y29AamFyYWNvLmNvbYERamFyYWNvQGphcmFjby5jb22BEWphcmFjb0Bjcy5ubXQuZWR1gRBqYXJh
Y29AZ21haWwuY29tgRRqYXJhY29Ac3BlYWtlYXN5Lm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYL
KwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp
Y3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD
AgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3Mg
MyBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxp
YW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy
ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBs
aW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRD
b20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEu
c3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhho
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj5oD4GgcCRCQcnaaRB
8+UyCkPMmJCaXvsRPseEv+zozL0Iq/s3Uj1sMir9W+vK74q22kPxvuaPnTUTePa6m/y4RpQpIh/Y
d3WkaeHtM2zvIXpeK2FsoOObIWo71yR18uyttTIQOEbg94ZYriIReBkob0jhUq35wzpqoxURSB+2
IRQ1Wwpgft7PjO/0e1yuHPuXtg5i7FlupZqCyo9NuIbWi1ZMaRl22V9b4hjQaxCAU4W/unqoQgY3
Lhz2Zz5YmXsbKGdIYIpKmRGqXE55RawY0uZc/7FqKfP3NQHp50srze53tkA5Rc27WtWOCD2FrEdn
PTflmqnf43IikwO43CgwggfJMIIFsaADAgECAgEBMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0wNjA5MTcxOTQ2MzZaFw0zNjA5MTcxOTQ2MzZaMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAMGI2wm8bEZ8eJ+Ve7UzkPJyYtbBNiAiJF7O6XfyQwqiBmSk
zI42+DjmI/BubbE83XKjhRyh0z20MyvTL6/+6rBBWWe2xAZ9Cp50hdZ5TIA3et85BVJZ9/QbRkOk
0oWF0sNx83ViNLosin8ej+7tNNARx5bNUj26M9bdTd4LO0pLn8ImL/q1FhxyNXfKPF3myuEmixo2
dlwB23QUJf7ttaCID914yi0fB5cwAS1yefpG1hMqqLmmq4NJHeXy793kAY4YCo9jUxaFYqkOGTrM
tWamwmt0B+Qr4XY+tG3Y9kThc2IfO8S+oFNWJWxRCfeqq8q/dv1tm/Od2789ZrwMVqqvmEiVOkvf
p1hQ2Th1qVvqQwwC/5nr6GxNcFspZZzdql3MrwEx7Azr0o3o6px75m73J2YMGkjXbkLjP94hPnvh
DXD7Y6qobBpUtFwlesmiyYsWprssfhdeBU1YbhIdAe4SEA3GMn8Y//z0+s1ukeg2Sb4aSGmLwpZN
GhKyaRfBCpDW+nkiSL+6e2n4cMf6ejfY2A3Sdk9X/5C345HS3e/CYLdnOt3+qpzw1It/ciLOxp+X
tviviqAQqNn7GMa2tVxSPIm2GSpzAQoPA7MSYPJ6L4Hbo27/JjCX9YvdiVe2rT2zryvFt3YC8KXW
K5qGFCpy9uMzjF0JSxPfu4x0E1JLAgMBAAGjggJSMIICTjAMBgNVHRMEBTADAQH/MAsGA1UdDwQE
AwIBrjAdBgNVHQ4EFgQUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZAYDVR0fBF0wWzAsoCqgKIYmaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3Rh
cnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEB
MIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYI
KwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggr
BgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGlt
aXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcwOAYJ
YIZIAYb4QgENBCsWKVN0YXJ0Q29tIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MA0G
CSqGSIb3DQEBBQUAA4ICAQAWbJn0Zgw09dCFXn0K7NoQTjgcXt+mJQVLkTLB6DvxPd1ECVsHSYop
y2YCt7Ga9yWYCTyOG+HdNocrS7to0zlmPaAmx/I5kR1Rq4J7ftXOWuTiA1dwaZcI+V5YpgrfjAaa
RRYWOApeV/Zix3oCBea8HrXynvSpKYP4shTjbiiHRMOQGt44qTysQ01kRc7dKKlc8nN7BPgX6Kux
8y5cZG5zMToSuLyzEeR9j4FRmjuNifRNk2Z7PAPt05odmvNlUPWg0HWfL6/w6oJDmPhpnIl5xEOO
RnLjZDYSr/clHjiJkHd+w2tqucPLREuseJCL58csHksRRMg0UifNCl2fhcGJ1Rp48pUQUzLdgIRm
ddm1aCj7YS6+hKg4wJkShqUeZ2StBi4vqXCFx5YPfIll9Y5DVA6r3aWAOZRgwDTJlnAsoxL1H0h7
vRx+a7edkPQiO674/CrK+oJSoO+vS1WT68G18CKLrDROJiIEoYcsdUq35X0T17gMZMA20skvhhKM
IwnBG4I7c0mjaleHlOXWeMWZQ2PjTeB3LeFlmXJpBBpHCeYPAVYk+x+/DnmpWC65xAkBfpW6bQAG
PrLqShA52NAr9b/sdb+XAsUJGwjcVTfigfs3hENiIMrnVktl6v5swSSTJKE06wX/miKum30/8WVR
CqYwarP0iByADfxyiuiDXjGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu
ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg
Q0ECAgC7MAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTExMTIyODAyMDQyN1owIwYJKoZIhvcNAQkEMRYEFISsIve5H3Phdr3HE0xioyAupXTh
MIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM
dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICALswgaYG
CyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgC7MA0GCSqG
SIb3DQEBAQUABIIBAIXAZC+9KmsQB4aC+yQ65UcidFL09k7PFnt+En1CjPrhL42EgHKBcgXFnvhZ
j3Z8t6F//MpyRzbWzcakHI6ifIdYAhGwGVM0chvOLxgXguDnCShxbhCps8ilhnZibw8ctG0vaHSR
D3GtHOTxdt37iybCZf8zAUPKuGQ0PCthDXkp1EqMesKYcuuhHVvW97Gh8h8+tJblDdrymZ6dJmrX
D+WTMgdtkN/d+/TF6msF91WwwsW6/7HvFX/7t8hvdzb2KimuVQ51Q4TyIzBSYYS03sE0fpUUa+wL
8/+2j62mxmqYHDSOab1S6f3uMGXNUl+xKasGdr7M6CFiC5m584njPUsAAAAAAAA=

--Apple-Mail-FA56491B-2C01-4E22-9020-A26B2780291D--

From report at bugs.python.org  Wed Dec 28 03:47:44 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Wed, 28 Dec 2011 02:47:44 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1325040464.29.0.697880015673.issue13241@psf.upfronthosting.co.za>


Nam Nguyen <bitsink at gmail.com> added the comment:

Here's a minimal test case for #define bug in LLVM GCC.

If the base struct is 8-byte long or smaller, the code runs correctly.

gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

========
#include <stdio.h>
#include <stdlib.h>

typedef struct {
    int padding;  /* remove this and the sizes will be the same */
    int type;
    int attr;
} struct_a;

typedef struct {
    struct_a base;
    int junk;
} struct_b;

#define BUG(op) \
    ((((struct_a*)(op))->type) ? (void*)((struct_a*)(op) + 1) : \
                                 (void*)((struct_b*)(op) + 1))

static void* func(void* op)
{
    if (((struct_a*)(op))->type)
    {
        return (void*)((struct_a*)(op) + 1);
    }
    return (void*)((struct_b*)(op) + 1);
}

int main(int argc, char** argv)
{
    struct_b* b = malloc(sizeof(struct_b) + 2);
    struct_a* a = (struct_a*)b;
    char* p;
    a->type = 0;
    p = BUG(b);
    printf("expected: %d, actual: %d, b = %p, p = %p\n",
            sizeof(struct_b), p - (char*)b, b, p);
    p = func(b);
    printf("expected: %d, actual: %d, b = %p, p = %p\n",
            sizeof(struct_b), p - (char*)b, b, p);
    return 0;
}
========

$ ./bug
expected: 16, actual: 12, b = 0x10d7008b0, p = 0x10d7008bc
expected: 16, actual: 16, b = 0x10d7008b0, p = 0x10d7008c0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Wed Dec 28 04:07:20 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 28 Dec 2011 03:07:20 +0000
Subject: [issue13659] Add a help() viewer for IDLE's Shell.
In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za>
Message-ID: <1325041640.3.0.172714688379.issue13659@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

If you're on Linux, run this as your first command in IDLE:

    import pydoc; pydoc.pager = lambda text: pydoc.tempfilepager(pydoc.plain(text), 'xterm -e less')

If Windows: 

    import pydoc; pydoc.pager = lambda text: pydoc.tempfilepager(pydoc.plain(text), 'notepad')

All help() output for objects will now display outside of IDLE.

The Squeezer extension does something similar for output that is longer than 30 lines.

It should be possible to create a custom pager for the subprocess which communicates with IDLE to display this text. RPCProxy could be used to accomplish this in conjunction with the textView module.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13659>
_______________________________________

From report at bugs.python.org  Wed Dec 28 05:23:21 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Dec 2011 04:23:21 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1325046201.29.0.253575516993.issue12857@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

What would you use the functionality provided by this patch for?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Wed Dec 28 06:15:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Dec 2011 05:15:57 +0000
Subject: [issue13346] re.split() should behave like string.split() for
	maxsplit=0 and maxsplit=-1
In-Reply-To: <1320461196.01.0.560612390683.issue13346@psf.upfronthosting.co.za>
Message-ID: <1325049357.99.0.815153094103.issue13346@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with closing this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13346>
_______________________________________

From report at bugs.python.org  Wed Dec 28 07:30:48 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 28 Dec 2011 06:30:48 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1325053848.06.0.508640528539.issue12857@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

My response to a similar query:

What it enables is the ability to introspect the *actual* function object belonging to the currently executing code, whether in the same execution frame or in a later one on the stack.  We don't have that now.  The best we can do is guess, and I'm trying to refuse the temptation by building in an alternative that doesn't get in the way (and doesn't provide an attractive nuisance).

My motivation for this patch was to be able to find out, in one of my functions, what function called it and to interact with that function object.  The name or file represented in the code object on the stack didn't cut it; and decorators and function factories make the whole thing a mess.  Guido sounded rather positive to the idea, which is why I pursued it.  From Guido's post to which I linked in the issue[1]:

   > For me the use case involves determining what function called my
   > function.  Currently you can tell in which execution frame a function
   > was called, and thereby which code object, but reliably matching that
   > to a function is not so simple.  I recognize that my case is likely
   > not a general one.

   But it is a nice one. It solves some issues that pdb currently solves
   by just using a file/line reference.

Not that it necessarily matters, but I could dig up the bit of code that motivated the whole thing.  I recall it was something related to writing an enum library (a la flufl.enum).  Anyway, I'd love to see this move forward.


[1] http://mail.python.org/pipermail/python-ideas/2011-August/011062.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Wed Dec 28 08:22:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 28 Dec 2011 07:22:14 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1325056934.98.0.672019791815.issue13641@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:11:10 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 09:11:10 +0000
Subject: [issue13667] __contains__ method behavior
Message-ID: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

Hi, I'm working on a class which implements the __contains__ method but the way I would like it to work is by generating an object that will be evaluated later.

It'll return a custom object instead of True/False


class C:
    def __contains__(self, x):
        return "I will evaluate this thing later... Don't bother now"


but when I do:


>>> 1 in C()
True


It seems to evaluate the answer with bool!

Reading the docs (http://docs.python.org/py3k/reference/expressions.html#membership-test-details) It says:

"`x in y` is true if and only if `y.__contains__(x)` is true."

It looks like the docs doesn't match the code and the code is trying to mimic the behavior of lists/tuples where "x in y" is the same as

any(x is e or x == e for e in y)

and always yield True or False.

There is a reason why it is that way?


Thanks!

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 150283
nosy: JBernardo, docs at python
priority: normal
severity: normal
status: open
title: __contains__ method behavior
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:24:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 28 Dec 2011 09:24:38 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325064278.32.0.170098322305.issue13667@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

"an object is true" is a short way of saying "bool(obj) is True".  So the docs match the behavior.

Returning the actual object instead of True/False from the "in" operator is a feature request.

----------
assignee: docs at python -> 
nosy: +georg.brandl
type: behavior -> enhancement
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:29:19 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 09:29:19 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325064559.81.0.507182971978.issue13667@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

@Georg Brandl
Oh sorry, now I see... true != True

But still, why is that the default behavior? Shouldn't it use whatever the method returns?

----------
type: enhancement -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:34:24 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 09:34:24 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325064864.02.0.141839226872.issue13667@psf.upfronthosting.co.za>


Changes by Jo?o Bernardo <jbvsmo at gmail.com>:


----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 11:37:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 28 Dec 2011 10:37:11 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325068631.53.0.471070754891.issue13667@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, usually what you want *is* a boolean indicating whether the element is in the collection or not.

Being able to overload "in", mostly for metaprogramming purposes, is a request that probably nobody thought of when implementing "in".

----------
nosy: +benjamin.peterson, pitrou -docs at python
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 11:59:10 2011
From: report at bugs.python.org (Anthony Kong)
Date: Wed, 28 Dec 2011 10:59:10 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1325069950.09.0.449959639987.issue13641@psf.upfronthosting.co.za>


Changes by Anthony Kong <anthony.hw.kong at gmail.com>:


----------
nosy: +Anthony.Kong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Wed Dec 28 14:08:18 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 28 Dec 2011 13:08:18 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1325077698.96.0.950708608815.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Seems to work also on kfreebsd/debian (with eglibc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Wed Dec 28 14:18:13 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Wed, 28 Dec 2011 13:18:13 +0000
Subject: [issue13668] mute ImportError in __del__ of _threading_local module
Message-ID: <1325078293.01.0.773837635362.issue13668@psf.upfronthosting.co.za>


New submission from Zhiping Deng <kofreestyler at gmail.com>:

If python was configured without-threads:

% ./python
Python 2.7.2+ (2.7:e71e4bd45c89, Dec 28 2011, 21:03:59) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import dummy_threading as _threading
>>> a = _threading.local()
>>> del a
Exception ImportError: ImportError('No module named thread',) in <bound method local.__del__ of <_threading_local.local object at 0xb7681694>> ignored

Patch to mute this Exception:
diff --git a/Lib/_threading_local.py b/Lib/_threading_local.py
--- a/Lib/_threading_local.py
+++ b/Lib/_threading_local.py
@@ -221,7 +221,13 @@
             lock.release()
 
     def __del__(self):
-        import threading
+        try:
+            import threading
+        except ImportError:
+            import sys
+            if '_dummy_threading' in sys.modules:
+                return
+            raise
 
         key = object.__getattribute__(self, '_local__key')

----------
files: _threading_local.mute_ImportError.diff
keywords: patch
messages: 150288
nosy: Zhiping.Deng
priority: normal
severity: normal
status: open
title: mute ImportError in __del__ of _threading_local module
versions: Python 2.7
Added file: http://bugs.python.org/file24097/_threading_local.mute_ImportError.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13668>
_______________________________________

From report at bugs.python.org  Wed Dec 28 14:25:14 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 28 Dec 2011 13:25:14 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
Message-ID: <1325078714.64.0.530368798013.issue13669@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

Extended attribute support was added in issue 12720. Doesn't compile on kfreebsd/debian, which uses eglibc and gcc. The error is that the symbols XATTR_LIST_MAX and XATTR_SIZE_MAX are not defined.

After http://hg.python.org/cpython/rev/f325439d7f84 xattr compilation tests for 'defined(HAVE_SYS_XATTR_H) && defined(__GLIBC__)', but in this case this test doesn't work. Anyway, XATTR_SIZE_MAX is defined (on Linux) in <linux/limits.h>, and <sys/xattr.h> doesn't know anything about it.

(When defined XATTR_{SIZE,LIST}_MAX to 65536 like on linux to go through with the compilation, and os.listxattr('/') returns 'OSError: [Errno 78] Function not implemented'...)

----------
components: Extension Modules
messages: 150289
nosy: Arfrever, benjamin.peterson, pitrou, skrah, zbysz
priority: normal
severity: normal
status: open
title: XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 14:28:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Dec 2011 13:28:00 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1325078880.12.0.321934628507.issue13609@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/issue13609>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:13:29 2011
From: report at bugs.python.org (andrea crotti)
Date: Wed, 28 Dec 2011 14:13:29 +0000
Subject: [issue13670] Increase test coverage for pstats.py
Message-ID: <1325081609.19.0.540376222409.issue13670@psf.upfronthosting.co.za>


New submission from andrea crotti <andrea.crotti.0 at gmail.com>:

This patch increases test coverage for pstats.py from 25 to 36%.

It's my first proposed patch so sorry in advance if there are problems. Much more can be done for pstats.py (which is also not much commented) but I want to get some feedback on this first..

----------
components: Tests
files: test_pstats.diff
keywords: patch
messages: 150290
nosy: andrea.crotti
priority: normal
severity: normal
status: open
title: Increase test coverage for pstats.py
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24098/test_pstats.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13670>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:57:41 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 28 Dec 2011 14:57:41 +0000
Subject: [issue13670] Increase test coverage for pstats.py
In-Reply-To: <1325081609.19.0.540376222409.issue13670@psf.upfronthosting.co.za>
Message-ID: <1325084261.89.0.99807238339.issue13670@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy: +brian.curtin
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13670>
_______________________________________

From report at bugs.python.org  Wed Dec 28 16:12:01 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 28 Dec 2011 15:12:01 +0000
Subject: [issue13670] Increase test coverage for pstats.py
In-Reply-To: <1325081609.19.0.540376222409.issue13670@psf.upfronthosting.co.za>
Message-ID: <1325085121.23.0.0217729533988.issue13670@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't understand this comment:
+        #TODO: add more complicated tests, which might almost compile

Also, please don't use docstrings for the test methods because of unittest's "feature" to display them instead of the test method names.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13670>
_______________________________________

From report at bugs.python.org  Wed Dec 28 16:36:53 2011
From: report at bugs.python.org (andrea crotti)
Date: Wed, 28 Dec 2011 15:36:53 +0000
Subject: [issue13670] Increase test coverage for pstats.py
In-Reply-To: <1325081609.19.0.540376222409.issue13670@psf.upfronthosting.co.za>
Message-ID: <1325086613.76.0.965276622203.issue13670@psf.upfronthosting.co.za>


andrea crotti <andrea.crotti.0 at gmail.com> added the comment:

It's really hard to understand true, and if should not go in the patch in general of course.

The sense was that the only test I added is trivial, but I haven't produced something better yet.

And ok I will remove the docstrings, I was actually doing it on purpose thinking about the unittest feature, but if the name is clear enough than is better to leave the docstring out...

Another thing, I didn't want to use tempfile.mktemp to generate a temporary file, but dump_stats doesn't accept anything else, is it in general safe to use it in this case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13670>
_______________________________________

From report at bugs.python.org  Wed Dec 28 16:45:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2011 15:45:54 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if
	version	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <E1RfvhR-0006MQ-0x@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a7744f778646 by Jason R. Coombs in branch 'default':
Limit test scope to those platforms that can save the target filenames. Reference #11638.
http://hg.python.org/cpython/rev/a7744f778646

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 28 16:48:46 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 28 Dec 2011 15:48:46 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if
	version	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1325087326.99.0.836337108691.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've limited the scope of the patch to attempt to only test on those platforms that can actually create unicode-named files. I'll watch the buildbots to see if that corrects the failures (since I don't have the failing platforms available to me).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 28 16:54:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Dec 2011 15:54:44 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325078714.64.0.530368798013.issue13669@psf.upfronthosting.co.za>
Message-ID: <1325087684.58.0.242719494699.issue13669@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Are you telling me that XATTR_SIZE_MAX is defined nowhere on eglibc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:01:39 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Dec 2011 16:01:39 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325088099.0.0.160013745889.issue13667@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think the idea has some merit. I think it should be well vetted on python-ideas, though. One thing that will certianly weigh against it is that implementation would not be trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:15:40 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 28 Dec 2011 16:15:40 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1325088940.34.0.704909932897.issue5689@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/issue5689>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:19:36 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 28 Dec 2011 16:19:36 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325078714.64.0.530368798013.issue13669@psf.upfronthosting.co.za>
Message-ID: <1325089176.86.0.588337917481.issue13669@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Unless I'm completely confused, XATTR_SIZE_MAX is defined by linux kernel headers, not the libc.

On my linux debian box:
$ grep -r XATTR_SIZE_MAX -I /usr
include/linux/limits.h:#define XATTR_SIZE_MAX 65536
$ dpkg -l libc6
libc6          2.11.2-10      Embedded GNU C Library: Shared libraries
$ dpkg -S /usr/include/linux/limits.h
linux-libc-dev: /usr/include/linux/limits.h

On debian/kfreebsd grep XATTR_SIZE_MAX doesn't find anything.

On fedora 16:
$ grep -r XATTR_SIZE_MAX -I /usr
/usr/include/linux/limits.h:#define XATTR_SIZE_MAX 65536
$ rpm -qf /usr/include/linux/limits.h
kernel-headers-3.1.0-0.rc10.git0.1.fc16.x86_64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:29:25 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 28 Dec 2011 16:29:25 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325078714.64.0.530368798013.issue13669@psf.upfronthosting.co.za>
Message-ID: <1325089765.13.0.31885119023.issue13669@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Forgot to add (on the fedora box):
$ rpm -q glibc
glibc-2.14.90-13.x86_64
(The GNU libc libraries from http://www.gnu.org/software/glibc/)

So the glibc/eglibc split is not important here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:39:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Dec 2011 16:39:08 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325089176.86.0.588337917481.issue13669@psf.upfronthosting.co.za>
Message-ID: <1325090296.3447.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On my linux debian box:
> $ grep -r XATTR_SIZE_MAX -I /usr
> include/linux/limits.h:#define XATTR_SIZE_MAX 65536
> $ dpkg -l libc6
> libc6          2.11.2-10      Embedded GNU C Library: Shared libraries
> $ dpkg -S /usr/include/linux/limits.h
> linux-libc-dev: /usr/include/linux/limits.h

But linux/limits.h is included by the glibc:

$ \grep -r linux/limits.h /usr/include/
/usr/include/sys/param.h:#include <linux/limits.h>
[...]
$ \rpm -qf /usr/include/sys/param.h
glibc-devel-2.12.1-11.2.mga1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:42:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2011 16:42:41 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if
	version	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <E1RfwaM-0003VZ-EJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9b681e0c04ed by Jason R. Coombs in branch '2.7':
Limit test scope to those platforms that can save the target filenames. Reference #11638.
http://hg.python.org/cpython/rev/9b681e0c04ed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:44:24 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 28 Dec 2011 16:44:24 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if
	version	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1325090664.69.0.162723832759.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The changes to the default branch seem to have cleaned up the test failures on most platforms (still waiting on the ARM results). So I've backported the test skips to the Python 2.7 branch as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:57:12 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 28 Dec 2011 16:57:12 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325090296.3447.1.camel@localhost.localdomain>
Message-ID: <4EFB4A61.1050006@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Yes, it must be, because XATTR_SIZE_MAX is only defined in 
linux/limits.h. The problem is that with the kfreebsd kernel,
/usr/include/sys/limits.h doesn't define or include anything that 
defines XATTR_SIZE_MAX.

Maybe the test should be 'defined(HAVE_SYS_XATTR_H) && 
defined(XATTR_SIZE_MAX)'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:58:29 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 16:58:29 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325091509.16.0.812673048109.issue13667@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

I see that every other comparison operator (<, >, <=, >=, ==, !=) except for `is` work the way I expect and is able to return anything.

e.g.

>>> numpy.arange(5) < 3
array([ True,  True,  True, False, False], dtype=bool)

I didn't checked the code (and probably I'm talking nonsense), but seems like the `in` operator has an extra call to `PyObject_IsTrue` that maybe could be dropped?

Of course it can break code relying on `x in y` being True/False but it would only happen on customized classes.

Another option that won't break code is to add a different method to handle these cases. Something like "__contains_non_bool__", but that'd be a big api change.

----------
components:  -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:01:13 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Dec 2011 17:01:13 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325091509.16.0.812673048109.issue13667@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o9vEL2Be0Kj=RmKkE===usbp0_UVCQXdLNokJKxZhnrcQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/12/28 Jo?o Bernardo <report at bugs.python.org>:
>
> Jo?o Bernardo <jbvsmo at gmail.com> added the comment:
>
> I see that every other comparison operator (<, >, <=, >=, ==, !=) except for `is` work the way I expect and is able to return anything.
>
> e.g.
>
>>>> numpy.arange(5) < 3
> array([ True, ?True, ?True, False, False], dtype=bool)
>
> I didn't checked the code (and probably I'm talking nonsense), but seems like the `in` operator has an extra call to `PyObject_IsTrue` that maybe could be dropped?

I'm not sure what you're referring to, but I doubt that would do the job.

>
> Of course it can break code relying on `x in y` being True/False but it would only happen on customized classes.
>
> Another option that won't break code is to add a different method to handle these cases. Something like "__contains_non_bool__", but that'd be a big api change.

And completely hideous.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:05:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 28 Dec 2011 17:05:24 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325078714.64.0.530368798013.issue13669@psf.upfronthosting.co.za>
Message-ID: <1325091924.3.0.193541447796.issue13669@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

So the problem occurs on:

http://www.debian.org/ports/kfreebsd-gnu/


Did I get that right? Is __FreeBSD__ defined on that system?


I'm not sure though if we should start supporting hybrid systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:21:09 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCR0LDQu9C10LfQuNC9?=)
Date: Wed, 28 Dec 2011 17:21:09 +0000
Subject: [issue13671] double comma cant be parsed in config module
Message-ID: <1325092869.34.0.25240402307.issue13671@psf.upfronthosting.co.za>


New submission from ????????? ??????? <gescheit12 at gmail.com>:

In conf file:
"key?_ = ,,"
Get next exception:
  File "/usr/lib/python2.6/dist-packages/configobj.py", line 1230, in __init__
    self._load(infile, configspec)
  File "/usr/lib/python2.6/dist-packages/configobj.py", line 1306, in _load
    self._parse(infile)
  File "/usr/lib/python2.6/dist-packages/configobj.py", line 1660, in _parse
    ParseError, infile, cur_index)
  File "/usr/lib/python2.6/dist-packages/configobj.py", line 1721, in _handle_error
 raise error
configobj.ParseError: Parse error in value at line 15.

----------
components: Regular Expressions
messages: 150306
nosy: ezio.melotti, lukasz.langa, ?????????.???????
priority: normal
severity: normal
status: open
title: double comma cant be parsed in config module
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13671>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:22:55 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 17:22:55 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325092975.45.0.968032663993.issue13667@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Using my poor grep abilities I found that on Objects/typeobject.c
(I replaced some declarations/error checking from the code with ...)

static int
slot_sq_contains(PyObject *self, PyObject *value) {
    ...
    func = lookup_maybe(self, "__contains__", &contains_str);
    if (func != NULL) {
        ...
        res = PyObject_Call(func, args, NULL);
        ...
        if (res != NULL) {
            result = PyObject_IsTrue(res);
            Py_DECREF(res);
        }
    }
    else if (! PyErr_Occurred()) {
        /* Possible results: -1 and 1 */
        result = (int)_PySequence_IterSearch(self, value,
                                         PY_ITERSEARCH_CONTAINS);
    }
}

    
I don't know if I'm in the right place, but the function returns `int` and evaluates the result to 1 or 0 if __contains__ is found.

I also don't know what SQSLOT means, but unlike the other operators (which are defined as TPSLOT), `slot_sq_contains` is a function returning "int" while `slot_tp_richcompare` returns "PyObject *".

Why is that defined that way?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:24:01 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 28 Dec 2011 17:24:01 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325091924.3.0.193541447796.issue13669@psf.upfronthosting.co.za>
Message-ID: <4EFB50A9.6030303@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

That's the one.

No. I'm putting the complete list below.

Actually python2.5-7 and 3.2 is normally packaged by debian for
is arch, so it mostly works.

$ gcc -dM -E - < /dev/null
#define __DBL_MIN_EXP__ (-1021)
#define __UINT_LEAST16_MAX__ 65535
#define __FLT_MIN__ 1.17549435082228750797e-38F
#define __UINT_LEAST8_TYPE__ unsigned char
#define __INTMAX_C(c) c ## L
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 255
#define __WINT_MAX__ 4294967295U
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 18446744073709551615UL
#define __WCHAR_MAX__ 2147483647
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L)
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __FLT_EVAL_METHOD__ 0
#define __unix__ 1
#define __x86_64 1
#define __UINT_FAST64_MAX__ 18446744073709551615UL
#define __SIG_ATOMIC_TYPE__ int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 2
#define __UINT_FAST8_MAX__ 255
#define __DEC64_MAX_EXP__ 385
#define __INT8_C(c) c
#define __UINT_LEAST64_MAX__ 18446744073709551615UL
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __UINT_LEAST8_MAX__ 255
#define __UINTMAX_TYPE__ long unsigned int
#define __DEC32_EPSILON__ 1E-6DF
#define __unix 1
#define __UINT32_MAX__ 4294967295U
#define __LDBL_MAX_EXP__ 16384
#define __WINT_MIN__ 0U
#define __SCHAR_MAX__ 127
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __INT64_C(c) c ## L
#define __DBL_DIG__ 15
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 8
#define __USER_LABEL_PREFIX__ 
#define __GLIBC__ 1
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __FLT_EPSILON__ 1.19209289550781250000e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __DEC32_MAX__ 9.999999E96DF
#define __INT32_MAX__ 2147483647
#define __SIZEOF_LONG__ 8
#define __UINT16_C(c) c
#define __DECIMAL_DIG__ 21
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 4
#define __MMX__ 1
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 16
#define __BIGGEST_ALIGNMENT__ 16
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L)
#define __INT_FAST32_MAX__ 9223372036854775807L
#define __DBL_HAS_INFINITY__ 1
#define __DEC32_MIN_EXP__ (-94)
#define __INT_FAST16_TYPE__ long int
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __INT_LEAST32_MAX__ 2147483647
#define __DEC32_MIN__ 1E-95DF
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __SSE2_MATH__ 1
#define __PTRDIFF_MAX__ 9223372036854775807L
#define __amd64 1
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __SIZEOF_SIZE_T__ 8
#define __SIZEOF_WINT_T__ 4
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __INT_FAST64_TYPE__ long int
#define __DBL_MIN__ ((double)2.22507385850720138309e-308L)
#define __LP64__ 1
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__ 
#define __UINT16_MAX__ 65535
#define __DBL_HAS_DENORM__ 1
#define __UINT8_TYPE__ unsigned char
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.6.2"
#define __UINT64_C(c) c ## UL
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __INT32_C(c) c
#define __DEC64_EPSILON__ 1E-15DD
#define __ORDER_PDP_ENDIAN__ 3412
#define __DEC128_MIN_EXP__ (-6142)
#define __INT_FAST32_TYPE__ long int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define unix 1
#define __INT16_MAX__ 32767
#define __SIZE_TYPE__ long unsigned int
#define __UINT64_MAX__ 18446744073709551615UL
#define __INT8_TYPE__ signed char
#define __ELF__ 1
#define __FLT_RADIX__ 2
#define __INT_LEAST16_TYPE__ short int
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __UINTMAX_C(c) c ## UL
#define __SSE_MATH__ 1
#define __k8 1
#define __SIG_ATOMIC_MAX__ 2147483647
#define __SIZEOF_PTRDIFF_T__ 8
#define __x86_64__ 1
#define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF
#define __INT_FAST16_MAX__ 9223372036854775807L
#define __UINT_FAST32_MAX__ 18446744073709551615UL
#define __UINT_LEAST64_TYPE__ long unsigned int
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 9223372036854775807L
#define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL
#define __FLT_HAS_INFINITY__ 1
#define __UINT_FAST16_TYPE__ long unsigned int
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __CHAR16_TYPE__ short unsigned int
#define __PRAGMA_REDEFINE_EXTNAME 1
#define __INT_LEAST16_MAX__ 32767
#define __DEC64_MANT_DIG__ 16
#define __INT64_MAX__ 9223372036854775807L
#define __UINT_LEAST32_MAX__ 4294967295U
#define __INT_LEAST64_TYPE__ long int
#define __INT16_TYPE__ short int
#define __INT_LEAST8_TYPE__ signed char
#define __DEC32_MAX_EXP__ 97
#define __INT_FAST8_MAX__ 127
#define __INTPTR_MAX__ 9223372036854775807L
#define __SSE2__ 1
#define __LDBL_MANT_DIG__ 64
#define __DBL_HAS_QUIET_NAN__ 1
#define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1)
#define __k8__ 1
#define __INTPTR_TYPE__ long int
#define __UINT16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ int
#define __SIZEOF_FLOAT__ 4
#define __UINTPTR_MAX__ 18446744073709551615UL
#define __DEC64_MIN_EXP__ (-382)
#define __INT_FAST64_MAX__ 9223372036854775807L
#define __FLT_DIG__ 6
#define __UINT_FAST64_TYPE__ long unsigned int
#define __INT_MAX__ 2147483647
#define __amd64__ 1
#define __INT64_TYPE__ long int
#define __FreeBSD_kernel__ 1
#define __FLT_MAX_EXP__ 128
#define __ORDER_BIG_ENDIAN__ 4321
#define __DBL_MANT_DIG__ 53
#define __INT_LEAST64_MAX__ 9223372036854775807L
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ unsigned int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __SIZEOF_SHORT__ 2
#define __SSE__ 1
#define __LDBL_MIN_EXP__ (-16381)
#define __INT_LEAST8_MAX__ 127
#define __SIZEOF_INT128__ 16
#define __LDBL_MAX_10_EXP__ 4932
#define __DBL_EPSILON__ ((double)2.22044604925031308085e-16L)
#define _LP64 1
#define __UINT8_C(c) c
#define __INT_LEAST32_TYPE__ int
#define __SIZEOF_WCHAR_T__ 4
#define __UINT64_TYPE__ long unsigned int
#define __INT_FAST8_TYPE__ signed char
#define __DBL_DECIMAL_DIG__ 17
#define __DEC_EVAL_METHOD__ 2
#define __UINT32_C(c) c ## U
#define __INTMAX_MAX__ 9223372036854775807L
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLT_DENORM_MIN__ 1.40129846432481707092e-45F
#define __INT8_MAX__ 127
#define __UINT_FAST32_TYPE__ long unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __FLT_MAX__ 3.40282346638528859812e+38F
#define __INT32_TYPE__ int
#define __SIZEOF_DOUBLE__ 8
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long int
#define __DEC128_MAX_EXP__ 6145
#define __GNUC_MINOR__ 6
#define __UINTMAX_MAX__ 18446744073709551615UL
#define __DEC32_MANT_DIG__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __INT16_C(c) c
#define __STDC__ 1
#define __PTRDIFF_TYPE__ long int
#define __UINT32_TYPE__ unsigned int
#define __UINTPTR_TYPE__ long unsigned int
#define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-4931)
#define __SIZEOF_LONG_LONG__ 8
#define __LDBL_DIG__ 18
#define __FLT_DECIMAL_DIG__ 9
#define __UINT_FAST16_MAX__ 18446744073709551615UL
#define __GNUC_GNU_INLINE__ 1
#define __UINT_FAST8_TYPE__ unsigned char

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:08:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 28 Dec 2011 18:08:11 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325095691.31.0.470802724787.issue13667@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It's defined that way because it's a slot returning a bool, so it doesn't need to return anything except for 0 or 1.

Changing this to return a PyObject would mean that every extension module (i.e. module written in C) that defines a custom __contains__ would need to be adapted.  That is the non-trivial implementation that Benjamin was talking about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:15:42 2011
From: report at bugs.python.org (James B)
Date: Wed, 28 Dec 2011 18:15:42 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1325096142.86.0.306567984083.issue9334@psf.upfronthosting.co.za>


James B <skilletaudio at gmail.com> added the comment:

I have encountered this issue(python 2.7) with respect to positional arguments that begin with a dash (linux/ bash).

In the following example, the parser requires three positional arguments. I attempted to encase the arguments in single-quotes as that is expected in general to result in strings to be correctly handled (these args are API keys, so they could contain shell-unfriendly chars like - and &).

./tool.py  arg1 'arg2' '-arg3&otherstuff' 

You'll note there are no optional arguments in this example, it just boils down to a positional argument being broken up on parse.

Needless to say it was quite confusing to see the script complain after passing in what would typically be perfectly valid strings in most other apps / scripts.

Is it possible to get argparse to correctly notice and handle shell-appropriate single-quoting methods(dont break down a string that has been implied as a complete token via ' ')

As it stands, it appears I have two workaround options: 1) adopt the ./tool.py -- <postional args> convention mentioned in this thread, or 2) escape leading dashes in positional argument strings to avoid this issue.

----------
nosy: +skilletaudio

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:29:31 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 28 Dec 2011 18:29:31 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1325096971.47.0.598393204963.issue12715@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24099/23e6204efe20.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:50:11 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 28 Dec 2011 18:50:11 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1325098211.65.0.245587115602.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Added another patch fixing the issues pointed out by Antoine and Charles-Fran?ois.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Dec 28 20:20:00 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 28 Dec 2011 19:20:00 +0000
Subject: [issue13672] Add co_qualname attribute in code objects
Message-ID: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

PEP 3155 added qualified name as __qualname__ attribute in classes and functions. It would be useful if qualified name was also available as co_qualname attribute of code objects.

>>> import sys
>>> class A:
...     def f1():
...         return B.f2()
... 
>>> class B:
...     def f2():
...         return sys._getframe(1)
...
>>> A.f1.__name__
'f1'
>>> A.f1.__qualname__
'A.f1'
>>> B.f2.__name__
'f2'
>>> B.f2.__qualname__
'B.f2'
>>> frame = A.f1()
>>> frame
<frame object at 0x7f9c1adca3a0>
>>> frame.f_code
<code object f1 at 0x7f9c1ae4be40, file "<stdin>", line 2>
>>> frame.f_code.co_name
'f1'
>>> frame.f_code.co_qualname
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'code' object has no attribute 'co_qualname'


Suggested behavior:
>>> frame.f_code.co_qualname
'A.f1'

----------
components: Interpreter Core
messages: 150312
nosy: Arfrever, pitrou
priority: normal
severity: normal
status: open
title: Add co_qualname attribute in code objects
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13672>
_______________________________________

From report at bugs.python.org  Wed Dec 28 21:08:11 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 28 Dec 2011 20:08:11 +0000
Subject: [issue13672] Add co_qualname attribute in code objects
In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za>
Message-ID: <1325102891.11.0.115318435405.issue13672@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

with f_func (see #12857) you would get that for free:

>>> frame.f_func.__qualname__
'A.f1'

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13672>
_______________________________________

From report at bugs.python.org  Wed Dec 28 21:25:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Dec 2011 20:25:10 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325103910.18.0.130041681747.issue13667@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1 on this proposal.  It has everyone paying a price for a questionable feature that would benefit very few.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 21:31:29 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 28 Dec 2011 20:31:29 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325104289.42.0.674629080877.issue13667@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

For what it's worth I proposed this on -ideas a while ago, the sticking points were what does `not in` do (no one had an answer anyone was happy with for this), and do we need a way to override it from the other perspective (e.g. if I want to do `SpecialObj() in [1, 2, 3]`, is there a way to do that?).

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 21:35:04 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 28 Dec 2011 20:35:04 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1325104504.67.0.159323730632.issue12857@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/issue12857>
_______________________________________

From report at bugs.python.org  Wed Dec 28 21:36:35 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 28 Dec 2011 20:36:35 +0000
Subject: [issue13672] Add co_qualname attribute in code objects
In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za>
Message-ID: <1325104595.83.0.71089629046.issue13672@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

co_qualname could still be useful if somebody has code object without frame object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13672>
_______________________________________

From report at bugs.python.org  Wed Dec 28 22:11:25 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 28 Dec 2011 21:11:25 +0000
Subject: [issue13672] Add co_qualname attribute in code objects
In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za>
Message-ID: <1325106685.0.0.411832471872.issue13672@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

True.  I wonder, though if perhaps a co_func (as a weak ref) or co_orig_func would be better, since co_qualname would be built from the original function anyway.  Then you could call "code.co_func.func_qualname".

One sticky point is that there isn't a guarantee of one-to-one between function object and code object.  A code object could be bound to several different functions as happens with function definitions (particularly lambdas) inside comprehensions.

Also, if a code object is not associated with a function, i.e. one generated by exec, what should the qualname for the code object be?  How about, in CPython, the code objects created for classes and modules?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13672>
_______________________________________

From report at bugs.python.org  Wed Dec 28 22:11:45 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 28 Dec 2011 21:11:45 +0000
Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on
	kfreebsd/debian with eglibc
In-Reply-To: <1325078714.64.0.530368798013.issue13669@psf.upfronthosting.co.za>
Message-ID: <1325106705.81.0.640305166031.issue13669@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

[Why does roundup remove quoted text being replied to???]

On 12/28/2011 06:05 PM, Stefan Krah wrote:
> http://www.debian.org/ports/kfreebsd-gnu/
That's the one.

> Is __FreeBSD__ defined on that system?
No. I'm putting the complete list below.

> I'm not sure though if we should start supporting hybrid systems.
Actually python2.5-7 and 3.2 is normally packaged by debian for
is arch, so it mostly works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13669>
_______________________________________

From report at bugs.python.org  Wed Dec 28 22:28:27 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 28 Dec 2011 21:28:27 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1325107707.87.0.206952592251.issue13609@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/issue13609>
_______________________________________

From report at bugs.python.org  Wed Dec 28 22:35:00 2011
From: report at bugs.python.org (sbt)
Date: Wed, 28 Dec 2011 21:35:00 +0000
Subject: [issue13673] SIGINT prevents raising of exceptions unless
	PyErr_CheckSignals() called
Message-ID: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

If SIGINT arrives while a function implemented in C is executing, then it prevents the function from raising an exception unless the function first calls PyErr_CheckSignals().  (If the function returns an object (instead of NULL) then KeyboardInterrupt is raised as expected.)

For example, the following function just spins for 5 seconds before raising RuntimeError:

  static PyObject *
  testsigint_wait(PyObject *self, PyObject *arg)
  {
      clock_t start = clock();
      while (clock() - start < 5 * CLOCKS_PER_SEC) {
          /* pass */
      }
      //PyErr_CheckSignals();
      PyErr_SetNone(PyExc_RuntimeError);
      return NULL;
  }

If I call this function and press Ctrl-C before it completes, then I get the following:

  >>> import testsigint
  >>> a = testsigint.wait()
  ^C>>> print(a)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'a' is not defined

So the call failed, but no exception was raised, and the variable "a" was not set!

I would have expected RuntimeError (or KeyboardInterrupt) to be raised.  If I uncomment the PyErr_CheckSignals() line then I get RuntimeError as expected:

  >>> import testsigint
  >>> a = testsigint.wait()
  ^CTraceback (most recent call last):
    File "<stdin>", line 1, in <module>
  RuntimeError

Also, if I wrap the call in try...finally or try...except, I get a sensible "chained" traceback:

  >>> try:
  ...   testsigint.wait()
  ... finally:
  ...   print("done")
  ... 
  ^CTraceback (most recent call last):
    File "<stdin>", line 2, in <module>
  RuntimeError

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
    File "<stdin>", line 2, in <module>
  KeyboardInterrupt

(Tested under Linux and Windows with the default branch.)

----------
files: testsigint.zip
messages: 150319
nosy: sbt
priority: normal
severity: normal
status: open
title: SIGINT prevents raising of exceptions unless PyErr_CheckSignals() called
versions: Python 3.3
Added file: http://bugs.python.org/file24100/testsigint.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:20:11 2011
From: report at bugs.python.org (Anders Kaseorg)
Date: Wed, 28 Dec 2011 22:20:11 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1325110811.07.0.5298104621.issue9334@psf.upfronthosting.co.za>


Anders Kaseorg <andersk at mit.edu> added the comment:

James: That?s not related to this issue.  This issue is about options taking arguments beginning with dash (such as a2x --asciidoc-opts --safe, where --safe is the argument to --asciidoc-opts), not positional arguments beginning with dash.

Your observation isn?t a bug.  In all getopt-like parsers, -- is the only way to pass positional arguments beginning with -.  (Whether you shell-quoted the argument is irrelevant; the - is interpreted by the program, not the shell, after the shell has already stripped off the shell quoting.)

If your program doesn?t take any options and you?d like to parse positional arguments without requiring --, don?t use a getopt-like parser; use sys.argv directly.

If you still think your example is a bug, please file a separate report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:33:52 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 22:33:52 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325111632.22.0.67344477959.issue13667@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

The problem with `not in` is because it must evaluate the result. It's not just another operator like "==" and "!=".

Looks like we're suffering from premature optimization and now it would break a lot of code to make it good.

For my application, I created a different method to generate the object (Not as good as I wanted, but there's no option right now):

`MyClass().has(1)` instead of `1 in MyClass()`

So, if no one comes up with a better idea, this issue should be closed.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:35:01 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Dec 2011 22:35:01 +0000
Subject: [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325111701.02.0.906493905183.issue13667@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13667>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:36:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 28 Dec 2011 22:36:29 +0000
Subject: [issue13672] Add co_qualname attribute in code objects
In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za>
Message-ID: <1325111789.93.0.460496471746.issue13672@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/issue13672>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:37:19 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 28 Dec 2011 22:37:19 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1325111839.17.0.412312269808.issue12857@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/issue12857>
_______________________________________

From report at bugs.python.org  Thu Dec 29 00:11:17 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 28 Dec 2011 23:11:17 +0000
Subject: [issue13672] Add co_qualname attribute in code objects
In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za>
Message-ID: <1325113877.3.0.224698913253.issue13672@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13672>
_______________________________________

From report at bugs.python.org  Thu Dec 29 00:18:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Dec 2011 23:18:02 +0000
Subject: [issue9260] A finer grained import lock
In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za>
Message-ID: <1325114282.32.0.397373477094.issue9260@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New prototype with per-module import locks and deadlock avoidance.
When a deadlock due to threaded circular imports is detected, the offending import returns the partially constructed module object (as would happen in single-threaded mode).

Probably lacks a test and some cleanup.

----------
nosy: +neologix
versions: +Python 3.3 -Python 3.2
Added file: http://bugs.python.org/file24101/implock3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9260>
_______________________________________

From report at bugs.python.org  Thu Dec 29 01:34:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 00:34:35 +0000
Subject: [issue13668] mute ImportError in __del__ of _threading_local module
In-Reply-To: <1325078293.01.0.773837635362.issue13668@psf.upfronthosting.co.za>
Message-ID: <1325118875.95.0.21856958561.issue13668@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13668>
_______________________________________

From report at bugs.python.org  Thu Dec 29 01:37:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 00:37:10 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1325119030.67.0.900488972074.issue13508@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:04:18 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Thu, 29 Dec 2011 09:04:18 +0000
Subject: [issue13674] crash in datetime.strftime
Message-ID: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2

C:\Python32>python
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime(1899,12,31).strftime("%y")

The crash happens with %y but not with %Y.
The crash happens with any year < 1900.
On 2.7.2 a ValueError is raised because strftime requires year >= 1900. This is what IMHO should happen (and would have saved me a lot of time)

----------
components: Library (Lib)
messages: 150323
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: crash in datetime.strftime
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:13:43 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 29 Dec 2011 09:13:43 +0000
Subject: [issue13671] double comma cant be parsed in config module
In-Reply-To: <1325092869.34.0.25240402307.issue13671@psf.upfronthosting.co.za>
Message-ID: <1325150023.84.0.249767569874.issue13671@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Hello, Alexander. ConfigObj is an external library. It is not maintained by the core team. You can report your issue to the ConfigObj issue tracker here:

http://code.google.com/p/configobj/issues/list

----------
components: +None -Regular Expressions
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13671>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:15:10 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 29 Dec 2011 09:15:10 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1325150110.33.0.516865725159.issue13674@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

This bug can not be reproduced in Python 3.2.2 on Ubuntu.
Since Python 2.7.2 on your system raises a ValueError for dates below 1900 ,your system's strftime probably does not allow dates below 1900 (unlike Ubuntu).
Python 3.2.2's datetime.strftime should handle this error from strftime().

----------
nosy: +maniram.maniram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:45:59 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 29 Dec 2011 10:45:59 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1325155559.33.0.746088864405.issue12715@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Added file: http://bugs.python.org/file24102/8330f2045f4d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:47:33 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 29 Dec 2011 10:47:33 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1325155653.05.0.964562054936.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Added new patch with protection for the remaining UF_NODUMPs in the test case. All raised issues should be fixed now. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:12:32 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 29 Dec 2011 12:12:32 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1325160752.49.0.728262286111.issue13674@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +belopolsky, flox, haypo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:13:31 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 29 Dec 2011 12:13:31 +0000
Subject: [issue13675] IDLE won't open if it can't read recent-files.lst
Message-ID: <1325160810.98.0.295250634303.issue13675@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Reported by a user. Reported on Windows but probably not Windows specific.

If IDLE doesn't have permission to read the recent-files.lst file then it crashes. (When launched with pythonw.exe on Windows it silently fails to open with no error message to the user.)

As the recent file list isn't "core functionality", IDLE should be able to run without access to this file. 

Attached is a screenshot of the traceback when IDLE is launched from the console.

----------
components: IDLE
files: Python problem.JPG
messages: 150327
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE won't open if it can't read recent-files.lst
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24103/Python problem.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13675>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:25:24 2011
From: report at bugs.python.org (sbt)
Date: Thu, 29 Dec 2011 12:25:24 +0000
Subject: [issue13673] SIGINT prevents raising of exceptions unless
	PyErr_CheckSignals() called
In-Reply-To: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>
Message-ID: <1325161524.97.0.651561370171.issue13673@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I have tried the same with Python 2.7.1 on Linux.  The problem is the same, but one gets a partial traceback with no exception:

  >>> import sys, testsigint
  >>> testsigint.wait()
  ^CTraceback (most recent call last):
    File "<stdin>", line 1, in <module>

  >>> sys.last_value
  RuntimeError()

Both on 2.7 and 3.3 sys.last_value gives RuntimeError().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:27:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 29 Dec 2011 12:27:35 +0000
Subject: [issue13676] sqlite3: Zero byte truncates string contents
Message-ID: <1325161654.99.0.774888973707.issue13676@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

Inserting a string with embedded zero byte only inserts the string up to the first zero byte:

import sqlite3

connection = sqlite3.connect(':memory:')
cursor = connection.cursor()

cursor.execute('CREATE TABLE test (value TEXT)')
cursor.execute('INSERT INTO test (value) VALUES (?)', ('foo\x00bar',))

cursor.execute('SELECT value FROM test')
print(cursor.fetchone())
# expected output: (u'foo\x00bar',)
# actual output: (u'foo',)

Also, if there's already data inserted to a table like above with embedded zero bytes, the sqlite-API-to-Python-string conversion truncates the strings to just before the first zero byte.

Attaching a patch against 3.3 that fixes the problem. Basically, it uses PyUnicode_AsStringAndSize and PyUnicode_FromStringAndSize instead of the non-size variants.

Please review, as I'm not sure it covers each possible case.

----------
components: Library (Lib)
files: sqlite3_zero_byte.patch
keywords: needs review, patch
messages: 150329
nosy: ghaering, petri.lehtinen
priority: normal
severity: normal
status: open
title: sqlite3: Zero byte truncates string contents
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24104/sqlite3_zero_byte.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13676>
_______________________________________

From report at bugs.python.org  Thu Dec 29 14:45:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Dec 2011 13:45:49 +0000
Subject: [issue9260] A finer grained import lock
In-Reply-To: <1325114282.32.0.397373477094.issue9260@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2jfJmbJiERNWVLrnPvv75BJFoUjGnkQdXNBm6AjfueTQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

IIUC, the deadlock avoidance code just checks that acquiring a
per-module lock won't create a cycle.
However, I think there's a race, because the cycle detection and the
lock acquisition is not atomic.

For example, let's say we have a thread exactly here in in
acquire_import_lock():
        PyThread_acquire_lock(lock->lock, 1);
        /* thread inside PyEval_RestoreThread(), waiting for the GIL */
        PyEval_RestoreThread(saved);
        lock->waiters--;
    }
    assert(lock->level == 0);
    lock->tstate = tstate;

It owns the lock, but hasn't yet updated the lock's owner
(lock->tstate), so another thread calling detect_circularity() will
think that this lock is available, and will proceed, which can
eventually lead to a deadlock.

Also, I think that locks will use POSIX semaphores on systems that
support only a limited number of them (such as FreeBSD 7), and this
might fail in case of nested imports (the infamous ENFILE). I'd have
to double check this, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9260>
_______________________________________

From report at bugs.python.org  Thu Dec 29 15:58:58 2011
From: report at bugs.python.org (sbt)
Date: Thu, 29 Dec 2011 14:58:58 +0000
Subject: [issue13673] PyTraceBack_Print() fails if signal received but
	PyErr_CheckSignals() not called
In-Reply-To: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>
Message-ID: <1325170738.51.0.253695334658.issue13673@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I think I have found the problem.  PyTraceBack_Print() calls PyFile_WriteString(), which calls PyFile_WriteObject(), which calls PyObject_Str() which begins with 

  PyObject_Str(PyObject *v)
  {
      PyObject *res;
      if (PyErr_CheckSignals())
          return NULL;
      ...

Since PyErr_CheckSignals() returns -1, PyTraceBack_Print() fails.

(Changed title.)

----------
title: SIGINT prevents raising of exceptions unless PyErr_CheckSignals() called -> PyTraceBack_Print() fails if signal received but PyErr_CheckSignals() not called
type:  -> behavior
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Thu Dec 29 16:49:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 15:49:36 +0000
Subject: [issue9260] A finer grained import lock
In-Reply-To: <CAH_1eM2jfJmbJiERNWVLrnPvv75BJFoUjGnkQdXNBm6AjfueTQ@mail.gmail.com>
Message-ID: <1325173722.3325.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It owns the lock, but hasn't yet updated the lock's owner
> (lock->tstate), so another thread calling detect_circularity() will
> think that this lock is available, and will proceed, which can
> eventually lead to a deadlock.

That's true. Do you think temptatively acquiring the lock (without
blocking) would solve the issue?

> Also, I think that locks will use POSIX semaphores on systems that
> support only a limited number of them (such as FreeBSD 7), and this
> might fail in case of nested imports (the infamous ENFILE). I'd have
> to double check this, though.

Isn't this limit only about named semaphores? Or does it apply to
anonymous semaphores as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9260>
_______________________________________

From report at bugs.python.org  Thu Dec 29 17:01:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 16:01:17 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1325174477.37.0.693713659917.issue12715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've checked the latest patch to work fine under Windows 7 (and Linux, of course).

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Thu Dec 29 17:54:30 2011
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 29 Dec 2011 16:54:30 +0000
Subject: [issue13675] IDLE won't open if it can't read recent-files.lst
In-Reply-To: <1325160810.98.0.295250634303.issue13675@psf.upfronthosting.co.za>
Message-ID: <1325177670.74.0.645444947071.issue13675@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This is a duplicate of issue4625 and was fixed.

The silently failing is part of issue13582.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13675>
_______________________________________

From report at bugs.python.org  Thu Dec 29 17:59:29 2011
From: report at bugs.python.org (Tim Golden)
Date: Thu, 29 Dec 2011 16:59:29 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1325177969.25.0.306968728989.issue13674@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

This is happening on Windows x86 against the current tip. The MS C runtime can handle older dates; it's just that we're taking 1900 off the year at some point. (At least, I think that's what's happening). FWIW you only need time.strftime to reproduce the error:

  import time
  time.strftime("%y", (1899, 1, 1, 0, 0, 0, 0, 0, 0))

If no-one gets there first I'll dig into the timemodule strftime wrapper.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 18:43:21 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 29 Dec 2011 17:43:21 +0000
Subject: [issue13675] IDLE won't open if it can't read recent-files.lst
In-Reply-To: <1325160810.98.0.295250634303.issue13675@psf.upfronthosting.co.za>
Message-ID: <1325180601.8.0.454199665703.issue13675@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Thanks

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13675>
_______________________________________

From report at bugs.python.org  Thu Dec 29 18:49:23 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 29 Dec 2011 17:49:23 +0000
Subject: [issue13677] correct docstring for builtin compile
Message-ID: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

The current docstring for compile suggests that the flags are strictly for selecting future statements.  These are not the only flags.

It also suggests that the source must be source code and the result will be bytecode, which isn't quite true.

I suggest changing:

"The flags argument, if present, controls which future statements influence the compilation of the code."

to:

"The flags argument, if present, largely controls which future 
statements influence the compilation of the code.  (Additional 
flags are documented in the AST module.)"

----------
assignee: docs at python
components: Documentation
files: bltinmodule.c.patch
keywords: patch
messages: 150337
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: correct docstring for builtin compile
type: behavior
Added file: http://bugs.python.org/file24105/bltinmodule.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13677>
_______________________________________

From report at bugs.python.org  Thu Dec 29 18:55:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Dec 2011 17:55:13 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <E1RgKC8-0006B8-2o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cf57ef65bcd0 by Antoine Pitrou in branch 'default':
Issue #12715: Add an optional symlinks argument to shutil functions (copyfile, copymode, copystat, copy, copy2).
http://hg.python.org/cpython/rev/cf57ef65bcd0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Thu Dec 29 18:55:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 17:55:47 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1325181347.8.0.145773630318.issue12715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch is now applied to 3.3, thank you for your patience :)

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Thu Dec 29 19:19:38 2011
From: report at bugs.python.org (sbt)
Date: Thu, 29 Dec 2011 18:19:38 +0000
Subject: [issue13673] PyTraceBack_Print() fails if signal received but
	PyErr_CheckSignals() not called
In-Reply-To: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>
Message-ID: <1325182778.7.0.783582342703.issue13673@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Attached is a patch for the default branch.

Before calling PyFile_WriteString() the patch saves the current exception.  Then it calls PyErr_CheckSignals() and clears the current exception if any.  After calling PyFile_WriteString() the exception is restored.

I am not sure this is an appropriate fix.

----------
components: +Interpreter Core
keywords: +patch
Added file: http://bugs.python.org/file24106/traceback_checksignals.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Thu Dec 29 19:20:34 2011
From: report at bugs.python.org (Tim Golden)
Date: Thu, 29 Dec 2011 18:20:34 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1325182834.62.0.846423726251.issue13674@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

... and that's because the tm struct defines the tm_year field as an offset from 1900. Sorry for the false start. I'll look at the MS runtime stuff instead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 19:40:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 18:40:10 +0000
Subject: [issue13673] PyTraceBack_Print() fails if signal received but
	PyErr_CheckSignals() not called
In-Reply-To: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>
Message-ID: <1325184010.24.0.892314977238.issue13673@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think calling PyErr_WriteUnraisable would be more appropriate than PyErr_Clear.
I also wonder whether it's ok to ignore the exception. Pressing e.g. Ctrl-C generally shouldn't fail to stop the program, even if another exception is being processed at that moment.
(of course, you could argue this is already the case when e.g. the signal is received while in a __del__)

----------
nosy: +amaury.forgeotdarc, pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Thu Dec 29 19:44:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Dec 2011 18:44:40 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1325184280.13.0.684009143455.issue13674@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

timemodule.c has the following check:

#if defined(_MSC_VER) || defined(sun)
    if (buf.tm_year + 1900 < 1 || 9999 < buf.tm_year + 1900) {
        PyErr_SetString(PyExc_ValueError,
                        "strftime() requires year in [1; 9999]");
        return NULL;
    }
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 20:08:39 2011
From: report at bugs.python.org (James Hutchison)
Date: Thu, 29 Dec 2011 19:08:39 +0000
Subject: [issue13678] way to prevent accidental variable overriding
Message-ID: <1325185719.14.0.308013470822.issue13678@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

In python is currently there a way to elegantly throw an error if a variable is already in the current scope?

For example:

def longfunc(self, filename):
    FILE = open(filename);
    header = FILE.readline();
    ... bunch of code ...
    childfiles = self.children;
    for child in childfiles:
         FILE = open(child);
         header = FILE.readline();
         ... do something with header ...
    for line in FILE:
       ... etc ...

In this case, I'm accidentally overriding the old values of FILE and header, resulting in a bug. But I'm not going to catch this. I've had a couple of real life bugs due to this that were a lot more subtle and lived for months without anyone noticing the output data was slightly wrong.

This situation could be prevented if there was a way to say something along the lines of "new FILE = open(child)" or "new header = FILE.readline()" and have python throw an error to let me know that it already exists. This would also make code clearer because it allows the intended scope of a variable to become more apparent. Since "new var = something" is a syntax error, adding this functionality wouldn't break old code, as long as python would allow for 'new' (or whatever the keyword would end up being) to also be a variable name (like "new new = 1" or "new = 1")

----------
components: Interpreter Core
messages: 150344
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: way to prevent accidental variable overriding
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13678>
_______________________________________

From report at bugs.python.org  Thu Dec 29 20:28:08 2011
From: report at bugs.python.org (Tim Golden)
Date: Thu, 29 Dec 2011 19:28:08 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325184280.13.0.684009143455.issue13674@psf.upfronthosting.co.za>
Message-ID: <4EFCBF3C.1010508@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Yes, but the MS crt strftime *for %y* requires a year >= 1900 (ie 
tm_year >= 0). Looks like we need a special check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 21:09:55 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Dec 2011 20:09:55 +0000
Subject: [issue13678] way to prevent accidental variable overriding
In-Reply-To: <1325185719.14.0.308013470822.issue13678@psf.upfronthosting.co.za>
Message-ID: <1325189395.71.0.541970672833.issue13678@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Interesting thought, the syntax seems unnecessary. Adding new syntax to the language is something that happens rarely and only with a _lot_ of consideration.

As a slightly more verbose alternative, currently you can do this:

    def fail_if_defined(*args, namespace):
        for name in args:
            if name in namespace:
                raise AlreadyBoundError(name)

And in your code you would put the following where you cared about it:
    
    fail_if_defined("FILE", "header", namespace=locals())

You could even drop the namespace parameter (since it's sort of boilerplate):

    def fail_if_defined(*args):
        namespace = inspect.currentframe().f_back.f_locals
        for name in args:
            if name in namespace:
                raise AlreadyBoundError(name)

However, if you are going to the trouble of sticking those in place (or of selectively using a new syntax), you are likely paying attention to the the situation already, rendering either solution unnecessary.

Ultimately, this is something better addressed instead by keeping your functions small, by being a little more cautious in naming, and particularly by careful unit testing.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13678>
_______________________________________

From report at bugs.python.org  Thu Dec 29 21:39:11 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Dec 2011 20:39:11 +0000
Subject: [issue13678] way to prevent accidental variable overriding
In-Reply-To: <1325185719.14.0.308013470822.issue13678@psf.upfronthosting.co.za>
Message-ID: <1325191151.45.0.649923476082.issue13678@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think this more the domain of pylint/pyflakes.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13678>
_______________________________________

From report at bugs.python.org  Thu Dec 29 21:39:48 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Thu, 29 Dec 2011 20:39:48 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1325191188.23.0.942507595212.issue7719@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Review of both patches (python-2.5.1-distutils-aixnfs.patch and dir_util.py.diff) as they are essentially the same:

I think that the test is in wrong place: we would want to ignore those .nfs* files always, not just when checking for symlinks. A separate test
at the top of the loop would be better:
    for n in names:
+       if n.startswith('.nfs'):
+           continue
        src_name = os.path.join(src, n)
        dst_name = os.path.join(dst, n)
        if preserve_symlinks and os.path.islink(src_name):


BTW: under linux 2.6.20 I see files like: .nfs000000000592413900000036, always of this length, with hexadecimal digits after .nfs).

----------
nosy: +zbysz
versions: +Python 3.3 -3rd party, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7719>
_______________________________________

From report at bugs.python.org  Thu Dec 29 22:28:42 2011
From: report at bugs.python.org (James Hutchison)
Date: Thu, 29 Dec 2011 21:28:42 +0000
Subject: [issue13678] way to prevent accidental variable overriding
In-Reply-To: <1325185719.14.0.308013470822.issue13678@psf.upfronthosting.co.za>
Message-ID: <1325194122.66.0.269945214609.issue13678@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

For starters, this would be most efficient implementation:

def unique(varname, value, scope):
    assert(not varname in scope);
    scope[varname] = value;

Usage:
unique('b', 1, locals());
print(b);

But you can't put that in a loop else it will false trigger. Ideally this wouldn't false trigger. This could be done by having python internally associate a line number with each explicit variable declaration.

Anyways, an external python function would be too slow for my use case. Likewise, since it would be something you could use a lot, it should be implemented in the underlying C code to give it minimal overhead.

Keeping functions small is very impractical at times. I shouldn't create 50 randomly named one use functions in my class as a safeguard against accidental overwriting when I have a legitimately complicated piece of code that can't be dissected without becoming unreadable. In many cases I might need 8 or 9 locals at a time in a single line in each loop section.

I don't see how this is the area of pylint/pyflakes at all. The idea is to make it so the human doesn't have to carefully inspect their code in order to decide if they made a mistake or not. Inspecting a long list of warnings is no better, and arguably I could pull up a bunch of python language design decisions and ask why they were made if pylint/pyflakes exists.

If such a change would have be implemented after much consideration and discussion, I don't see how closing my post helps accomplish that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13678>
_______________________________________

From report at bugs.python.org  Thu Dec 29 22:50:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 21:50:09 +0000
Subject: [issue13645] import machinery vulnerable to timestamp collisions
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1325195409.31.0.396254970861.issue13645@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch adding the source code size to the pyc header.
The number of places where details of the pyc file format are hard coded is surprisingly high...
Unfortunately, I had to modify importlib's public API (path_mtime -> path_stats). I find it unfortunate that importlib's API is vulnerable to pyc format changes.

----------
keywords: +patch
title: test_import fails after test_coding -> import machinery vulnerable to timestamp collisions
versions:  -Python 3.2
Added file: http://bugs.python.org/file24107/impsize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Thu Dec 29 23:02:08 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Dec 2011 22:02:08 +0000
Subject: [issue13678] way to prevent accidental variable overriding
In-Reply-To: <1325185719.14.0.308013470822.issue13678@psf.upfronthosting.co.za>
Message-ID: <1325196128.28.0.894009852151.issue13678@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I suggest you mail python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13678>
_______________________________________

From report at bugs.python.org  Thu Dec 29 23:08:55 2011
From: report at bugs.python.org (sbt)
Date: Thu, 29 Dec 2011 22:08:55 +0000
Subject: [issue13673] PyTraceBack_Print() fails if signal received but
	PyErr_CheckSignals() not called
In-Reply-To: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>
Message-ID: <1325196535.65.0.933073355806.issue13673@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> I think calling PyErr_WriteUnraisable would be more appropriate than 
> PyErr_Clear.

You mean just adding

    PyErr_CheckSignals();
    if (PyErr_Occurred())
        PyErr_WriteUnraisable(NULL);

before the call to PyFile_WriteString()?  That seems to work:

  >>> from testsigint import *; wait()
  ^CException KeyboardInterrupt ignored
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  RuntimeError

> I also wonder whether it's ok to ignore the exception. Pressing e.g. 
> Ctrl-C generally shouldn't fail to stop the program, even if another 
> exception is being processed at that moment.

The ignoring and clearing of exceptions also happens higher (lower?) in the call stack in print_exception() and print_exception_recursive().  For example, print_exception() ends with

      /* If an error happened here, don't show it.
         XXX This is wrong, but too many callers rely on this behavior. */
      if (err != 0)
          PyErr_Clear();
  }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Thu Dec 29 23:38:26 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Thu, 29 Dec 2011 22:38:26 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1325198306.53.0.729167535996.issue13674@psf.upfronthosting.co.za>


patrick vrijlandt <patrick.vrijlandt at gmail.com> added the comment:

Is it relevant that 2.7.2 _does_ throw a correct exception?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Thu Dec 29 23:39:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Dec 2011 22:39:51 +0000
Subject: [issue13676] sqlite3: Zero byte truncates string contents
In-Reply-To: <1325161654.99.0.774888973707.issue13676@psf.upfronthosting.co.za>
Message-ID: <1325198391.43.0.892737609449.issue13676@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Where are the tests? :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13676>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:26:40 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 29 Dec 2011 23:26:40 +0000
Subject: [issue13645] import machinery vulnerable to timestamp collisions
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1325201200.98.0.00198482752882.issue13645@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/issue13645>
_______________________________________

From report at bugs.python.org  Fri Dec 30 05:39:42 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 04:39:42 +0000
Subject: [issue13679] Multiprocessing system crash
Message-ID: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>


New submission from Rock Achu <rockachu2 at gmail.com>:

running this script repeatedly causes corruption in the console window. 

Just before posting this report, it led to a complete windows system freeze.

running python 2.7 x86 on windows x64.

The programs seems to run a couple times (when it is supposed to run once), with the output becoming more and more corrupted. 
One time it printed lots of triple quotes (""") and import os messages, even though none of those are in the script.

To reproduce run the spawner.test.bat file inside the zip.

Remember not to run with stuff you wont want to lose open.

----------
components: Windows
files: issue.zip
messages: 150355
nosy: Rock.Achu
priority: normal
severity: normal
status: open
title: Multiprocessing system crash
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file24108/issue.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 05:42:57 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 04:42:57 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325220177.54.0.207606985236.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

I hit Ctrl-C right after opening the bat file and got this mess:

----------
Added file: http://bugs.python.org/file24109/error.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 05:50:17 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 04:50:17 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325220617.24.0.831444089647.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

On a hunch opened task manager. There were over 9000 python processes open. Shocking. 

That was probably the cause of the system freeze.

However I only had 20 threads open. Why so many processes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 05:53:45 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 04:53:45 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325220825.03.0.0745949629871.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

Or did I only have 20 threads?
if the program was running in a loop, then it would have spawned 20 threads each, leading to the huge amount of processes, and probably the other issues.


So why does it run so many times?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:26:38 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 05:26:38 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325222798.58.0.605471618578.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

Ok, using other code, I narrowed it down to this code and before:
for i in xrange(10):
    spawner.newproc(run=True)

repeating infinitely


which only should set a variable (self.busy) to false

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:35:13 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 05:35:13 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325223313.34.0.880307417803.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

By inserting print statements and feverishly killing the process, I narrowed it down to the statement:
self.thread.start()
that causes the issue.
which runs _M_Process.func() in a multiprocessing.Process

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:36:04 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 05:36:04 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325223364.69.0.844486230708.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

More clues:

the function _M_Process.func isn't being called.


????

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:37:33 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 05:37:33 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325223453.63.0.482588587605.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

Changing the function name and removing the argument (self) passed to func doesn't change  a thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:39:33 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 05:39:33 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325223573.0.0.553234239425.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

Alright. The issue stays here. Passing nothing to multiprocessing.Process still reproduces the issue.


someone else know how to deal with this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:58:42 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 05:58:42 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325224722.95.0.491553459143.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

Alright. Just running:

import multiprocessing
thread = multiprocessing.Process()
thread.start()

raw_input()


-------------
Causes the crash. This time there is no output, so it is essentailly invisible. 
Caught me by surprise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 10:23:35 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 30 Dec 2011 09:23:35 +0000
Subject: [issue13680] Aifc comptype write fix
Message-ID: <1325237015.55.0.920988533262.issue13680@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

Two changes have been made to the library:
1. Lowercase compression type support have been added to the sample width validation routine during write operation. Everywhere else compression types are used in both lowercase and uppercase.
2. Redundant invalid compression type check has been removed. It cannot be executed using public module interface, therefore I think it is not necessary.

----------
components: Library (Lib), Tests
files: aifc_comptypes.patch
keywords: patch
messages: 150365
nosy: Oleg.Plakhotnyuk, ezio.melotti, r.david.murray
priority: normal
severity: normal
status: open
title: Aifc comptype write fix
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24110/aifc_comptypes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13680>
_______________________________________

From report at bugs.python.org  Fri Dec 30 10:24:23 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 30 Dec 2011 09:24:23 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1325237063.89.0.430882135677.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Fourth patch goes to issue 13680

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Fri Dec 30 10:38:05 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 30 Dec 2011 09:38:05 +0000
Subject: [issue13676] sqlite3: Zero byte truncates string contents
In-Reply-To: <1325161654.99.0.774888973707.issue13676@psf.upfronthosting.co.za>
Message-ID: <1325237885.05.0.210174132029.issue13676@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

What? Don't you SEE that it works correctly? :)

Attached an updated patch with a test case.

FTR, I also tried to make it possible to have the SQL statement include a zero byte, but it seems that sqlite3_prepare() (and also the newer sqlite3_prepare_v2()) always stops reading at the zero byte. See:

    http://www.sqlite.org/c3ref/prepare.html

----------
Added file: http://bugs.python.org/file24111/sqlite3_zero_byte_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13676>
_______________________________________

From report at bugs.python.org  Fri Dec 30 11:25:00 2011
From: report at bugs.python.org (Tim Golden)
Date: Fri, 30 Dec 2011 10:25:00 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325198306.53.0.729167535996.issue13674@psf.upfronthosting.co.za>
Message-ID: <4EFD9177.6000101@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Well, the code in 2.x is quite different from that in 3.x.
Specifically, the 2.x code assumes that, for Windows, no
year before 1900 is valid for any of the formats. So a
simple check throws a ValueError for tm_year < 0. For 3.x
the assumption was that Windows can handle any year as far
back as 0; in fact that's not true for the %y format.

I'll propose a patch to timemodule.c but I'll have to take
it to python-dev as I'm not 100% sure of the best place for
it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Fri Dec 30 11:42:42 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Fri, 30 Dec 2011 10:42:42 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1325241762.25.0.689061865979.issue13674@psf.upfronthosting.co.za>


patrick vrijlandt <patrick.vrijlandt at gmail.com> added the comment:

Somewhere in the code is also/still a seperate check concerning strftime:

PythonWin 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information.
>>> import datetime
>>> datetime.datetime(-1, 1, 1)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
ValueError: year is out of range
>>> datetime.datetime(0, 1, 1)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
ValueError: year is out of range
>>> datetime.datetime(1, 1, 1)
datetime.datetime(1, 1, 1, 0, 0)
>>> datetime.datetime(1, 1, 1).strftime("Y")
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
ValueError: year=1 is before 1000; the datetime strftime() methods require year >= 1000
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Fri Dec 30 11:55:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 10:55:55 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325242555.89.0.751866576559.issue13679@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, have you read http://docs.python.org/library/multiprocessing.html#windows ?
(especially "Safe importing of main module")

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 11:55:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Dec 2011 10:55:59 +0000
Subject: [issue9260] A finer grained import lock
In-Reply-To: <1325173722.3325.4.camel@localhost.localdomain>
Message-ID: <CAH_1eM0-OXdjVbrz5Fevq7jmpX+1+6LSTmR+p=VeBm3ZJ9pSAw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> That's true. Do you think temptatively acquiring the lock (without
> blocking) would solve the issue?

I think it should work. Something along those lines:

while True:
    if lock.acquire(0):
        lock.tstate = tstate
        return True
    else:
        if detect_circularity():
            return False
        global_lock.release()
        saved = save_tstate()
        yield()
        restore_tstate(saved)
        global_lock.acquire()

However, I find this whole mechanism somewhat complicated, so the
question really is: what are we trying to solve?
If we just wan't to avoid deadlocks, a trylock with the global import
lock will do the trick.
If, on the other hand, we really want to reduce the number of cases
where a deadlock would occur by increasing the locking granularity,
then it's the way to go. But I'm not sure it's worth the extra
complexity (increasing the locking granularity is usually a proven
recipe to introduce deadlocks).

> Isn't this limit only about named semaphores? Or does it apply to
> anonymous semaphores as well?

I'm no FreeBSD expert, but AFAICT, POSIX SEM_NSEMS_MAX limit doesn't
seem to make a distinction between named and anonymous semaphores.
>From POSIX sem_init() man page:
"""
[ENOSPC]
A resource required to initialise the semaphore has been exhausted, or
the limit on semaphores (SEM_NSEMS_MAX) has been reached.
"""

Also, a quick search returned those links:
http://ftp.es.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/src/sys/sys/ksem.h,v
http://translate.google.fr/translate?hl=fr&sl=ru&tl=en&u=http%3A%2F%2Fforum.nginx.org%2Fread.php%3F21%2C202865%2C202865
So it seems that sem_init() can fail when the max number of semaphores
is reached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9260>
_______________________________________

From report at bugs.python.org  Fri Dec 30 12:03:59 2011
From: report at bugs.python.org (Tim Golden)
Date: Fri, 30 Dec 2011 11:03:59 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325241762.25.0.689061865979.issue13674@psf.upfronthosting.co.za>
Message-ID: <4EFD9A80.5070908@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Yes, sorry. I wasn't clear enough. There *are* still checks
in the 3.x code (for the kind of thing you're showing). But
the checks assume 1000 <= year <= maxint is ok for all format
parameters on Windows. In fact, for %y, only 1900 <= year is ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Fri Dec 30 12:17:10 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 30 Dec 2011 11:17:10 +0000
Subject: [issue13681] Aifc read compressed frames fix
Message-ID: <1325243830.12.0.0659769703479.issue13681@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

This patch resolves two issues:

1. ADPCM compressed audio files reading. Such files have frame size of 4 bits. Aifc lib cannot represent 4 bits frame size because it uses integer bytes count variable. I have replaced it with bits count.

2. ALAW/ULAW/ADPCM audio data decompression. According to documentation (http://docs.python.org/library/audioop.html), adpcm2lin, alaw2lin and ulaw2lin are using 'width' argument to represent output frames width. However, in audioop.c module there are checks that are raising exceptions if input frames length is not multiple of 'width'. I have replaced checking of 'len' to match 'size' with checking of 'len*size' to match 'size' in order to retain only basic length validity checks.

----------
components: Library (Lib), Tests
files: aifc_compression.patch
keywords: patch
messages: 150373
nosy: Oleg.Plakhotnyuk, ezio.melotti, r.david.murray
priority: normal
severity: normal
status: open
title: Aifc read compressed frames fix
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24112/aifc_compression.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13681>
_______________________________________

From report at bugs.python.org  Fri Dec 30 12:22:24 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 30 Dec 2011 11:22:24 +0000
Subject: [issue13681] Aifc read compressed frames fix
In-Reply-To: <1325243830.12.0.0659769703479.issue13681@psf.upfronthosting.co.za>
Message-ID: <1325244144.53.0.0296002541047.issue13681@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

I have put changes to both aifc and audioop module in this single patch. The reason is that aifc test reading compressed frames will work properly only after audioop fix has been applied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13681>
_______________________________________

From report at bugs.python.org  Fri Dec 30 12:24:55 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 30 Dec 2011 11:24:55 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1325244295.4.0.707396174301.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

The last, fifth, patch goes to issue 13681

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Fri Dec 30 12:36:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 30 Dec 2011 11:36:08 +0000
Subject: [issue13682] Documentation of os.fdopen() refers to non-existing
	bufsize argument of builtin open()
Message-ID: <1325244968.02.0.142917484563.issue13682@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

>From the docs of os.fdopen():

    Return an open file object connected to the file descriptor fd. The
    mode and bufsize arguments have the same meaning as the corresponding
    arguments to the built-in open() function.

However, there's no bufsize argument for builtin open() anymore in py3k.

----------
assignee: docs at python
components: Documentation
messages: 150376
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
status: open
title: Documentation of os.fdopen() refers to non-existing bufsize argument of builtin open()
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13682>
_______________________________________

From report at bugs.python.org  Fri Dec 30 12:42:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 11:42:31 +0000
Subject: [issue9260] A finer grained import lock
In-Reply-To: <CAH_1eM0-OXdjVbrz5Fevq7jmpX+1+6LSTmR+p=VeBm3ZJ9pSAw@mail.gmail.com>
Message-ID: <1325245286.3330.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If, on the other hand, we really want to reduce the number of cases
> where a deadlock would occur by increasing the locking granularity,
> then it's the way to go.

Yes, that's the point. Today you have to be careful when mixing imports
and threads. The problems is that imports can be implicit, inside a
library call for example (and putting imports inside functions is a way
of avoiding circular imports, or can also allow to reduce startup time).
Some C functions try to circumvent the problem by calling
PyImport_ModuleNoBlock, which is ugly and fragile in its own way (it
will fail if the import lock is taken, even if there wouldn't be a
deadlock: a very primitive kind of deadlock avoidance indeed).

> Also, a quick search returned those links:
> http://ftp.es.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/src/sys/sys/ksem.h,v
> http://translate.google.fr/translate?hl=fr&sl=ru&tl=en&u=http%3A%2F%2Fforum.nginx.org%2Fread.php%3F21%2C202865%2C202865
> So it seems that sem_init() can fail when the max number of semaphores
> is reached.

As they say, "Kritirii choice of the number 30 in the XXI century is
unclear." :-)

File objects also have a per-object lock, so I guess opening 30 files
under FreeBSD would fail. Perhaps we need to fallback on the other lock
implementation on certain platforms?

(our FreeBSD 8.2 buildbot looks pretty much stable, was the number of
semaphores tweaked on it?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9260>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:21:28 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 30 Dec 2011 14:21:28 +0000
Subject: [issue13642] urllib incorrectly quotes username and password in https
	basic auth
In-Reply-To: <1324393425.24.0.243026081887.issue13642@psf.upfronthosting.co.za>
Message-ID: <1325254888.24.0.80685206365.issue13642@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

> Joonas, this issue seems easy to solve. Do you want to try to post a 
> patch?. Extra credits for patching testsuite too :).
As far as I see, it would be sufficient to add unquote(passed) to _open_generic_http. Regarding unittests instead, there is already a method called test_userpass_inurl which could be extended with some tests on a password containing spaces ( Lib/test/test_urllib.py:263). But what I haven't yet understood is: does it really exists a user:pass in python.org?

----------
nosy: +maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13642>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:51:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Dec 2011 14:51:09 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1325256669.01.0.814930382422.issue11812@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Seems to be fixed now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Fri Dec 30 16:01:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 30 Dec 2011 15:01:30 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325257290.76.0.372407678665.issue13663@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd rather have you maintain poodle.python.org instead of maintaining Python translations off-site.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Fri Dec 30 16:13:53 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Dec 2011 15:13:53 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1324660677.47.0.672646059471.issue8623@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2NTqPdoyoNOxppiJOQkZ80RxiZZXM4Q0Gr6qnw7=F=Yg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This change probably should be backported to 3.2 branch.

I'm not sure about this, I don't feel comfortable backporting a such
path which doesn't solve a "real world problem".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8623>
_______________________________________

From report at bugs.python.org  Fri Dec 30 16:34:14 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 30 Dec 2011 15:34:14 +0000
Subject: [issue13683] Docs in Python 3:raise statement mistake
Message-ID: <1325259254.7.0.957455919083.issue13683@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

In the Python 3 docs for the raise statement, http://docs.python.org/py3k/reference/simple_stmts.html#the-raise-statement,the docs say "If no exception is active in the current scope, a TypeError exception is raised indicating that this is an error (if running under IDLE, a queue.Empty exception is raised instead).

This is wrong in Python 3 because raise raises a RuntimeError and IDLE does the same (does not raise a queue.Empty Exception).

The text should be "If no exception is active in the current scope, a RuntimeError exception is raised indicating that this is an error."

----------
assignee: docs at python
components: Documentation
messages: 150382
nosy: docs at python, maniram.maniram
priority: normal
severity: normal
status: open
title: Docs in Python 3:raise statement mistake
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13683>
_______________________________________

From report at bugs.python.org  Fri Dec 30 16:56:27 2011
From: report at bugs.python.org (luzakiru)
Date: Fri, 30 Dec 2011 15:56:27 +0000
Subject: [issue13684] httplib tunnel infinite loop
Message-ID: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za>


New submission from luzakiru <viscount at inbox.com>:

readline() can return ''. This is handled in most places in httplib but not when a tunnel is used. It leads to a infinite loop that permanently blocks the program while wasting CPU cycles.

For the patch I simply copied the fix that is used elsewhere in the file where readline() is used. It can be fixed in the same way in 2.6.

----------
components: Library (Lib)
files: httplib.patch
keywords: patch
messages: 150383
nosy: luzakiru
priority: normal
severity: normal
status: open
title: httplib tunnel infinite loop
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file24113/httplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13684>
_______________________________________

From report at bugs.python.org  Fri Dec 30 19:03:33 2011
From: report at bugs.python.org (Rock Achu)
Date: Fri, 30 Dec 2011 18:03:33 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325268213.23.0.643982153161.issue13679@psf.upfronthosting.co.za>


Rock Achu <rockachu2 at gmail.com> added the comment:

Erm.. No. I was unaware I had to do so.
Next time I'll be more careful.

Anyways, the docs say that python should throw a RuntimeError, but it didn't?
And would it be doable to add a warning at the top of the multiprocessing tutorial/page that section?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 19:08:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 18:08:03 +0000
Subject: [issue9260] A finer grained import lock
In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za>
Message-ID: <1325268483.91.0.977460013966.issue9260@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I believe this new patch should be much more robust than the previous one.
It also adds a test for the improvement (it freezes an unpatched interpreter).

----------
Added file: http://bugs.python.org/file24114/implock5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9260>
_______________________________________

From report at bugs.python.org  Fri Dec 30 19:08:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 18:08:07 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325268487.17.0.303279558149.issue13679@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Anyways, the docs say that python should throw a RuntimeError, but it
> didn't?

I think running it directly would raise a RuntimeError, but importing it wouldn't.

> And would it be doable to add a warning at the top of the
> multiprocessing tutorial/page that section?

In the introduction you have the following note, together with a link to the relevant section:

?Functionality within this package requires that the __main__ module be importable by the children. This is covered in Programming guidelines however it is worth pointing out here.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 19:10:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 18:10:02 +0000
Subject: [issue13679] Multiprocessing system crash
In-Reply-To: <1325219982.72.0.0375355745471.issue13679@psf.upfronthosting.co.za>
Message-ID: <1325268602.29.0.536217498149.issue13679@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, closing this issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13679>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:00:07 2011
From: report at bugs.python.org (Reuben Garrett)
Date: Fri, 30 Dec 2011 20:00:07 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1325275207.39.0.68197162803.issue12641@psf.upfronthosting.co.za>


Changes by Reuben Garrett <reubengarrett at gmail.com>:


----------
nosy: +RubyTuesdayDONO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:16:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 20:16:06 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1325276166.2.0.264035042839.issue13609@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(review posted on http://bugs.python.org/review/13609/show )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:17:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 20:17:18 +0000
Subject: [issue13684] httplib tunnel infinite loop
In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za>
Message-ID: <1325276238.63.0.949080523693.issue13684@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
stage:  -> patch review
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13684>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:23:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Dec 2011 20:23:12 +0000
Subject: [issue13676] sqlite3: Zero byte truncates string contents
In-Reply-To: <1325161654.99.0.774888973707.issue13676@psf.upfronthosting.co.za>
Message-ID: <1325276592.36.0.826452893061.issue13676@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would be nice to also have tests for the bytes and bytearray cases.
It also seems the generic case hasn't been fixed ("""PyObject_CallFunction(self->connection->text_factory, "y", val_str)""").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13676>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:50:46 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 30 Dec 2011 20:50:46 +0000
Subject: [issue13645] import machinery vulnerable to timestamp collisions
In-Reply-To: <1324470738.36.0.917497036729.issue13645@psf.upfronthosting.co.za>
Message-ID: <1325278246.88.0.960194781645.issue13645@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Why change importlib's API and instead add to it? You could add the requisite path_size() method to get the value, and assume 0 means unsupported (at least until some future version where a deprecation warning about not requiring file size comes about). But I don't see how you can get around not exposing these details as stored in some API, whether it is by method or object attribute since you can't assume stat results since support for non-file storage back-ends would be unduly burdened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13645>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:50:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 20:50:55 +0000
Subject: [issue13641] decoding functions in the base64 module could accept
	unicode strings
In-Reply-To: <1324386392.48.0.968435833624.issue13641@psf.upfronthosting.co.za>
Message-ID: <1325278255.07.0.446009150864.issue13641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13641>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:55:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 20:55:46 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1325278546.18.0.841379002713.issue13508@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:55:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 20:55:57 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1325278557.32.0.0780350082472.issue13508@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:59:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 20:59:05 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325278745.44.0.783137736919.issue12760@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> This is not a "duplicate issue". The openat solution is no easier than the os.open
> solution.

Amaury did not suggest to use openat, but the new opener argument to open, which was especially added for use cases such as the one discussed here:

    ...
    open_exclusive = lambda path, mode: os.open(path, mode|os.O_CREAT|os.O_EXCL))
    ...
    fp = open(filename, 'w', opener=open_exclusive)
    ...

That?s why this bug was initially closed as duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:01:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 21:01:42 +0000
Subject: [issue13659] Add a help() viewer for IDLE's Shell.
In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za>
Message-ID: <1325278902.61.0.481490734855.issue13659@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I should like it if a separate window were either automatic or a configuration option for help on modules and classes, which should cover 'long' output.  The Windows workaround, which I will never remember, brings up an extraneous cmd.exe window in addition to notepad.

----------
nosy: +terry.reedy
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13659>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:05:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:05:04 +0000
Subject: [issue13656] Document ctypes.util and ctypes.wintypes.
In-Reply-To: <1324640225.55.0.0772852885981.issue13656@psf.upfronthosting.co.za>
Message-ID: <1325279104.52.0.753421346262.issue13656@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

May I ask why you closed this?  From a quick glance, a few functions from ctypes.util are considered public and documented (albeit not with module directives, so I?m not sure the indexing works helpfully for people searching); I don?t know the status of wintypes.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13656>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:10:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 21:10:26 +0000
Subject: [issue13664] UnicodeEncodeError in gzip when filename contains
	non-ascii
In-Reply-To: <1324914932.64.0.469258692044.issue13664@psf.upfronthosting.co.za>
Message-ID: <1325279426.44.0.249630554157.issue13664@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The actual fix in the previous issue, as in Python 3, was to always write the filename, but with errors replaced with '?/.

----------
nosy: +lars.gustaebel, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13664>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:13:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 21:13:18 +0000
Subject: [issue13665] TypeError: string or integer address expected instead of
	str instance
In-Reply-To: <1324921834.92.0.644281007494.issue13665@psf.upfronthosting.co.za>
Message-ID: <1325279598.16.0.420855939866.issue13665@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +amaury.forgeotdarc, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13665>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:27:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:27:34 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1325280454.35.0.924262087786.issue13655@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, loewis
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:27:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:27:46 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1325280466.1.0.8182378642.issue13655@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:29:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 21:29:24 +0000
Subject: [issue13666] datetime documentation typos
In-Reply-To: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za>
Message-ID: <1325280564.03.0.0625931300517.issue13666@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 only gets security updates.

I verified 'rzinfo' typo in x.1.6 in 2.7 and 3.2. Also in both, tzinfo.utcoffset begins as Stephen claims. I have not verified that this is error.

 Also in both, in x.1.4, class GMT1 has
...     def utcoffset(self, dt):
...         return timedelta(hours=1) + self.dst(dt)
...     def dst(self, dt):
...         if self.dston <=  dt.replace(tzinfo=None) < self.dstoff:
...             return timedelta(hours=1)
...         else:
...             return timedelta(0)

while GMT2 has
...     def utcoffset(self, dt):
...         return timedelta(hours=1) + self.dst(dt)
...     def dst(self, dt):
...         if self.dston <=  dt.replace(tzinfo=None) < self.dstoff:
...             return timedelta(hours=2)
...         else:
...             return timedelta(0)

Stephen is saying that 'hours=1' should here be 'hours=2'. Should '0' by 'hours=1' to be just 1 off from 2?

----------
nosy: +belopolsky, terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13666>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:30:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:30:22 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs waiting for connection
	close after a redirect
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <1325280622.56.0.746084698804.issue8035@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It could be possible to set up an ad-hoc httpserver for that purpose,
> but that sounds a bit overkill.

Oh, I assumed urllib already had a server for tests.  We have one in distutils2/packaging, otherwise we?d have to resort to manual testing against the real PyPI, and I?d feel much less confident about regressions.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:37:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:37:28 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1325281048.18.0.332897278772.issue13443@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Senthil.  I think you applied a patch that did not have consensus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:40:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:40:01 +0000
Subject: [issue13294] http.server: minor code style changes.
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1325281201.12.0.913501147108.issue13294@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just a note: ?Incorporated Michele Orr?'s code style changes into the trunk and other codelines.?

The policy is to apply only bug fixes and doc fixes and improvements to stable branches, not code cleanups (they?re usually compatible but are just not worth doing?at one point code is released and should stop being improved).  This is not worth reverting now, unless the commit was buggy (I didn?t read all messages), I just wanted to restate the policy to avoid such future code cleanups in bugfix branches.  Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:40:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:40:42 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1325281242.96.0.507948749721.issue13443@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hm, it was actually Antoine who removed it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:42:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:42:18 +0000
Subject: [issue13614] setup.py register fails if long_description contains ReST
In-Reply-To: <1324069250.69.0.136486094973.issue13614@psf.upfronthosting.co.za>
Message-ID: <1325281338.27.0.447470547956.issue13614@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
components: +Distutils2
keywords: +easy
nosy: +alexis
stage:  -> test needed
title: `setup.py register` fails if long_description contains RST -> setup.py register fails if long_description contains ReST
type:  -> behavior
versions: +3rd party, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13614>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:48:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 21:48:48 +0000
Subject: [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325281728.56.0.466131415715.issue13677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Flags comment applies to 3.2.2 docs and 2.7.2 docs. There is only one additional flag: ast.PyCF_ONLY_AST, so 'flags' should be singular.

As for src and dst, doc has been updated to say 'Compile the source into a code or AST object. ... source can either be a string or an AST object.

'source' should be capitalized.

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13677>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:02:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 22:02:45 +0000
Subject: [issue13683] Docs in Python 3:raise statement mistake
In-Reply-To: <1325259254.7.0.957455919083.issue13683@psf.upfronthosting.co.za>
Message-ID: <1325282565.21.0.904256621592.issue13683@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Verified for 3.2.2 cmd window and idle. Fix looks good.

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13683>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:07:18 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Fri, 30 Dec 2011 22:07:18 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325282838.91.0.688268261114.issue12760@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

> Amaury did not suggest to use openat, but the new opener argument to open, which was especially added for use cases such as the one discussed here:

Sorry, yes. Wrong words, same thought. We can implement this using opener, but we could implement this with os.open before. What's changed, except that there's more ways to do it? (There is slightly more versatility with the opener method, but no more obviousness and no less typing).

My understanding from reading the other thread is that this is not the primary use-case of the new parameter for open(). In fact, this ticket was not really mentioned at all there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:24:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 22:24:55 +0000
Subject: [issue13684] httplib tunnel infinite loop
In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za>
Message-ID: <1325283895.47.0.693585353298.issue13684@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.2, http.client.py, insertion would be at line 718.
However, only one statement is needed to break. 3.2 elsewhere has
    if line in (b'\r\n', b'\n', b''):
        break
But I note that at 512, there is the code luzakiru patched in. I think that should perhaps be changed to above also, unless bare \n from reading a server is really impossible.

At 313, i found this misformed code:

         if not line:
            # Presumably, the server closed the connection before
            # sending a valid response.
     raise BadStatusLine(line)

[I am curious -- is it really intended to simply throw away the tunnel server response after the first header?]

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13684>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:29:27 2011
From: report at bugs.python.org (Jeff Yurkiw)
Date: Fri, 30 Dec 2011 22:29:27 +0000
Subject: [issue13685] argparse does not sanitize help strings for % signs
Message-ID: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za>


New submission from Jeff Yurkiw <jeff at cyan.com>:

I discovered this while programming the command line interface for a python program that can take a passed argument and throw it into the 'where like' clause of a SQL expression (intended for a postgresql database).

The wildcard character for where-like statements is generally the percent sign, which is how I found this ("WHERE %s LIKE '%--value%')".

If you use any single '%' signs in an ArgumentParser.new_argument(help=)'s help description Python 3.2 will throw an error.

Workaround: You can avoid this issue by doubling up on all % signs that you want to display in your help text.

parser.add_argument(('--foo', action='store',help='%bar') throws an error.
parser.add_argument(('--foo', action='store',help='%%bar') displays '--foo FOO   %bar'.

Suggested fix:
When assigning help strings from add_argument(), throw them through a sanitizer and replace all occurrences of '%' with '%%' behind the scenes.

Example code (argparseBug.py):

from argparse import ArgumentParser

parser = ArgumentParser()
parser.add_argument('--foo', action='store', help='%bar')

args = parser.parse_args('-h'.split())

You get the following stacktrace:
Traceback (most recent call last):
  File "/path/to/script/argparseBug.py", line 6, in <module>
    args = parser.parse_args('-h'.split())
  File "/usr/lib/python3.2/argparse.py", line 1701, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python3.2/argparse.py", line 1733, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python3.2/argparse.py", line 1939, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python3.2/argparse.py", line 1879, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python3.2/argparse.py", line 1807, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python3.2/argparse.py", line 994, in __call__
    parser.print_help()
  File "/usr/lib/python3.2/argparse.py", line 2331, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib/python3.2/argparse.py", line 2305, in format_help
    return formatter.format_help()
  File "/usr/lib/python3.2/argparse.py", line 279, in format_help
    help = self._root_section.format_help()
  File "/usr/lib/python3.2/argparse.py", line 209, in format_help
    func(*args)
  File "/usr/lib/python3.2/argparse.py", line 209, in format_help
    func(*args)
  File "/usr/lib/python3.2/argparse.py", line 515, in _format_action
    help_text = self._expand_help(action)
  File "/usr/lib/python3.2/argparse.py", line 601, in _expand_help
    return self._get_help_string(action) % params
ValueError: unsupported format character 'b' (0x62) at index 1

----------
components: None
files: argparseBug.py
messages: 150404
nosy: Jeff.Yurkiw
priority: normal
severity: normal
status: open
title: argparse does not sanitize help strings for % signs
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file24115/argparseBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13685>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:35:21 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 30 Dec 2011 22:35:21 +0000
Subject: [issue13685] argparse does not sanitize help strings for % signs
In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za>
Message-ID: <1325284521.31.0.790848225961.issue13685@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This is because the help text support substitution, as mentioned here: http://docs.python.org/dev/library/argparse.html#help

It's possible this documentation could be improved.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python, eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13685>
_______________________________________

From report at bugs.python.org  Sat Dec 31 01:37:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 00:37:44 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325291864.93.0.942110099636.issue12760@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> [...] There is slightly more versatility with the opener method, but no more obviousness
> and no less typing.

I agree with your opinion.  I re-read this report:
- Antoine thinks this fills an important use case, namely avoiding race conditions
- Amaury then suggested the opener argument idea, which was implemented in the openat bug
- Antoine judged it would be better than what we had before

I don?t have a strong opinion on ?opener is generic and good enough? vs. ?not as ice as it could be?.  Antoine seems to agree with you, so your patch will get reviewed and eventually accepted.  Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:51:20 2011
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 31 Dec 2011 01:51:20 +0000
Subject: [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325296280.12.0.629202660134.issue13677@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

I'm not sure we're looking at the same thing.  I was talking about the docstring that shows up at the interactive prompt in response to 
>>> help(compile)

Going to hg.python.org/cpython and selecting branches, then default, then browse, got me to
http://hg.python.org/cpython/file/7010fa9bd190/Python/bltinmodule.c
which still doesn't mention AST.  I also don't see any reference to "src" or "dst", or any "source" that looks like it should be capitalized.

I agree that there is (to my knowledge, at this time) only one additional flag.  I figured ast or future was needed to get the compilation constants, so it made sense to delegate -- but you seem to be reading something newer than I am.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13677>
_______________________________________

From report at bugs.python.org  Sat Dec 31 05:19:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 04:19:39 +0000
Subject: [issue13590] Prebuilt python-2.7.2 binaries for macosx can not
	compile c extensions
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1325305179.84.0.807952242246.issue13590@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13590>
_______________________________________

From report at bugs.python.org  Sat Dec 31 05:20:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 04:20:08 +0000
Subject: [issue13640] add mimetype for application/vnd.apple.mpegurl
In-Reply-To: <1324345079.76.0.172332572268.issue13640@psf.upfronthosting.co.za>
Message-ID: <1325305208.41.0.717238478986.issue13640@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> patch review
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13640>
_______________________________________

From report at bugs.python.org  Sat Dec 31 05:47:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Dec 2011 04:47:27 +0000
Subject: [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325306847.0.0.827216573189.issue13677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am aware that the docstring, shown at help(compile), is what you were talking about. The docstring and manuals should say the same thing, or at least not contradict each other, so it is common for both to be out of date and both to be updated at the same time. So I went and looked at the current py2 and py3 docs to see if they also need change. And they do, though not quite as much. src and dst were unofficial abbreviations for source and output, in reference to what you said. Sorry for the confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13677>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:00:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Dec 2011 05:00:14 +0000
Subject: [issue13686] Some notes on the docs of multiprocessing
Message-ID: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

I've decided to study the multiprocessing module a bit, and carefully went over the docs (for 2.7). Some small fixes I will commit myself, but a few issues came up on which I'd like some opinion from others. In rough order of appearance in the doc:

1. In the documentation of the 'name' argument of the multiprocessing.Process constructor, it mentions that the length of the generated name depends on the "generation", without elaborating. It could be better to briefly describe the algorithm in a sentence or two.
2. Section 16.6.2.1. is called "Process and exceptions". It only documents one exception from multiprocessing: BufferTooShort. Other exception classes exported by the module aren't documented similarly: ProcessError, TiemoutError, AuthenticationError.
3. AuthenticationError is documented as multiprocessing.connection.AuthenticationError, although in reality it exists in the root multiprocessing module, and multiprocessing.connection just imports it
4. The doc of JoinableQueue.task_done() says "Used by queue consumer threads". Shouldn't that be "consumer processes"?
5. The doc of active_children() should probably mention that it returns a list of Process objects (similarly to what current_process() says)
6. multiprocessing.freeze_support() says "If the freeze_support() line is omitted then trying to run the frozen executable will raise RuntimeError.". *Who* will raise the error?
7. class multiprocessing.Event says "This method returns..." - what method? Seems like an irrelevant documentation piece was intermixed here
8. 16.6.2.7. Managers starts by saying that Managers provide a way to create data which can be shared between different processes. Since it comes right after the section about Shared objects, I think it would be nice to mention in a sentence or two what Managers give above normal synchonized objects in multiprocessing (i.e. sharing between different machines)
9. In the programming guidelines about "Avoid shared state" it says "It is probably best to stick to using queues or pipes for communication between processes rather than using the lower level synchronization primitives from the threading module.". Surely not the "threading" module is meant here?

----------
assignee: docs at python
components: Documentation
messages: 150409
nosy: docs at python, eli.bendersky, pitrou
priority: normal
severity: normal
status: open
title: Some notes on the docs of multiprocessing
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13686>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:58:08 2011
From: report at bugs.python.org (baleno)
Date: Sat, 31 Dec 2011 05:58:08 +0000
Subject: [issue13687] parse incorrect command line on windows 7
Message-ID: <1325311088.94.0.632588075426.issue13687@psf.upfronthosting.co.za>


New submission from baleno <cui_y_x at 126.com>:

i just tested python2.7.2 and python 3.2.2 on windows 7,this bugs at all version.

my test code:
import sys
print(sys.argv)

command line:
test.py "%cc%cd%bd"

command result:
['E:\\Codes\\test.py', '%ccE:\\Codesbd']

----------
components: None
files: error.png
messages: 150410
nosy: balenocui
priority: normal
severity: normal
status: open
title: parse incorrect command line on windows 7
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file24116/error.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13687>
_______________________________________

From report at bugs.python.org  Sat Dec 31 08:24:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Dec 2011 07:24:45 +0000
Subject: [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <1325316285.08.0.179662421191.issue13686@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

10. Unless I'm missing something entirely obvious, except in the examples it says that Value has a "value" attribute for actual data access. One is expected to look in the docs of ctypes to find that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13686>
_______________________________________

From report at bugs.python.org  Sat Dec 31 08:25:56 2011
From: report at bugs.python.org (baleno)
Date: Sat, 31 Dec 2011 07:25:56 +0000
Subject: [issue13687] parse incorrect command line on windows 7
In-Reply-To: <1325311088.94.0.632588075426.issue13687@psf.upfronthosting.co.za>
Message-ID: <1325316356.19.0.914768966631.issue13687@psf.upfronthosting.co.za>


baleno <cui_y_x at 126.com> added the comment:

% is escape characters for DOS,

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13687>
_______________________________________

From report at bugs.python.org  Sat Dec 31 08:37:14 2011
From: report at bugs.python.org (Ron Adam)
Date: Sat, 31 Dec 2011 07:37:14 +0000
Subject: [issue13659] Add a help() viewer for IDLE's Shell.
In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za>
Message-ID: <1325317034.64.0.0721435234981.issue13659@psf.upfronthosting.co.za>


Ron Adam <ron3200 at gmail.com> added the comment:

What about having idle open a web browser session with pydocs new browse option?

python3 -m pydoc -b

We've added input fields to the pages that take the same input as help() command does.  It also links to the online help pages, and you can view the source code of the files directly in the browser.  (Sometimes that's the best documentation you can get.)

----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13659>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:02:55 2011
From: report at bugs.python.org (Sergey Dorofeev)
Date: Sat, 31 Dec 2011 11:02:55 +0000
Subject: [issue13688] ast.literal_eval fails on octal numbers
Message-ID: <1325329375.55.0.0376452596418.issue13688@psf.upfronthosting.co.za>


New submission from Sergey Dorofeev <fidoman at users.sourceforge.net>:

Python 3.2.2 (default, Nov 16 2011, 10:58:44) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.literal_eval('10')
10
>>> ast.literal_eval('0x10')
16
>>> ast.literal_eval('010')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python322/lib/python3.2/ast.py", line 48, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "/opt/python322/lib/python3.2/ast.py", line 36, in parse
    return compile(source, filename, mode, PyCF_ONLY_AST)
  File "<unknown>", line 1
    010
      ^
SyntaxError: invalid token

----------
components: Library (Lib)
messages: 150414
nosy: fidoman
priority: normal
severity: normal
status: open
title: ast.literal_eval fails on octal numbers
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13688>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:05:18 2011
From: report at bugs.python.org (Sergey Dorofeev)
Date: Sat, 31 Dec 2011 11:05:18 +0000
Subject: [issue13688] ast.literal_eval fails on octal numbers
In-Reply-To: <1325329375.55.0.0376452596418.issue13688@psf.upfronthosting.co.za>
Message-ID: <1325329518.72.0.461055144652.issue13688@psf.upfronthosting.co.za>


Sergey Dorofeev <fidoman at users.sourceforge.net> added the comment:

python 3 feature - should use 0o10
need to rebuild data file :(

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13688>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:19:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 11:19:10 +0000
Subject: [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325330350.58.0.48590064539.issue13677@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13677>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:22:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 11:22:54 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325330574.28.0.630360966639.issue13663@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:26:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 11:26:38 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325330798.11.0.433467383535.issue13663@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed with Martin.  I would be nice to get a statement on the status of pootle.python.org (social aspects like updating and publishing the translations + organization of teams), but Georg seems busy.

(This would probably be more at home on a mailing list rather than in the CPython bug tracker.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:43:17 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Dec 2011 11:43:17 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325331797.5.0.730432316558.issue13663@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've never really had a hand in pootle.python.org; it was set up by Martin and Robert Lehmann, and Sandro Tosi also wanted to lend a hand...

----------
nosy: +lehmannro, sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:49:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 31 Dec 2011 11:49:36 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325332176.8.0.647737594731.issue13663@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Yeah, I really would like to help with pootle, but it seems we don't have a current status of the thing + a roadmap to where we want to go.

>From the top of my head, I think we need at least:

- the current setup of the machine/service
- updated packages for pootle + its deps (it should be a debian machine, so I can leverage my DD status to help here)
- plan the migration from the current pootle to the updated one
- start advertise pootle, which is much better than having a lot of people translating python doc on their own websites instead of a central (official) place
- maybe rename the service?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Sat Dec 31 15:01:48 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 31 Dec 2011 14:01:48 +0000
Subject: [issue13609] Add "os.get_terminal_size()" function
In-Reply-To: <1323997298.98.0.00319779142763.issue13609@psf.upfronthosting.co.za>
Message-ID: <1325340108.91.0.430072570218.issue13609@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Thanks for the review!

New version is attached. The code is actually slightly shorter, but
there are more docs.

 Doc/library/os.rst        |   52 +++++++++++++++++++
 Doc/whatsnew/3.3.rst      |    5 +
 Lib/os.py                 |   43 +++++++++++++++
 Lib/test/test_termsize.py |   31 +++++++++++
 Misc/NEWS                 |    3 +
 Modules/posixmodule.c     |  125 ++++++++++++++++++++++++++++++++++++++++++++++
 configure                 |    2 
 configure.in              |    2 
 pyconfig.h.in             |    3 +
 9 files changed, 264 insertions(+), 2 deletions(-)

>The patch also lacks some documentation update in Doc/library/os.rst.
Added as a subsection under "File Descriptor Operations" section.
I also added an entry to Misc/NEWS and Doc/whatsnew/3.3.rst.

> Lib/os.py:833: def get_terminal_size(columns=80, rows=25):
> The arguments seem ignored in the function body, so I think they should simply
> be removed.
The implementation was borked and didn't actually do what the
docstring said. It should be fixed now.

I want to retain the default values, because get_terminal_size()
should "do the right thing" in case stdout is not a terminal,
without the user needing to wrap it in a try..except block
or some other test. Putting the default values as parameters
makes it clear what will be returned in case query fails, and
makes it easy to override those defaults.

To make it clearer that those are the fallback values, I renamed the
parameter to 'fallback=(c, r)', which should be understandable even
without reading the docstring. Having it as a single parameter might
also make it easier to add something like 'minimum=(c, r)' in the
future.

> I wonder if you shouldn't try to explicitly pass sys.stdout.fileno() here, or
> perhaps sys.__stdout__.fileno() since the former could be overriden.
OK, changed to sys.__stdout__.fileno().

I think that sys.__stdout__ is better, because when stdout is overridden,
it is usually with something that is not a terminal. Changing the output
terminal is probably pretty rare.

> Actually, perhaps get_terminal_size() should have an optional file descriptor
> argument.
Querying anything other than stdout should be pretty rare. If
necessary, query_terminal_size() can be called explicitly. Also,
the variables $COLUMNS and $ROWS are usually meant to refer to stdout,
so get_terminal_size() is about stdout and ROWS and COLUMNS, and the
other function allows full control.

> Lib/test/test_termsize.py:1: import unittest
> This file seems to lack an ``if __name__ == '__main__'`` like other test files
OK.

> Besides, why not simply put the tests in test_os.py?
The tests were nicely self-contained. I wanted to be able to do:
  ./python Lib/test/test_termsize.py
and
  ./python Lib/test/test_termsize.py | cat
but I guess it can be easily moved to test_os.py if necessary.

> Lib/test/test_termsize.py:7: def set_environ(**variables):
> There's already EnvironmentVarGuard in test.support.
OK.

> Lib/test/test_termsize.py:7: def set_environ(**variables):
> There's already EnvironmentVarGuard in test.support.
> Lib/test/test_termsize.py:25: self.assertTrue(0 < size.columns)
> Better to use assertGreater here, failure messages will be more informative.
> Lib/test/test_termsize.py:33: self.assertTrue(size.columns == 777)
> And better to use assertEqual here.
OK.

> Typo here ("imlmented").
OK.

> Modules/posixmodule.c:10571: return PyErr_Format(PyExc_ValueError)
> I don't think there's any point in changing the error here. Just let
> a normal OSError be raised.
OK, s/ValueError/OSError/ here and the the windows case below too.

> Modules/posixmodule.c:10573: return PyErr_SetFromErrno(PyExc_IOError);
> For the record, in 3.3, PyExc_IOError is an alias of PyExc_OSError.
OK, s/IOError/OSError/ for clarity.

> Modules/posixmodule.c:10599: return PyErr_Format(PyExc_IOError, "error %i",
> (int) GetLastError());
> Just use PyErr_SetFromWindowsErr(GetLastError()).
OK.

> Modules/posixmodule.c:11086: {"query_terminal_size", query_terminal_size,
> METH_VARARGS, termsize__doc__},
> I don't think there's any point in making this helper function public, so I'd
> rename it _query_terminal_size or something.
The idea is that query_terminal_size() can be used to do the
low-level query ignoring $COLUMNS and $ROWS and returing the real
error if something goes wrong. If is documented, so I think that
it can be "public".

I've also improved the docstrings slightly.

----------
Added file: http://bugs.python.org/file24117/termsize.diff.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13609>
_______________________________________

From report at bugs.python.org  Sat Dec 31 15:31:43 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 31 Dec 2011 14:31:43 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325341903.3.0.41687807089.issue13663@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

naoki: what is your actual complaint about the installation being outdated? Are you referring to the message catalog (documentation version), or the software?

As for the message catalog, I don't think it should be updated too often (only once per Python release), otherwise, translators will have to fight a moving target (which they will have to, anyway, given that the documentation evolves).

Whatever updating procedure is performed: preserving the existing translations and the existing accounts is an absolute must.

I'm not sure what good renaming the service would do; this sounds like bike shedding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Sat Dec 31 15:39:32 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 31 Dec 2011 14:39:32 +0000
Subject: [issue13688] ast.literal_eval fails on octal numbers
In-Reply-To: <1325329375.55.0.0376452596418.issue13688@psf.upfronthosting.co.za>
Message-ID: <1325342372.69.0.563646064902.issue13688@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution: rejected -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13688>
_______________________________________

From report at bugs.python.org  Sat Dec 31 16:16:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 31 Dec 2011 15:16:28 +0000
Subject: [issue13689] fix CGI Web Applications with Python link in
	howto/urllib2
Message-ID: <1325344588.81.0.466504825204.issue13689@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi,
as discussed on irc, howto/urllib2 refers to "CGI Web Applications with Python, Part One" on http://www.pyzine.com/Issue008/Section_Articles/article_CGIOne.html which is no more accessible.

Given part two of that document is on Michael's website (http://www.voidspace.org.uk/python/articles/cgi_web_applications_two.shtml), maybe Michael could move Part One too so we can fix the broken link.

----------
assignee: michael.foord
components: Documentation
messages: 150421
nosy: michael.foord, sandro.tosi
priority: normal
severity: normal
status: open
title: fix CGI Web Applications with Python link in howto/urllib2
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13689>
_______________________________________

From report at bugs.python.org  Sat Dec 31 17:33:02 2011
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 31 Dec 2011 16:33:02 +0000
Subject: [issue13663] pootle.python.org is outdated.
In-Reply-To: <1325341903.3.0.41687807089.issue13663@psf.upfronthosting.co.za>
Message-ID: <CAEfz+Ty9637Q8sHw+mHZMkyE5+o=a7N6R2X9Q7L5=MHpO7YH0Q@mail.gmail.com>


INADA Naoki <songofacandy at gmail.com> added the comment:

On Sat, Dec 31, 2011 at 11:31 PM, Martin v. L?wis
<report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> naoki: what is your actual complaint about the installation being outdated? Are you referring to the message catalog (documentation version), or the software?

I need Python 3.2's message catalog. But updating pootle version is
also nice to me.

> As for the message catalog, I don't think it should be updated too often (only once per Python release), otherwise, translators will have to fight a moving target (which they will have to, anyway, given that the documentation evolves).
>

I agree with you about already released series (~3.2).
I think updating message catalog for beta versions may help releasing new
Python's translated document fast.

The way to manage multiple series is also needed when Python 3.3 is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13663>
_______________________________________

From report at bugs.python.org  Sat Dec 31 19:26:18 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 31 Dec 2011 18:26:18 +0000
Subject: [issue13690] Add DEBUG flag to documentation of re.compile
Message-ID: <1325355977.96.0.0770563449241.issue13690@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

This is a useful flag and it would be good, if it was in documentation.

----------
messages: 150423
nosy: gruszczy
priority: normal
severity: normal
status: open
title: Add DEBUG flag to documentation of re.compile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13690>
_______________________________________

From report at bugs.python.org  Sat Dec 31 19:26:57 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 31 Dec 2011 18:26:57 +0000
Subject: [issue13690] Add DEBUG flag to documentation of re.compile
In-Reply-To: <1325355977.96.0.0770563449241.issue13690@psf.upfronthosting.co.za>
Message-ID: <1325356017.17.0.529410110597.issue13690@psf.upfronthosting.co.za>


Changes by Filip Gruszczy?ski <gruszczy at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24118/13690.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13690>
_______________________________________

From report at bugs.python.org  Sat Dec 31 19:27:15 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 31 Dec 2011 18:27:15 +0000
Subject: [issue13676] sqlite3: Zero byte truncates string contents
In-Reply-To: <1325161654.99.0.774888973707.issue13676@psf.upfronthosting.co.za>
Message-ID: <1325356035.63.0.434229551992.issue13676@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/issue13676>
_______________________________________

From report at bugs.python.org  Sat Dec 31 22:00:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Dec 2011 21:00:44 +0000
Subject: [issue13659] Add a help() viewer for IDLE's Shell.
In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za>
Message-ID: <1325365244.25.0.431971609128.issue13659@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would like that to be a help() option, such as help(module, -b) or more verbosely, help(module, browser=True). This would be useful for the regular interactive interpreter as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13659>
_______________________________________