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: [New-bugs-announce] [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 05:59:05 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 04:59:05 +0000
Subject: [New-bugs-announce] [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 07:33:08 2011
From: report at bugs.python.org (Paul Sladen)
Date: Thu, 01 Dec 2011 06:33:08 +0000
Subject: [New-bugs-announce] [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 08:53:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2011 07:53:37 +0000
Subject: [New-bugs-announce] [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 19:00:23 2011
From: report at bugs.python.org (Raul Morales)
Date: Thu, 01 Dec 2011 18:00:23 +0000
Subject: [New-bugs-announce] [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 21:53:52 2011
From: report at bugs.python.org (Thouis (Ray) Jones)
Date: Thu, 01 Dec 2011 20:53:52 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 10:11:11 2011
From: report at bugs.python.org (aoi.leslie)
Date: Fri, 02 Dec 2011 09:11:11 +0000
Subject: [New-bugs-announce] [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 17:29:13 2011
From: report at bugs.python.org (sbt)
Date: Fri, 02 Dec 2011 16:29:13 +0000
Subject: [New-bugs-announce] [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  Sat Dec  3 01:30:28 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Dec 2011 00:30:28 +0000
Subject: [New-bugs-announce] [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 13:08:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Dec 2011 12:08:49 +0000
Subject: [New-bugs-announce] [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:18:58 2011
From: report at bugs.python.org (lennartyseboodt)
Date: Sat, 03 Dec 2011 12:18:58 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 14:17:22 2011
From: report at bugs.python.org (Nicolas Goutte)
Date: Sat, 03 Dec 2011 13:17:22 +0000
Subject: [New-bugs-announce] [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 20:10:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Dec 2011 19:10:49 +0000
Subject: [New-bugs-announce] [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 21:14:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 20:14:56 +0000
Subject: [New-bugs-announce] [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  Sun Dec  4 18:01:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 17:01:31 +0000
Subject: [New-bugs-announce] [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 21:08:19 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 04 Dec 2011 20:08:19 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 12:55:23 2011
From: report at bugs.python.org (mike c)
Date: Mon, 05 Dec 2011 11:55:23 +0000
Subject: [New-bugs-announce] [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 15:07:43 2011
From: report at bugs.python.org (maniram maniram)
Date: Mon, 05 Dec 2011 14:07:43 +0000
Subject: [New-bugs-announce] [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:36:34 2011
From: report at bugs.python.org (dangermouseb)
Date: Mon, 05 Dec 2011 15:36:34 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 01:49:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2011 00:49:34 +0000
Subject: [New-bugs-announce] [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 02:02:40 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 06 Dec 2011 01:02:40 +0000
Subject: [New-bugs-announce] [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 13:28:22 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Tue, 06 Dec 2011 12:28:22 +0000
Subject: [New-bugs-announce] [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:56:42 2011
From: report at bugs.python.org (Guillaume Bouchard)
Date: Tue, 06 Dec 2011 12:56:42 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 15:56:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Dec 2011 14:56:35 +0000
Subject: [New-bugs-announce] [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 17:44:59 2011
From: report at bugs.python.org (Peter)
Date: Tue, 06 Dec 2011 16:44:59 +0000
Subject: [New-bugs-announce] [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 21:28:30 2011
From: report at bugs.python.org (Yang Zhang)
Date: Tue, 06 Dec 2011 20:28:30 +0000
Subject: [New-bugs-announce] [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 23:33:53 2011
From: report at bugs.python.org (ekorn)
Date: Tue, 06 Dec 2011 22:33:53 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 09:14:10 2011
From: report at bugs.python.org (Peter Frauenglass)
Date: Wed, 07 Dec 2011 08:14:10 +0000
Subject: [New-bugs-announce] [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:49:04 2011
From: report at bugs.python.org (Ji Han)
Date: Wed, 07 Dec 2011 08:49:04 +0000
Subject: [New-bugs-announce] [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 16:53:29 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Dec 2011 15:53:29 +0000
Subject: [New-bugs-announce] [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 vadim at vmtechnology.com  Wed Dec  7 16:46:43 2011
From: vadim at vmtechnology.com (VM)
Date: Wed, 07 Dec 2011 10:46:43 -0500
Subject: [New-bugs-announce] IDLE on Windows bug
Message-ID: <003201ccb4f7$6bc1b340$434519c0$@com>

Running Python 3.2.1 IDLE on Windows XP SP2 creates two pytonw.exe
processes. When closing IDLE one process is killed and another one stays.
Multiple IDLE run/close result in unlimited growing number of abandoned
pytonw.exe processes.


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: [New-bugs-announce] [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 22:49:54 2011
From: report at bugs.python.org (Matt Long)
Date: Wed, 07 Dec 2011 21:49:54 +0000
Subject: [New-bugs-announce] [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:40:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2011 22:40:26 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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: [New-bugs-announce] [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 02:12:09 2011
From: report at bugs.python.org (th9)
Date: Thu, 08 Dec 2011 01:12:09 +0000
Subject: [New-bugs-announce] [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:44:26 2011
From: report at bugs.python.org (th9)
Date: Thu, 08 Dec 2011 01:44:26 +0000
Subject: [New-bugs-announce] [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 13:52:03 2011
From: report at bugs.python.org (Phillies)
Date: Thu, 08 Dec 2011 12:52:03 +0000
Subject: [New-bugs-announce] [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 18:23:11 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Dec 2011 17:23:11 +0000
Subject: [New-bugs-announce] [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 21:25:54 2011
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Thu, 08 Dec 2011 20:25:54 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:47:25 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Dec 2011 20:47:25 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 02:50:00 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 09 Dec 2011 01:50:00 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 06:21:52 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Dec 2011 05:21:52 +0000
Subject: [New-bugs-announce] [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:56:07 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Dec 2011 06:56:07 +0000
Subject: [New-bugs-announce] [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 13:58:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2011 12:58:59 +0000
Subject: [New-bugs-announce] [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:25:04 2011
From: report at bugs.python.org (sbt)
Date: Fri, 09 Dec 2011 13:25:04 +0000
Subject: [New-bugs-announce] [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 16:54:42 2011
From: report at bugs.python.org (Pami Ketolainen)
Date: Fri, 09 Dec 2011 15:54:42 +0000
Subject: [New-bugs-announce] [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 18:57:23 2011
From: report at bugs.python.org (Gianluigi Tiesi)
Date: Fri, 09 Dec 2011 17:57:23 +0000
Subject: [New-bugs-announce] [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 20:57:42 2011
From: report at bugs.python.org (Nikita Pchelin)
Date: Fri, 09 Dec 2011 19:57:42 +0000
Subject: [New-bugs-announce] [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 22:12:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Dec 2011 21:12:32 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 14:47:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Dec 2011 13:47:29 +0000
Subject: [New-bugs-announce] [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 19:49:55 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Dec 2011 18:49:55 +0000
Subject: [New-bugs-announce] [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:52:05 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 19:52:05 +0000
Subject: [New-bugs-announce] [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:57:39 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 20:57:39 +0000
Subject: [New-bugs-announce] [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  Sun Dec 11 02:58:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Dec 2011 01:58:34 +0000
Subject: [New-bugs-announce] [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 05:27:05 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Dec 2011 04:27:05 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 08:10:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Dec 2011 07:10:50 +0000
Subject: [New-bugs-announce] [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 10:47:57 2011
From: report at bugs.python.org (kxroberto)
Date: Sun, 11 Dec 2011 09:47:57 +0000
Subject: [New-bugs-announce] [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 19:26:28 2011
From: report at bugs.python.org (Christopher the Magnificent)
Date: Sun, 11 Dec 2011 18:26:28 +0000
Subject: [New-bugs-announce] [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 20:38:10 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 11 Dec 2011 19:38:10 +0000
Subject: [New-bugs-announce] [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 22:45:48 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Sun, 11 Dec 2011 21:45:48 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 02:49:50 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 01:49:50 +0000
Subject: [New-bugs-announce] [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 06:42:12 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Mon, 12 Dec 2011 05:42:12 +0000
Subject: [New-bugs-announce] [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 13:40:54 2011
From: report at bugs.python.org (Bithin A)
Date: Mon, 12 Dec 2011 12:40:54 +0000
Subject: [New-bugs-announce] [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 16:32:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Dec 2011 15:32:34 +0000
Subject: [New-bugs-announce] [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 19:31:26 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Mon, 12 Dec 2011 18:31:26 +0000
Subject: [New-bugs-announce] [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 22:22:58 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Mon, 12 Dec 2011 21:22:58 +0000
Subject: [New-bugs-announce] [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:43:24 2011
From: report at bugs.python.org (Ryan Twitchell)
Date: Mon, 12 Dec 2011 21:43:24 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 15:08:16 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Dec 2011 14:08:16 +0000
Subject: [New-bugs-announce] [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 20:08:06 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 13 Dec 2011 19:08:06 +0000
Subject: [New-bugs-announce] [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:25:40 2011
From: report at bugs.python.org (Pyry Pakkanen)
Date: Tue, 13 Dec 2011 19:25:40 +0000
Subject: [New-bugs-announce] [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:41:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Dec 2011 19:41:04 +0000
Subject: [New-bugs-announce] [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 21:28:02 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 13 Dec 2011 20:28:02 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 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: [New-bugs-announce] [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:56:36 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 14 Dec 2011 08:56:36 +0000
Subject: [New-bugs-announce] [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 14:11:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 13:11:32 +0000
Subject: [New-bugs-announce] [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 21:18:40 2011
From: report at bugs.python.org (James Classen)
Date: Wed, 14 Dec 2011 20:18:40 +0000
Subject: [New-bugs-announce] [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  Thu Dec 15 04:35:22 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 15 Dec 2011 03:35:22 +0000
Subject: [New-bugs-announce] [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 05:25:47 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 04:25:47 +0000
Subject: [New-bugs-announce] [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 14:28:30 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 13:28:30 +0000
Subject: [New-bugs-announce] [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 21:46:33 2011
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 15 Dec 2011 20:46:33 +0000
Subject: [New-bugs-announce] [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  Fri Dec 16 01:02:54 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 16 Dec 2011 00:02:54 +0000
Subject: [New-bugs-announce] [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:55:50 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 00:55:50 +0000
Subject: [New-bugs-announce] [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:38 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Fri, 16 Dec 2011 01:01:38 +0000
Subject: [New-bugs-announce] [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 08:27:21 2011
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 16 Dec 2011 07:27:21 +0000
Subject: [New-bugs-announce] [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 09:17:41 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 16 Dec 2011 08:17:41 +0000
Subject: [New-bugs-announce] [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 10:04:11 2011
From: report at bugs.python.org (Dongying Zhang)
Date: Fri, 16 Dec 2011 09:04:11 +0000
Subject: [New-bugs-announce] [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 13:58:00 2011
From: report at bugs.python.org (Edmund Eyles)
Date: Fri, 16 Dec 2011 12:58:00 +0000
Subject: [New-bugs-announce] [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 22:00:50 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Dec 2011 21:00:50 +0000
Subject: [New-bugs-announce] [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:37 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Dec 2011 21:21:37 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:53:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 03:53:42 +0000
Subject: [New-bugs-announce] [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 06:37:33 2011
From: report at bugs.python.org (Silverback Networks)
Date: Sat, 17 Dec 2011 05:37:33 +0000
Subject: [New-bugs-announce] [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 07:13:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 06:13:45 +0000
Subject: [New-bugs-announce] [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 12:22:32 2011
From: report at bugs.python.org (Oleg Broytman)
Date: Sat, 17 Dec 2011 11:22:32 +0000
Subject: [New-bugs-announce] [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 18:34:48 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:34:48 +0000
Subject: [New-bugs-announce] [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:53:50 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 17:53:50 +0000
Subject: [New-bugs-announce] [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 19:22:49 2011
From: report at bugs.python.org (Boris FELD)
Date: Sat, 17 Dec 2011 18:22:49 +0000
Subject: [New-bugs-announce] [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:49:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 18:49:11 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 14:07:07 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 13:07:07 +0000
Subject: [New-bugs-announce] [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:38:58 2011
From: report at bugs.python.org (naif)
Date: Sun, 18 Dec 2011 13:38:58 +0000
Subject: [New-bugs-announce] [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 17:31:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 16:31:28 +0000
Subject: [New-bugs-announce] [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 19:21:22 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 18 Dec 2011 18:21:22 +0000
Subject: [New-bugs-announce] [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  Mon Dec 19 03:13:49 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Mon, 19 Dec 2011 02:13:49 +0000
Subject: [New-bugs-announce] [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 05:06:37 2011
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Mon, 19 Dec 2011 04:06:37 +0000
Subject: [New-bugs-announce] [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 06:30:01 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 05:30:01 +0000
Subject: [New-bugs-announce] [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 07:55:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Dec 2011 06:55:57 +0000
Subject: [New-bugs-announce] [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 11:39:59 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 10:39:59 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 12:00:08 2011
From: report at bugs.python.org (naif)
Date: Mon, 19 Dec 2011 11:00:08 +0000
Subject: [New-bugs-announce] [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 17:30:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 16:30:44 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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:37:59 2011
From: report at bugs.python.org (Hiroaki Kawai)
Date: Tue, 20 Dec 2011 01:37:59 +0000
Subject: [New-bugs-announce] [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 14:06:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Dec 2011 13:06:32 +0000
Subject: [New-bugs-announce] [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 16:03:45 2011
From: report at bugs.python.org (Joonas Kuorilehto)
Date: Tue, 20 Dec 2011 15:03:45 +0000
Subject: [New-bugs-announce] [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 20:02:21 2011
From: report at bugs.python.org (Martin)
Date: Tue, 20 Dec 2011 19:02:21 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 13:32:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 12:32:18 +0000
Subject: [New-bugs-announce] [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 15:16:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Dec 2011 14:16:03 +0000
Subject: [New-bugs-announce] [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  Thu Dec 22 15:34:50 2011
From: report at bugs.python.org (naif)
Date: Thu, 22 Dec 2011 14:34:50 +0000
Subject: [New-bugs-announce] [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:49:17 2011
From: report at bugs.python.org (Alexey)
Date: Thu, 22 Dec 2011 14:49:17 +0000
Subject: [New-bugs-announce] [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 16:09:45 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 22 Dec 2011 15:09:45 +0000
Subject: [New-bugs-announce] [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 17:14:51 2011
From: report at bugs.python.org (tom kel)
Date: Thu, 22 Dec 2011 16:14:51 +0000
Subject: [New-bugs-announce] [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 19:09:39 2011
From: report at bugs.python.org (tom kel)
Date: Thu, 22 Dec 2011 18:09:39 +0000
Subject: [New-bugs-announce] [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 21:25:27 2011
From: report at bugs.python.org (WIl Hall)
Date: Thu, 22 Dec 2011 20:25:27 +0000
Subject: [New-bugs-announce] [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  Fri Dec 23 01:54:13 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Fri, 23 Dec 2011 00:54:13 +0000
Subject: [New-bugs-announce] [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 02:23:33 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Fri, 23 Dec 2011 01:23:33 +0000
Subject: [New-bugs-announce] [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 11:18:54 2011
From: report at bugs.python.org (naif)
Date: Fri, 23 Dec 2011 10:18:54 +0000
Subject: [New-bugs-announce] [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 12:37:05 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 23 Dec 2011 11:37:05 +0000
Subject: [New-bugs-announce] [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:45:42 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 23 Dec 2011 11:45:42 +0000
Subject: [New-bugs-announce] [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 16:31:54 2011
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 23 Dec 2011 15:31:54 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 08:44:45 2011
From: report at bugs.python.org (mani and ram)
Date: Sat, 24 Dec 2011 07:44:45 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  Mon Dec 26 06:38:47 2011
From: report at bugs.python.org (wang)
Date: Mon, 26 Dec 2011 05:38:47 +0000
Subject: [New-bugs-announce] [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 13:50:09 2011
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2011 12:50:09 +0000
Subject: [New-bugs-announce] [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 16:55:32 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 15:55:32 +0000
Subject: [New-bugs-announce] [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 18:50:34 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Dec 2011 17:50:34 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 14:18:13 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Wed, 28 Dec 2011 13:18:13 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 15:13:29 2011
From: report at bugs.python.org (andrea crotti)
Date: Wed, 28 Dec 2011 14:13:29 +0000
Subject: [New-bugs-announce] [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 18:21:09 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCR0LDQu9C10LfQuNC9?=)
Date: Wed, 28 Dec 2011 17:21:09 +0000
Subject: [New-bugs-announce] [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 20:20:00 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 28 Dec 2011 19:20:00 +0000
Subject: [New-bugs-announce] [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 22:35:00 2011
From: report at bugs.python.org (sbt)
Date: Wed, 28 Dec 2011 21:35:00 +0000
Subject: [New-bugs-announce] [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  Thu Dec 29 10:04:17 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Thu, 29 Dec 2011 09:04:17 +0000
Subject: [New-bugs-announce] [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 13:13:30 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 29 Dec 2011 12:13:30 +0000
Subject: [New-bugs-announce] [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:27:34 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 29 Dec 2011 12:27:34 +0000
Subject: [New-bugs-announce] [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 18:49:23 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 29 Dec 2011 17:49:23 +0000
Subject: [New-bugs-announce] [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 20:08:39 2011
From: report at bugs.python.org (James Hutchison)
Date: Thu, 29 Dec 2011 19:08:39 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 10:23:35 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 30 Dec 2011 09:23:35 +0000
Subject: [New-bugs-announce] [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 12:17:10 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Fri, 30 Dec 2011 11:17:10 +0000
Subject: [New-bugs-announce] [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:36:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 30 Dec 2011 11:36:08 +0000
Subject: [New-bugs-announce] [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 16:34:14 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 30 Dec 2011 15:34:14 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 23:29:27 2011
From: report at bugs.python.org (Jeff Yurkiw)
Date: Fri, 30 Dec 2011 22:29:27 +0000
Subject: [New-bugs-announce] [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  Sat Dec 31 06:00:13 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Dec 2011 05:00:13 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 12:02:55 2011
From: report at bugs.python.org (Sergey Dorofeev)
Date: Sat, 31 Dec 2011 11:02:55 +0000
Subject: [New-bugs-announce] [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 16:16:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 31 Dec 2011 15:16:28 +0000
Subject: [New-bugs-announce] [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 19:26:17 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 31 Dec 2011 18:26:17 +0000
Subject: [New-bugs-announce] [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>
_______________________________________