From report at bugs.python.org  Thu Nov  1 05:10:24 2012
From: report at bugs.python.org (Bradley Froehle)
Date: Thu, 01 Nov 2012 04:10:24 +0000
Subject: [New-bugs-announce] [issue16378] venv.EnvBuilder docstring
	inconsistencies
Message-ID: <1351743024.49.0.854763959686.issue16378@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

Consider the docstring for venv.EnvBuilder::

    By default, the builder makes the system (global) site-packages dir
    available to the created environment.

    By default, the creation process uses symlinks wherever possible.

It seems to suggest that the `system_site_packages` and `symlink` parameters both default to True, even though the default values for each are False.

The docstring for venv.create is similarly misleading.

----------
assignee: docs at python
components: Documentation
messages: 174388
nosy: bfroehle, docs at python
priority: normal
severity: normal
status: open
title: venv.EnvBuilder docstring inconsistencies
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  1 11:14:38 2012
From: report at bugs.python.org (Torsten Landschoff)
Date: Thu, 01 Nov 2012 10:14:38 +0000
Subject: [New-bugs-announce] [issue16379] SQLite error code not exposed to
	python
Message-ID: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za>


New submission from Torsten Landschoff:

The sqlite3 module does not expose the sqlite3 error codes to python. This makes it impossible to detect specific error conditions directly.

Case in point: If a user selects some random file as the database in our application, we can not detect that it is not a valid database file:

$ /opt/python3/bin/python3
Python 3.4.0a0 (default:2d6eec5d01f7, Nov  1 2012, 10:47:27) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> conn = sqlite3.connect("/etc/passwd")
>>> from pprint import pprint
>>> try:
...     conn.execute("select * from random_table")
... except Exception as e:
...     pprint({name: getattr(e, name) for name in dir(e)})
...     raise
... 
{'__cause__': None,
 '__class__': <class 'sqlite3.DatabaseError'>,
 '__context__': None,
 '__delattr__': <method-wrapper '__delattr__' of DatabaseError object at 0x7ffc9a13b050>,
 '__dict__': {},
 '__dir__': <built-in method __dir__ of DatabaseError object at 0x7ffc9a13b050>,
 '__doc__': None,
 '__eq__': <method-wrapper '__eq__' of DatabaseError object at 0x7ffc9a13b050>,
 '__format__': <built-in method __format__ of DatabaseError object at 0x7ffc9a13b050>,
 '__ge__': <method-wrapper '__ge__' of DatabaseError object at 0x7ffc9a13b050>,
 '__getattribute__': <method-wrapper '__getattribute__' of DatabaseError object at 0x7ffc9a13b050>,
 '__gt__': <method-wrapper '__gt__' of DatabaseError object at 0x7ffc9a13b050>,
 '__hash__': <method-wrapper '__hash__' of DatabaseError object at 0x7ffc9a13b050>,
 '__init__': <method-wrapper '__init__' of DatabaseError object at 0x7ffc9a13b050>,
 '__le__': <method-wrapper '__le__' of DatabaseError object at 0x7ffc9a13b050>,
 '__lt__': <method-wrapper '__lt__' of DatabaseError object at 0x7ffc9a13b050>,
 '__module__': 'sqlite3',
 '__ne__': <method-wrapper '__ne__' of DatabaseError object at 0x7ffc9a13b050>,
 '__new__': <built-in method __new__ of type object at 0x8267e0>,
 '__reduce__': <built-in method __reduce__ of DatabaseError object at 0x7ffc9a13b050>,
 '__reduce_ex__': <built-in method __reduce_ex__ of DatabaseError object at 0x7ffc9a13b050>,
 '__repr__': <method-wrapper '__repr__' of DatabaseError object at 0x7ffc9a13b050>,
 '__setattr__': <method-wrapper '__setattr__' of DatabaseError object at 0x7ffc9a13b050>,
 '__setstate__': <built-in method __setstate__ of DatabaseError object at 0x7ffc9a13b050>,
 '__sizeof__': <built-in method __sizeof__ of DatabaseError object at 0x7ffc9a13b050>,
 '__str__': <method-wrapper '__str__' of DatabaseError object at 0x7ffc9a13b050>,
 '__subclasshook__': <built-in method __subclasshook__ of type object at 0x1238770>,
 '__suppress_context__': False,
 '__traceback__': <traceback object at 0x7ffc9a138cf8>,
 '__weakref__': None,
 'args': ('file is encrypted or is not a database',),
 'with_traceback': <built-in method with_traceback of DatabaseError object at 0x7ffc9a13b050>}
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
sqlite3.DatabaseError: file is encrypted or is not a database
>>>

Currently, one can only match the error message, with is bad programming style.

The error code for this error is SQLITE_NOTADB, as found in the function sqlite3ErrStr when searching for the message in SQLite's main.c at http://www.sqlite.org/src/artifact/02255cf1da50956c5427c469abddb15bccc4ba09

Unfortunately, the sqlite3 module does not expose the error code itself (neither the actual error code nor the defined error codes) in any way. Errors are handled in Modules/_sqlite/util.c:

http://hg.python.org/cpython/file/2d6eec5d01f7/Modules/_sqlite/util.c#l99

I would like to have the defined error codes available in some mapping inside the sqlite3 module as well as the actual error code inside every sqlite exception e as e.sqlite_errcode

----------
components: Library (Lib)
messages: 174395
nosy: torsten
priority: normal
severity: normal
status: open
title: SQLite error code not exposed to python
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov  1 14:02:34 2012
From: report at bugs.python.org (abcdef)
Date: Thu, 01 Nov 2012 13:02:34 +0000
Subject: [New-bugs-announce] [issue16380] true/proper subset
Message-ID: <1351774954.98.0.350778906182.issue16380@psf.upfronthosting.co.za>


New submission from abcdef:

The documentation

http://docs.python.org/2.7/library/stdtypes.html#set-types-set-frozenset

http://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset

of "<" for sets uses "true subset" and "true superset". The correct termininology is "proper subset" and "proper superset", as evidenced by Google searches

http://google.com/search?q="true subset"

http://google.com/search?q="proper subset"

and most set theory books.

----------
assignee: docs at python
components: Documentation
messages: 174410
nosy: abcdef, docs at python
priority: normal
severity: normal
status: open
title: true/proper subset
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Nov  1 14:15:04 2012
From: report at bugs.python.org (Christian Theune)
Date: Thu, 01 Nov 2012 13:15:04 +0000
Subject: [New-bugs-announce] [issue16381] Introduce option to force the
	interpreter to exit upon	MemoryErrors
Message-ID: <1351775704.44.0.517582874178.issue16381@psf.upfronthosting.co.za>


New submission from Christian Theune:

I run long-running server processes (web apps, etc) a lot and I keep encountering the situation that many applications will not properly deal with MemoryError exceptions but end up in an unusable state.

>From an operational perspective I wish the process in this case would just fail and exit.

I talked to Guido about this general idea at EuroPython2012 and he encouraged me to look into this. 

Here's a patch:
https://bitbucket.org/ctheune/cpython/changeset/323bb572344d46df669d3dbec4431cf6720fc5b4

I think it does what I want it to do, but a) my C knowledge is really bad and b) I'm not sure whether this is the right approach anyway.

I'd appreciate feedback and possibly inclusion in the core.

----------
components: Interpreter Core
hgrepos: 158
messages: 174413
nosy: ctheune, gvanrossum
priority: normal
severity: normal
status: open
title: Introduce option to force the interpreter to exit upon MemoryErrors
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov  1 15:16:46 2012
From: report at bugs.python.org (Phil Elson)
Date: Thu, 01 Nov 2012 14:16:46 +0000
Subject: [New-bugs-announce] [issue16382] Better warnings exception for bad
	category
Message-ID: <1351779406.35.0.0813926106632.issue16382@psf.upfronthosting.co.za>


New submission from Phil Elson:

When passing an invalid Warning subclasses to the warnings.warn function, a bare issubclass exception is raised:


>>> import warnings
>>> warnings.warn('hello world', 'not a valid warning type')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class


This exception is consistent accross both Python/_warnings.c and Lib/warnings.py implementations, but I feel it could be more helpful/explicit about the nature problem.


To test both cases I have been using the following code (python3.4):

>>> import test.support
>>> py_warnings = test.warnings = test.support.import_fresh_module('warnings', blocked=['_warnings'])
>>> c_warnings = test.support.import_fresh_module('warnings', fresh=['_warnings'])


Now:


>>> py_warnings.warn('hello world', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lib/python3.4/warnings.py", line 168, in warn
    assert issubclass(category, Warning)
TypeError: issubclass() arg 1 must be a class

>>> c_warnings.warn('hello world', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class



Additionally, there is a difference in the denotational semantics of None between the c and py warnings implementation:


>>> py_warnings.warn('Hello world', None)
__main__:1: UserWarning: Hello world

>>> c_warnings.warn('Hello world', None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class


I can understand that python does not allow the concept of an optional positional arguments and therefore it is arguable that the signatures of the two functions are inevitably going to be different. I defer to someone more knowledgeable in Python to decide if this is a problem, and whether it should be made consistent.


Attached is a patch to address these two issues, with associated tests. Please review (n.b. I am a python developer at heart, and only dabble in C when I have to, so extra scrutiny on the C would be valuable to me) and I'd be happy to get any necessary changed applied to the patch asap.


In short, as a result of applying this patch, the following results ensue:

>>> py_warnings.warn('hello world', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lib/python3.4/warnings.py", line 175, in warn
    'Got {!r}'.format(Warning, category)) from None
ValueError: category must be a subclass of <class 'Warning'>.Got ''


>>> c_warnings.warn('hello world', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: category must be a subclass of <class 'Warning'>. Got ''.
>>> 
>>> c_warnings.warn('hello world', None)
__main__:1: UserWarning: hello world



Thanks!

----------
components: Library (Lib)
files: pelson_warnings_fix.diff
keywords: patch
messages: 174421
nosy: pelson
priority: normal
severity: normal
status: open
title: Better warnings exception for bad category
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file27824/pelson_warnings_fix.diff

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

From report at bugs.python.org  Thu Nov  1 18:28:43 2012
From: report at bugs.python.org (Jim Pattee)
Date: Thu, 01 Nov 2012 17:28:43 +0000
Subject: [New-bugs-announce] [issue16383] Python 3.3 Permission Error with
	User Library on Windows
Message-ID: <1351790923.15.0.230780432409.issue16383@psf.upfronthosting.co.za>


New submission from Jim Pattee:

Python 3.3 Permission Error with User Library on Windows

I have certain scripts that run without error on Python 2.7 and 3.2. With Python 3.3 they get a "Permission Error". This does not occur with every script. The difference seems to be that the ones with a problem use a local user library. The ones without a local library are OK.

A test case is attached. Do not change the directory names. Double click on the file run_test.bat to run. You may need to change the path to the Python executable on your computer. It runs the script astyle_protected.py which uses the library libastyle.py. It runs OK with Python 2.7 and 3.2. But gets an exception with Python 3.3.

----------
components: Windows
files: Projects.zip
messages: 174434
nosy: jimp02
priority: normal
severity: normal
status: open
title: Python 3.3 Permission Error with User Library on Windows
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file27827/Projects.zip

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

From report at bugs.python.org  Thu Nov  1 19:56:19 2012
From: report at bugs.python.org (Sye van der Veen)
Date: Thu, 01 Nov 2012 18:56:19 +0000
Subject: [New-bugs-announce] [issue16384] import.c doesn't handle EOFError
	from PyMarshal_Read*
Message-ID: <1351796179.35.0.165892579115.issue16384@psf.upfronthosting.co.za>


New submission from Sye van der Veen:

The PyMarshal_Read* functions raise EOFError when the end of the file is unexpectedly met.  The current import.c functions propagate this error when reading .pyc or .pyo files.  One consequence of this is that Python will abort on startup if, say, encodings.utf_8's .pyc file is truncated.

I have encountered a scenario where this truncation is common.  If a second Python process is launched while the first is writing the "core" .pyc files, the second process may open the files before they are completely written and will thus see truncated files and abort.  This is a race condition that I was able to reproduce consistently on several Windows Server 2008 RC2 Standard SP1 machines running 32-bit Python 3.2.3 from GNU make with "-j 16" (Intel Xeon E5405 2GHz 2 processors 8GB 64-bit OS).  (Of course, I had to clean the __pycache__ directories between tests.)

This can be fixed in load_source_module by making read_compiled_module failures non-fatal:
    if (cpathname != NULL &&
        (fpc = check_compiled_module(pathname, st.st_mtime, cpathname))) {
        co = read_compiled_module(cpathname, fpc);
        if (co == NULL) PyErr_Clear();
        fclose(fpc);
    }
    if (co != NULL) {
        // etc...
    }
    else {
        co = parse_source_module(pathname, fp);
        // etc...
                write_compiled_module(co, cpathname, &st);
    }
This is similar to how write_compiled_module ignores failures in writing the .pyc files.  It ensures that if the .pyc file is corrupt for _any_ reason, it will get rewritten; this could be made specific to EOFError, but I don't recommed that.  Mostly, it ensures that corrupt .pyc files do not prevent Python from loading if the .py files are valid.

----------
components: None
messages: 174438
nosy: syeberman
priority: normal
severity: normal
status: open
title: import.c doesn't handle EOFError from PyMarshal_Read*
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov  2 13:27:47 2012
From: report at bugs.python.org (Albert Ferras)
Date: Fri, 02 Nov 2012 12:27:47 +0000
Subject: [New-bugs-announce] [issue16385] evaluating dict with repeated keys
	gives no	error/warnings
Message-ID: <1351859267.72.0.446639729186.issue16385@psf.upfronthosting.co.za>


New submission from Albert Ferras:

I normally use dictionaries for configuration purposes in python, but there's a problem where I have a dictionary with many key<->values and one of the keys is repeated.
For example:

lives_in = { 'lion': ['Africa', 'America],
             'parrot': ['Europe'],
             #... 100+ more rows here
             'lion': ['Europe'],
             #... 100+ more rows here
           }

will end up with animal_lives_in['lion'] = 'Europe'. There's no way to detect that I've written a mistake in the code because python won't tell me there's a duplicated key assigned. It's easy to see when you have few keys but hard when you've got many.

I think it should atleast raise a warning when this happens.

----------
components: Interpreter Core
messages: 174507
nosy: Albert.Ferras
priority: normal
severity: normal
status: open
title: evaluating dict with repeated keys gives no error/warnings
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  2 13:36:07 2012
From: report at bugs.python.org (Jan Duzinkiewicz)
Date: Fri, 02 Nov 2012 12:36:07 +0000
Subject: [New-bugs-announce] [issue16386] imp.find_module does not specify
	registry key it	searches on windows
Message-ID: <1351859767.89.0.815277454803.issue16386@psf.upfronthosting.co.za>


New submission from Jan Duzinkiewicz:

quote from http://docs.python.org/3/library/imp.html#imp.find_module:

"...on some systems some other places are looked in as well (on Windows, it looks in the registry which may point to a specific file)."

I actually didn't know the registry key is listed in "using Python on Window" guide until I grepped for PythonCore (which kind of requires to know the key already) - so I'm submitting a patch that cross references find_module docs and using Python on Windows guide.

----------
assignee: docs at python
components: Documentation
files: import_nt_reg.patch
keywords: patch
messages: 174508
nosy: dhgmgn, docs at python
priority: normal
severity: normal
status: open
title: imp.find_module does not specify registry key it searches on windows
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file27843/import_nt_reg.patch

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

From report at bugs.python.org  Fri Nov  2 14:45:20 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 02 Nov 2012 13:45:20 +0000
Subject: [New-bugs-announce] [issue16387] test_cmd_line_script failures
Message-ID: <1351863920.6.0.283546215787.issue16387@psf.upfronthosting.co.za>


New submission from Stefan Krah:

test_cmd_line_script is failing on multiple buildbots:


======================================================================
FAIL: test_non_utf8 (test.test_cmd_line_script.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/test_cmd_line_script.py", line 373, in test_non_utf8
    importlib.machinery.SourceFileLoader)
  File "/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/test_cmd_line_script.py", line 126, in _check_script
    rc, out, err = assert_python_ok(*run_args)
  File "/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/script_helper.py", line 54, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/script_helper.py", line 46, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-20: ordinal not in range(128)

----------------------------------------------------------------------
Ran 23 tests in 4.646s

----------
components: Tests
keywords: buildbot
messages: 174511
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_cmd_line_script failures
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  2 17:54:13 2012
From: report at bugs.python.org (Calvin Owens)
Date: Fri, 02 Nov 2012 16:54:13 +0000
Subject: [New-bugs-announce] [issue16388] Urllib screws up capitalization in
	"User-Agent" HTTP	Header
Message-ID: <1351875253.7.0.390086386154.issue16388@psf.upfronthosting.co.za>


New submission from Calvin Owens:

Urllib encodes as: "User-agent"
The correct form is: "User-Agent"

This is quite important, as it makes this library totally unusable for scraping moronic websites which require a recognized User-Agent string to work correctly, of which there are many.

----------
components: Library (Lib)
messages: 174540
nosy: Calvin.Owens
priority: normal
severity: normal
status: open
title: Urllib screws up capitalization in "User-Agent" HTTP Header
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov  2 19:23:35 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 02 Nov 2012 18:23:35 +0000
Subject: [New-bugs-announce] [issue16389] re._compiled_typed's lru_cache
	causes significant	degradation of the mako_v2 bench
Message-ID: <1351880615.07.0.187029674279.issue16389@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

#9396 replaced a few caches in the stdlib w/ lru_cache, this made the mako_v2 benchmark on Python 3 almost 3x slower than 2.7

The benchmark results are good now that Mako was changed to cache the re itself, but the problem still stands that lru_cache seems to hurt the perf of inline res compared to 2.7. The fix for Mako did not affect the 2.7 benchmark numbers

See more info here:

http://mail.python.org/pipermail/python-dev/2012-November/122521.html

----------
components: Library (Lib)
messages: 174550
nosy: brett.cannon, ncoghlan, pjenvey, rhettinger, zzzeek
priority: normal
severity: normal
status: open
title: re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench
type: performance
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov  2 19:34:24 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Nov 2012 18:34:24 +0000
Subject: [New-bugs-announce] [issue16390] re compilation slow in Python 3.3
	due to	functools.lru_cache overhead
Message-ID: <1351881264.39.0.439395849292.issue16390@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The Mako developers discovered that under Python 3.3 their library under the mako_v2 benchmark went from 2.95x slower than Python 2.7 to 1.25x slower by simply avoiding an re compilation: http://www.makotemplates.org/trac/changeset/c1468b12f115ac9e469150ce24ea042aeae5e270

Their profiling showed that functools.lru_cache in rc._compiled_typed was a major contributor: http://paste.ofcode.org/yZRKnJfTsHesFR8hMWfc7f

----------
components: Library (Lib)
messages: 174554
nosy: brett.cannon, pjenvey
priority: normal
severity: normal
stage: needs patch
status: open
title: re compilation slow in Python 3.3 due to functools.lru_cache overhead
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  2 23:47:05 2012
From: report at bugs.python.org (Nikolay Bryskin)
Date: Fri, 02 Nov 2012 22:47:05 +0000
Subject: [New-bugs-announce] [issue16391] terminator argument for
	logging.FileHandlers
Message-ID: <1351896425.99.0.911168182655.issue16391@psf.upfronthosting.co.za>


New submission from Nikolay Bryskin:

"terminator" argument has appeared in logging.StreamHandler since 3.2, but it also may be useful for FileHandler classes.

----------
components: Library (Lib)
messages: 174594
nosy: nikicat
priority: normal
severity: normal
status: open
title: terminator argument for logging.FileHandlers
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov  3 13:42:34 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 03 Nov 2012 12:42:34 +0000
Subject: [New-bugs-announce] [issue16392] frozen importlib crashes on
	circular imports in ext	modules
Message-ID: <1351946554.54.0.101006341814.issue16392@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

After compiling the stdlib with Cython with the attached script, modules that use circular imports fail to initialise. That includes os and posixpath, as well as shutil and tarfile. Example:

$ ./python -c 'import shutil'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "tarfile.py", line 44, in init tarfile (tarfile.c:44135)
    import shutil
  File "shutil.py", line 14, in init shutil (shutil.c:22497)
    import tarfile
  File "<frozen importlib._bootstrap>", line 1556, in _find_and_load
RuntimeError: maximum recursion depth exceeded

I've tried this with the latest CPython 3.4 hg version, but I'm pretty sure it fails in Py3.3 as well.

----------
components: Interpreter Core
files: cystdlib.py
messages: 174612
nosy: scoder
priority: normal
severity: normal
status: open
title: frozen importlib crashes on circular imports in ext modules
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file27851/cystdlib.py

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

From report at bugs.python.org  Sat Nov  3 14:20:21 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 03 Nov 2012 13:20:21 +0000
Subject: [New-bugs-announce] [issue16393] typo in pkgutil.py
Message-ID: <1351948821.5.0.882170021897.issue16393@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

My guess is that line 454 in pkgutil.py should pass "pkg_name" into the import_module() function, not "pkg". I get the following error when compiling it with Cython:

Error compiling Cython file:
------------------------------------------------------------
...
        msg = "Relative module name {!r} not supported".format(fullname)
        raise ImportError(msg)
    if '.' in fullname:
        # Get the containing package's __path__
        pkg_name = fullname.rpartition(".")[0]
        pkg = importlib.import_module(pkg)
                                        ^
------------------------------------------------------------
pkgutil.py:454:41: local variable 'pkg' referenced before assignment

----------
components: Library (Lib)
messages: 174615
nosy: scoder
priority: normal
severity: normal
status: open
title: typo in pkgutil.py
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov  3 16:15:19 2012
From: report at bugs.python.org (Carsten Milkau)
Date: Sat, 03 Nov 2012 15:15:19 +0000
Subject: [New-bugs-announce] [issue16394] Improving tee() memory footprint
Message-ID: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>


New submission from Carsten Milkau:

The memory footprint of itertools.tee can be reduced substantially by using a shared buffer for the child iterators (see sample code). If local queues are desired for efficient threading support, they can be combined with a global queue, allowing to constrain the size of local queues.

----------
components: Library (Lib)
files: tee.py
messages: 174632
nosy: cami
priority: normal
severity: normal
status: open
title: Improving tee() memory footprint
type: performance
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/file27856/tee.py

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

From report at bugs.python.org  Sat Nov  3 16:18:21 2012
From: report at bugs.python.org (Simon Law)
Date: Sat, 03 Nov 2012 15:18:21 +0000
Subject: [New-bugs-announce] [issue16395] Documentation claims that
	PySequence_Fast returns a	tuple, when it actually returns a list.
Message-ID: <1351955901.81.0.627286470446.issue16395@psf.upfronthosting.co.za>


New submission from Simon Law:

The documentation in Python 2.7, 3.2, and 3.3 claim that:

PyObject* PySequence_Fast(PyObject *o, const char *m)
Return value: New reference.
Returns the sequence o as a tuple, unless it is already a tuple or list, in which case o is returned...

Unfortunately, the code does this in Objects/abstract.c:

    v = PySequence_List(it);

And the header file in Include/abstract.h matches the documentation:

     PyAPI_FUNC(PyObject *) PySequence_Fast(PyObject *o, const char* m);
       /*
     Returns the sequence, o, as a tuple, unless it's already a
     tuple or list.
       */

----------
components: Interpreter Core
messages: 174633
nosy: sfllaw
priority: normal
severity: normal
status: open
title: Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list.
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov  3 16:22:52 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 03 Nov 2012 15:22:52 +0000
Subject: [New-bugs-announce] [issue16396] Importing ctypes.wintypes on Linux
	gives a traceback
Message-ID: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

>>> import ctypes.wintypes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/ctypes/wintypes.py", line 20, in <module>
    class VARIANT_BOOL(ctypes._SimpleCData):
ValueError: _type_ 'v' not supported
>>> 


Shouldn't it just import silently without failing? Or if it's destined to fail, explain how to make a cross-platform import?

----------
components: ctypes
messages: 174634
nosy: techtonik
priority: normal
severity: normal
status: open
title: Importing ctypes.wintypes on Linux gives a traceback
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov  3 19:13:13 2012
From: report at bugs.python.org (Jorge Cardona)
Date: Sat, 03 Nov 2012 18:13:13 +0000
Subject: [New-bugs-announce] [issue16397] UserString doesn't combine nicely
	with strings
Message-ID: <1351966393.52.0.468233404693.issue16397@psf.upfronthosting.co.za>


New submission from Jorge Cardona:

Hi,

I think UserString must play nicely with other standard objects to be useful. For example, right now is not possible to join a list of UserString with a string. 

This shouldn't fail:

   from UserString import UserString
   '.'.join([UserString('some')])

but it fails in 2.7 and it fails too with 3.2 (replacing with collections).

I'm assuming most of the user of UserString, use it as a replacement of a string, and it would be great to actually be able to replace strings passed to thid parties with userstrings. 

I imagine there would be some edge situations harder to resolve, but if someone is just using standard libraries it should be safe to pass a string or an userstring.

Bye.

----------
messages: 174658
nosy: Jorge.Cardona
priority: normal
severity: normal
status: open
title: UserString doesn't combine nicely with strings
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Nov  3 20:31:06 2012
From: report at bugs.python.org (Simon Law)
Date: Sat, 03 Nov 2012 19:31:06 +0000
Subject: [New-bugs-announce] [issue16398] deque.rotate() could be much faster
Message-ID: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>


New submission from Simon Law:

If you look at the implementation of deque.rotate(), it does the equivalent of deque.append(deque.popleft()) or deque.appendleft(deque.pop()).

Unfortunately, for larger rotations, the pop() and append() calls just do too much work. Since the documentation recommends using rotate() to do slicing-style operations, this could get seriously slow.

deque.rotate() could just touch up the internal pointers and use memmove() to realign the data.

Benchmarks, of course, would have to be written to make sure this is a win.

----------
components: Library (Lib)
messages: 174679
nosy: sfllaw
priority: normal
severity: normal
status: open
title: deque.rotate() could be much faster
type: performance
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Nov  4 02:30:23 2012
From: report at bugs.python.org (Markus Amalthea Magnuson)
Date: Sun, 04 Nov 2012 01:30:23 +0000
Subject: [New-bugs-announce] [issue16399] argparse:
Message-ID: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>


New submission from Markus Amalthea Magnuson:

If the default value for a flag is a list, and the action append is used, argparse doesn't seem to override the default, but instead adding to it. I did this test script:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument(
    '--foo',
    action='append',
    default=['bar1', 'bar2']
)
args = parser.parse_args()

print args.foo

Output is as follows:

$ ./argparse_foo_test.py
['bar1', 'bar2']

$ ./argparse_foo_test.py --foo bar3
['bar1', 'bar2', 'bar3']

I would expect the last output to be ['bar3'].

Is this on purpose (although very confusing) or is it a bug?

----------
components: Library (Lib)
files: argparse_foo_test.py
messages: 174735
nosy: Markus.Amalthea.Magnuson
priority: normal
severity: normal
status: open
title: argparse:
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27874/argparse_foo_test.py

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

From report at bugs.python.org  Sun Nov  4 10:57:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 04 Nov 2012 09:57:35 +0000
Subject: [New-bugs-announce] [issue16400] update default PyPI behavior in
	docs re: listing versions
Message-ID: <1352023055.39.0.262942434831.issue16400@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

There is a mismatch between what PyPI and the docs say regarding listing versions of packages on PyPI.

The current docs say, "By default PyPI will list all versions of a given package."

(from http://docs.python.org/3.4/distutils/packageindex.html )

However, PyPI says (and behaves) the opposite way, "By default, each new release will hide all other release from the regular display."

(from the "releases" management page of a project)

----------
assignee: eric.araujo
components: Distutils, Documentation
keywords: easy
messages: 174769
nosy: chris.jerdonek, eric.araujo, loewis, tarek
priority: normal
severity: normal
status: open
title: update default PyPI behavior in docs re: listing versions
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov  4 11:19:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 04 Nov 2012 10:19:41 +0000
Subject: [New-bugs-announce] [issue16401] mention PKG-INFO in the
	documentation
Message-ID: <1352024381.32.0.925896266965.issue16401@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, the documentation makes no mention of the PKG-INFO file.

It would be useful if the documentation mentioned what this file is and how it is created (e.g. via the sdist command), and also linked to PEP 314.  This can be covered somewhere in the distutils documentation:

http://docs.python.org/3.4/distutils/index.html

Index entries should also be created as appropriate.

----------
assignee: eric.araujo
components: Distutils, Documentation
messages: 174773
nosy: chris.jerdonek, eric.araujo, ezio.melotti, georg.brandl, tarek
priority: normal
severity: normal
status: open
title: mention PKG-INFO in the documentation
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov  4 12:27:44 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Nov 2012 11:27:44 +0000
Subject: [New-bugs-announce] [issue16402] range slicing swallows exceptions
	from __index__ methods.
Message-ID: <1352028464.86.0.0930717180418.issue16402@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

>>> class A(object):
...     def __index__(self): raise ZeroDivisionError
... 
[66062 refs]
>>> a = A()
[66065 refs]
>>> range(10)[0:a]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method
[66105 refs]

----------
assignee: mark.dickinson
messages: 174782
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: range slicing swallows exceptions from __index__ methods.

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

From report at bugs.python.org  Sun Nov  4 12:37:06 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 04 Nov 2012 11:37:06 +0000
Subject: [New-bugs-announce] [issue16403] update distutils docs to say that
	maintainer replaces	author
Message-ID: <1352029026.5.0.383021349699.issue16403@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As discussed in issue 16108 and other issues referenced there, distutils lists the maintainer as the author in PKG-INFO when the maintainer is provided.  However, the documentation does not state this.

This issue is to update the distutils documentation to state this, e.g. here:

http://docs.python.org/dev/distutils/setupscript.html#additional-meta-data

and here:

http://docs.python.org/dev/distutils/apiref.html#distutils.core.setup

----------
assignee: eric.araujo
components: Distutils, Documentation
keywords: easy
messages: 174785
nosy: chris.jerdonek, eric.araujo, ezio.melotti, georg.brandl, tarek
priority: normal
severity: normal
status: open
title: update distutils docs to say that maintainer replaces author
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov  4 15:57:07 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 04 Nov 2012 14:57:07 +0000
Subject: [New-bugs-announce] [issue16404] Uses of PyLong_FromLong that don't
	check for errors
Message-ID: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

Examining the CPython sources, there are a number of places where PyLong_FromLong is used without checking its return value. In places where it is done correctly, PyErr_Occurred is often used to avoid having to check every call.

Here are places where it isn't done properly.  I can make patches if desired, though I can't build and test on Windows.  This code is from CPython tip, but the same issues exist in the 2.7 branch.

In Modules/arraymodule.c:

static PyObject *
array_buffer_info(arrayobject *self, PyObject *unused)
{
    PyObject* retval = NULL;
    retval = PyTuple_New(2);
    if (!retval)
        return NULL;

    PyTuple_SET_ITEM(retval, 0, PyLong_FromVoidPtr(self->ob_item));
    PyTuple_SET_ITEM(retval, 1, PyLong_FromLong((long)(Py_SIZE(self))));

    return retval;
}

In Modules/ossaudiodev.c

    /* Construct the return value: a (fmt, channels, rate) tuple that
       tells what the audio hardware was actually set to. */
    rv = PyTuple_New(3);
    if (rv == NULL)
        return NULL;
    PyTuple_SET_ITEM(rv, 0, PyLong_FromLong(fmt));
    PyTuple_SET_ITEM(rv, 1, PyLong_FromLong(channels));
    PyTuple_SET_ITEM(rv, 2, PyLong_FromLong(rate));
    return rv;

These 7 lines could be replaced simply with:

    return Py_BuildValue("(iii)", fmt, channels, rate);


In Python/sysmodule.c, where the PyUnicode_FromString is far more worrisome:

static PyObject *
sys_getwindowsversion(PyObject *self)
{
    PyObject *version;
    int pos = 0;
    OSVERSIONINFOEX ver;
    ver.dwOSVersionInfoSize = sizeof(ver);
    if (!GetVersionEx((OSVERSIONINFO*) &ver))
        return PyErr_SetFromWindowsErr(0);

    version = PyStructSequence_New(&WindowsVersionType);
    if (version == NULL)
        return NULL;

    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.dwMajorVersion));
    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.dwMinorVersion));
    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.dwBuildNumber));
    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.dwPlatformId));
    PyStructSequence_SET_ITEM(version, pos++, PyUnicode_FromString(ver.szCSDVersion));
    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.wServicePackMajor));
    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.wServicePackMinor));
    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.wSuiteMask));
    PyStructSequence_SET_ITEM(version, pos++, PyLong_FromLong(ver.wProductType));

    return version;
}

In Doc/extending/extending.rst, as an example of a correct function!:

   void
   no_bug(PyObject *list)
   {
       PyObject *item = PyList_GetItem(list, 0);

       Py_INCREF(item);
       PyList_SetItem(list, 1, PyLong_FromLong(0L));
       PyObject_Print(item, stdout, 0);
       Py_DECREF(item);
   }

----------
messages: 174809
nosy: nedbat
priority: normal
severity: normal
status: open
title: Uses of PyLong_FromLong that don't check for errors
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Nov  4 16:04:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Nov 2012 15:04:11 +0000
Subject: [New-bugs-announce] [issue16405] Explain how to set up the
	whitespace commit hook locally
Message-ID: <1352041451.32.0.465920697634.issue16405@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Setting up the same commit checks locally that the main repo enforces for incoming patch sets can save a great deal of frustration with the server rejecting "hg push" for changes (this can be especially frustrating if you have already merged changes across branches).

The committer section of the devguide [1] should explain how to:

1. Check out the hooks repo from hg.python.org
2. Configure the whitespace checking hook by adding this to hgrc for the relevant repo(s) (adjusting the path appropriately for the checked out location of the hooks repo):

[hooks]
commit = python:~/devel/hg_hooks/checkwhitespace.py:check_whitespace_single


[1] http://docs.python.org/devguide/committing.html#committing-and-pushing-changes

----------
components: Devguide
messages: 174810
nosy: ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Explain how to set up the whitespace commit hook locally
type: enhancement

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

From report at bugs.python.org  Sun Nov  4 20:03:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 04 Nov 2012 19:03:13 +0000
Subject: [New-bugs-announce] [issue16406] move the "Uploading Packages"
	section to	distutils/packageindex.rst
Message-ID: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

I think the Package Index (PyPI) documentation would be clearer if the section called "Uploading Packages to the Package Index":

http://docs.python.org/3.4/distutils/uploading.html

were made a part of the previous section about PyPI (now called "Registering with the Package Index"):

http://docs.python.org/3.4/distutils/packageindex.html

The combined section could then be renamed simply to "The Python Package Index (PyPI)".

Both sections are small and very closely related.  For example, the second half of the section on uploading (the subsection called "PyPI package display") is not actually about uploading but rather about registering and PyPI in general.  Similarly, the second half of the first section on registering (the subsection called "The .pypirc file") applies equally to uploading as it does to registering.

I was affected by the current organization, for example, because it gave the impression that uploading updates the PyPI package display (which is conceivable since PKG-INFO is part of the uploaded files).  Rather, it is registering a version which updates the package display for that version.

A combined section on PyPI would better reflect how things should be understood.

----------
assignee: eric.araujo
components: Distutils, Documentation
keywords: easy
messages: 174825
nosy: chris.jerdonek, eric.araujo, ezio.melotti, georg.brandl, tarek
priority: normal
severity: normal
status: open
title: move the "Uploading Packages" section to distutils/packageindex.rst
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov  4 20:49:38 2012
From: report at bugs.python.org (yrammos)
Date: Sun, 04 Nov 2012 19:49:38 +0000
Subject: [New-bugs-announce] [issue16407] Python 2.7.3: test_sys fails when
	building under 10.7.5	with dtrace support
Message-ID: <1352058578.46.0.0988393547736.issue16407@psf.upfronthosting.co.za>


New submission from yrammos:

I am building Python 2.7.3 using Homebrew as follows:

    > brew install --with-dtrace --quicktest python

The failing tests are: 
    test_ctypes
    test_sys

Omitting --with-dtrace reduces the failures to one test:
    test_ctypes

@samueljohn from github suggested that I ping Jes?s Cea Avi?n or Ronald Oussoren for this.

----------
components: Tests
messages: 174827
nosy: yrammos
priority: normal
severity: normal
status: open
title: Python 2.7.3: test_sys fails when building under 10.7.5 with dtrace support
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  4 21:22:59 2012
From: report at bugs.python.org (Eric Busboom)
Date: Sun, 04 Nov 2012 20:22:59 +0000
Subject: [New-bugs-announce] [issue16408] zipfile.testzip() opens file but
	does not close it.
Message-ID: <1352060579.29.0.995643495141.issue16408@psf.upfronthosting.co.za>


New submission from Eric Busboom:

The zipfile.testzip() method will open each of the files in a zip archive, but does not close the files, resulting in a file descriptor leak.

----------
components: Library (Lib)
messages: 174829
nosy: Eric.Busboom
priority: normal
severity: normal
status: open
title: zipfile.testzip() opens file but does not close it.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  4 23:27:05 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 04 Nov 2012 22:27:05 +0000
Subject: [New-bugs-announce] [issue16409] urlretrieve regression: first call
	returns block size as	0
Message-ID: <1352068025.04.0.157597994471.issue16409@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Renamed urllib.urlretrieve changed behaviour in Py3k, which leads to ZeroDivisionErrors in applications that use block_size parameter for calculations. Previously, block size was constant. Now it varies making it impossible to exactly calculate value transferred so far. Test file attached.


C:\Python33\python.exe test.py
0 0 59654
1 8192 59654
2 8192 59654
3 8192 59654
4 8192 59654
5 8192 59654
6 8192 59654
7 8192 59654
8 2310 59654

C:\Python27\python.exe test.py
(0, 8192, 59654)
(1, 8192, 59654)
(2, 8192, 59654)
(3, 8192, 59654)
(4, 8192, 59654)
(5, 8192, 59654)
(6, 8192, 59654)
(7, 8192, 59654)
(8, 8192, 59654)

----------
components: Library (Lib)
files: test.py
messages: 174836
nosy: techtonik
priority: normal
severity: normal
status: open
title: urlretrieve regression: first call returns block size as 0
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27886/test.py

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

From report at bugs.python.org  Sun Nov  4 23:53:32 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 04 Nov 2012 22:53:32 +0000
Subject: [New-bugs-announce] [issue16410] rewrite winsound with ctypes
Message-ID: <1352069612.71.0.36893630411.issue16410@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://hg.python.org/cpython/file/tip/PC/winsound.c

No need to maintain this in C. It doesn't seem like a critical part of code. Will there be significant performance penalty?

----------
components: Library (Lib), ctypes
messages: 174838
nosy: techtonik
priority: normal
severity: normal
status: open
title: rewrite winsound with ctypes
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov  5 01:29:24 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 05 Nov 2012 00:29:24 +0000
Subject: [New-bugs-announce] [issue16411] zlib.Decompress.decompress()
	retains pointer to input	buffer without acquiring reference to it
Message-ID: <1352075364.32.0.439696678294.issue16411@psf.upfronthosting.co.za>


New submission from Nadeem Vawda:

When calling zlib.Decompress.decompress() with a max_length argument,
if the input data is not full consumed, the next_in pointer in the
z_stream struct are left pointing into the data object, but the
decompressor does not hold a reference to this object. This same
pointer is reused (perhaps unintentionally) if flush() is called
without calling decompress() again.

If the data object gets deallocated between the calls to decompress()
and to flush(), zlib will then try to access this deallocated memory,
and most likely return bogus output (or segfault). See the attached
script for a demonstration.

I see two potential solutions:

  1. Set avail_in to zero in flush(), so that it does not try to use
     leftover data (or whatever is else where that data used to be).

  2. Have decompress() check if there is leftover data, and if so,
     save a reference to the object until a) we consume the rest of
     the data in flush(), or b) discard it in a subsequent call to
     decompress().

Solution 2 would be less disruptive to code that depends on the existing
behavior (in non-pathological cases), but I'm don't like the maintenance
burden of adding yet another thing to keep track of to the decompressor
state. The PyZlib_objdecompress function is complex enough as it is, and
we can expect more bugs like this to creep in the more we cram additional
logic into it. So I'm more in favor of solution 1.

Any thoughts?

----------
files: zlib_stale_ptr.py
messages: 174853
nosy: nadeem.vawda, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: zlib.Decompress.decompress() retains pointer to input buffer without acquiring reference to it
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27889/zlib_stale_ptr.py

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

From report at bugs.python.org  Mon Nov  5 01:47:25 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Nov 2012 00:47:25 +0000
Subject: [New-bugs-announce] [issue16412] test_shutil: 2 failures related to
	symlinks
Message-ID: <1352076445.7.0.182324345971.issue16412@psf.upfronthosting.co.za>


New submission from STINNER Victor:

======================================================================
FAIL: test_copymode_follow_symlinks (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\victor\default\lib\test\test_shutil.py", line 258, in test_copymode_f
ollow_symlinks
    self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
AssertionError: 33206 != 33060

======================================================================
FAIL: test_move_dangling_symlink (test.test_shutil.TestMove)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\victor\default\lib\test\test_shutil.py", line 60, in wrap
    return func(*args, **kwargs)
  File "C:\victor\default\lib\test\test_shutil.py", line 1435, in test_move_dang
ling_symlink
    self.assertEqual(os.path.realpath(src), os.path.realpath(dst_link))
AssertionError: 'c:\\users\\haypo\\appdata\\local\\temp\\tmpmhpdb_\\baz' != 'c:\
\users\\haypo\\appdata\\local\\temp\\tmpnsjap0\\quux'
- c:\users\haypo\appdata\local\temp\tmpmhpdb_\baz
?                                      ^^ ^^^ ^^^
+ c:\users\haypo\appdata\local\temp\tmpnsjap0\quux
?                                      ^^^^ ^ ^^^^

----------
components: Windows
messages: 174856
nosy: haypo
priority: normal
severity: normal
status: open
title: test_shutil: 2 failures related to symlinks

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

From report at bugs.python.org  Mon Nov  5 12:24:28 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Nov 2012 11:24:28 +0000
Subject: [New-bugs-announce] [issue16413] Non cross-platform behavior of
	os.path.split
Message-ID: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

os.path.split('c:foo') gives ('c:', 'foo') on Windows and ('', 'c:foo') on Linux, which is not documented. IIUC, the behavior change in os module is not possible, so a documentation note will be appreciated.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 174890
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Non cross-platform behavior of os.path.split
versions: 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/issue16413>
_______________________________________

From report at bugs.python.org  Mon Nov  5 13:12:14 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Nov 2012 12:12:14 +0000
Subject: [New-bugs-announce] [issue16414] Add support.NONASCII to test
	non-ASCII characters
Message-ID: <1352117534.37.0.611340206867.issue16414@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds support.NONASCII to have a "portable" non-ASCII character that can be used to test non-ASCII strings. The patch uses it in some existing functions.

I wrote the patch on the default branch, we may start to use it since Python 3.2.

----------
components: Tests
files: support_non_ascii.patch
keywords: patch
messages: 174897
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add support.NONASCII to test non-ASCII characters
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27892/support_non_ascii.patch

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

From report at bugs.python.org  Mon Nov  5 16:26:24 2012
From: report at bugs.python.org (Alessandro Pilotti)
Date: Mon, 05 Nov 2012 15:26:24 +0000
Subject: [New-bugs-announce] [issue16415] eventlet.monkey_patch() breaks
	subprocess.Popen on	Windows
Message-ID: <1352129184.29.0.628026501829.issue16415@psf.upfronthosting.co.za>


New submission from Alessandro Pilotti:

eventlet.monkey_patch() breaks subprocess.Popen on Windows with error:

NotImplementedError: set_nonblocking() on a file object with no setblocking() method (Windows pipes don't support non-blocking I/O)

Here's the full stack trace:
http://paste.openstack.org/show/24032/

Workaround: eventlet.monkey_patch(os=False)

----------
components: IO, Interpreter Core, Library (Lib)
messages: 174915
nosy: alexpilotti
priority: normal
severity: normal
status: open
title: eventlet.monkey_patch() breaks subprocess.Popen on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  5 23:18:23 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Nov 2012 22:18:23 +0000
Subject: [New-bugs-announce] [issue16416] Mac OS X: don't use the locale
	encoding but UTF-8 to	encode and decode filenames
Message-ID: <1352153903.84.0.995057035576.issue16416@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since the changeset 45079ad1e260 (issue #4388), command line arguments are decoded from UTF-8 instead of the locale encoding. Functions of Python/fileutils.c are still using the locale encoding.

It does not work: see issue #16218. On Mac OS X, in the command line "python script.py", the filename "script.py" is decoded from UTF-8 (by _Py_DecodeUTF8_surrogateescape) but then it is passed to _Py_fopen() which encodes the filename to the locale encoding (ex: ISO-8859-1 if $LANG, $LC_CTYPE and $LC_ALL environment variables are not set). The result is mojibake and Python fails to open the script.

Attached patch modifies function of Python/fileutils.c to use UTF-8 to encode and decode filenames, instead of the locale encoding on Mac OS X.

I don't know yet if Module/getpath.c should also decode paths from UTF-8 instead of the locale encoding on Mac OS X. We may expose _Py_decode_filename().

----------
assignee: ronaldoussoren
components: Macintosh
files: macosx.patch
keywords: patch
messages: 174943
nosy: haypo, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac OS X: don't use the locale encoding but UTF-8 to encode and decode filenames
versions: Python 3.4
Added file: http://bugs.python.org/file27903/macosx.patch

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

From report at bugs.python.org  Mon Nov  5 23:57:08 2012
From: report at bugs.python.org (Rosa Maria)
Date: Mon, 05 Nov 2012 22:57:08 +0000
Subject: [New-bugs-announce] [issue16417] Integer converted in tuple without
	request
Message-ID: <1352156228.06.0.802520364311.issue16417@psf.upfronthosting.co.za>


New submission from Rosa Maria:

in instruction:
  b = int(input('Dame valor (mayor) de b = '))

later is an instruction:
  while b > 0:

and the result is:
  Traceback (most recent call last):
  File "H:\Soft_nuevo\Reptil\GCD_MCD_Euclides_Extendido-0.py", line 39, in <module>
    while b > 0:
TypeError: unorderable types: tuple() > int()

----------
components: IDLE
files: GCD_MCD_Euclides_Extendido-0.py
messages: 174945
nosy: Gravitania
priority: normal
severity: normal
status: open
title: Integer converted in tuple without request
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file27904/GCD_MCD_Euclides_Extendido-0.py

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

From report at bugs.python.org  Tue Nov  6 00:11:51 2012
From: report at bugs.python.org (Juraj Variny)
Date: Mon, 05 Nov 2012 23:11:51 +0000
Subject: [New-bugs-announce] [issue16418] argparse with many choices can
	generate absurdly long	usage message
Message-ID: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>


New submission from Juraj Variny:

Example:

parser.add_argument("-p","--port", help="Listening port", type=int, choices=range(1, 65535),default=8007,required = False)

generates this usage text:

usage: agent.py [-h]
                [-p {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30, <...snip...> ,65522,65523,65524,65525,65526,65527,65528,65529,65530,65531,65532,65533,65534}]

optional arguments:
  -h, --help            show this help message and exit
  -p {1,2,3,4,5,6,7,8,9,10,11,12,13,14, <...snip...> ,65525,65526,65527,65528,65529,65530,65531,65532,65533,65534}
                        Listening port

----------
components: Library (Lib)
messages: 174947
nosy: Juraj.Variny
priority: normal
severity: normal
status: open
title: argparse with many choices can generate absurdly long usage message
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  6 04:39:12 2012
From: report at bugs.python.org (DDarko)
Date: Tue, 06 Nov 2012 03:39:12 +0000
Subject: [New-bugs-announce] [issue16419] email.message._headers is a list
Message-ID: <1352173152.15.0.701713687458.issue16419@psf.upfronthosting.co.za>


New submission from DDarko:

in Python 3.3 lib.email.message


  File "email/message.py", line 151, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "email/generator.py", line 112, in flatten
    self._write(msg)
  File "email/generator.py", line 171, in _write
    self._write_headers(msg)
  File "email/generator.py", line 197, in _write_headers
    for h, v in msg.raw_items():
  File "email/message.py", line 441, in raw_items
    return iter(self._headers.copy())
AttributeError: 'list' object has no attribute 'copy'




http://hg.python.org/cpython/file/ec00f8570c55/Lib/email/message.py
in line 443 is:
return iter(self._headers.copy())
I think that it should be:
return iter(self._headers[:])

----------
components: Library (Lib)
messages: 174952
nosy: DDarko
priority: normal
severity: normal
status: open
title: email.message._headers is a list
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  6 15:16:41 2012
From: report at bugs.python.org (Daniele Varrazzo)
Date: Tue, 06 Nov 2012 14:16:41 +0000
Subject: [New-bugs-announce] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
Message-ID: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo:

I've converted the DBAPI to reST, mostly to allow linking from external documentation. It would be great to replace the current text only version with it. File attached.

----------
assignee: docs at python
components: Documentation
files: pep-0249.txt
messages: 174965
nosy: docs at python, lemburg, piro
priority: normal
severity: normal
status: open
title: PEP 249 (DB-API 2.0) converted to reStructuredText
type: enhancement
Added file: http://bugs.python.org/file27908/pep-0249.txt

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

From report at bugs.python.org  Tue Nov  6 15:42:53 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Tue, 06 Nov 2012 14:42:53 +0000
Subject: [New-bugs-announce] [issue16421]
	importlib.machinery.ExtensionFileLoader cannot load	several
	modules from the same shared object
Message-ID: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>


New submission from V?clav ?milauer:

This issue was split off issue16194 (I am not copying the whole discussion here). It was suggested a new issue is opened for Python3, where a proper fix can be done.

Python internally caches dynamically loaded modules, but the cache is based on the filename only. If one file contains several modules, only the first of them is imported and initialized properly. This interface was previously exposed via imp.load_dynamic, the same codepath is used by importlib.machinery.ExtensionFileLoader now.

A solution is to cache by the (filename, modulename) tuple, which avoids any ambiguity.

I am attaching a simple patch for that, agains current hg tip (80272:ec00f8570c55), and tested with the scripot attached to issue16194.

I have not modified the test suite, I am not sure whether testing compiled modules is actually supported (did not see any compiled files in there), I will be glad for help.

----------
components: Extension Modules
files: many-modules-in-one-so_1.diff
keywords: patch
messages: 174967
nosy: Arfrever, amaury.forgeotdarc, brett.cannon, docs at python, eudoxos, ncoghlan, r.david.murray
priority: normal
severity: normal
status: open
title: importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file27909/many-modules-in-one-so_1.diff

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

From report at bugs.python.org  Wed Nov  7 00:04:32 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Nov 2012 23:04:32 +0000
Subject: [New-bugs-announce] [issue16422] Decimal constants should be the
	same for py & c module	versions
Message-ID: <1352243072.7.0.172202427654.issue16422@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Right now decimal.py defines 'ROUND_DOWN' as 'ROUND_DOWN' (string), whereas C version define it as 1 (integer).

While using constant values directly in your code is not a good idea, there is another case where it doesn't work: if you serialize decimal values along with their meta information, such as rounding settings.  In this case, when you unserialize data that was serialized with python decimal, those meta-settings won't work for 'c' decimal.

----------
messages: 175024
nosy: skrah, yselivanov
priority: normal
severity: normal
status: open
title: Decimal constants should be the same for py & c module versions
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov  7 04:28:02 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Wed, 07 Nov 2012 03:28:02 +0000
Subject: [New-bugs-announce] [issue16423] urllib data URL recipe
Message-ID: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>


New submission from Mathias Panzenb?ck:

I think it would be really helpful if urllib would support data URLs. However, I was told on the python-ideas mailing list that it would probably only added as recipe in the documentation. The attached patch adds such an recipe to the urllib.request documentation. I've never written a doc patch (or any patch) for python before, so I don't know if I added it at the right place in the right format.

----------
assignee: docs at python
components: Documentation
files: doc-urllib.request-data-url-recipe.patch
hgrepos: 160
keywords: patch
messages: 175041
nosy: docs at python, panzi
priority: normal
severity: normal
status: open
title: urllib data URL recipe
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file27914/doc-urllib.request-data-url-recipe.patch

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

From report at bugs.python.org  Wed Nov  7 07:15:33 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 07 Nov 2012 06:15:33 +0000
Subject: [New-bugs-announce] [issue16424] regression:
	os.path.split('//hostname/foo/bar.txt')
Message-ID: <1352268933.45.0.882120414377.issue16424@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Windows.

Python 3:
>>> import os.path as osp
>>> osp.split('//hostname/foo/')
('//hostname/foo/', '')

Python 2:
>>> osp.split('//hostname/foo/')
('//hostname/foo', '')


But Python 3 again:
>>> osp.split('//hostname/foo/bar/')
('//hostname/foo/bar', '')

----------
components: Library (Lib)
messages: 175044
nosy: techtonik
priority: normal
severity: normal
status: open
title: regression: os.path.split('//hostname/foo/bar.txt')
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov  7 10:05:50 2012
From: report at bugs.python.org (Martin Kugler)
Date: Wed, 07 Nov 2012 09:05:50 +0000
Subject: [New-bugs-announce] [issue16425] minidom replaceChild(new_child,
	old_child) removes new_child even if in another document
Message-ID: <1352279150.2.0.240477416324.issue16425@psf.upfronthosting.co.za>


New submission from Martin Kugler:

Calling doc.replaceChild(new_child, old_child) with new_child and old_child being similar nodes in two different documents results in new_child to be removed from its document instead of old_child being removed from doc.

Example:
        new_child = get_element_x(doc_a)
        old_child = get_element_x(doc_b)
        parent = get_element_y(doc_b)
        parent.replaceChild(new_child, old_child)

=> new_child will be removed from doc_a. Instead old_child should be removed from doc_b.

----------
components: XML
messages: 175057
nosy: Martin.Kugler
priority: normal
severity: normal
status: open
title: minidom replaceChild(new_child, old_child) removes new_child even if in another document
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  7 11:33:38 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Nov 2012 10:33:38 +0000
Subject: [New-bugs-announce] [issue16426] RoundUp signature removal test
	(please ignore)
Message-ID: <1352284418.2.0.897499151783.issue16426@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

As discussed on http://psf.upfronthosting.co.za/roundup/meta/issue491, I'm creating this ticket to test the roundup email interface.

----------
assignee: lemburg
components: None
messages: 175063
nosy: lemburg
priority: normal
severity: normal
status: open
title: RoundUp signature removal test (please ignore)
type: behavior

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

From report at bugs.python.org  Wed Nov  7 13:38:49 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Nov 2012 12:38:49 +0000
Subject: [New-bugs-announce] [issue16427] Faster hash implementation
Message-ID: <1352291929.32.0.895096534658.issue16427@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In the discussion of issue14621 it was noted that much more complex hash algorithms can overtake the current one due to the fact that they process more data at a time.  Here is a patch that implements this idea for the current algorithm.  Also code duplication removed.

Microbenchmarks:

$ ./python -m timeit -n 1 -s "t = b'a' * 10**8"  "hash(t)"
$ ./python -m timeit -n 1 -s "t = 'a' * 10**8"  "hash(t)"
$ ./python -m timeit -n 1 -s "t = '\u0100' * 10**8"  "hash(t)"
$ ./python -m timeit -n 1 -s "t = '\U00010000' * 10**8"  "hash(t)"

Results on 32-bit Linux on AMD Athlon 64 X2 4600+:

       original  patched    speedup

bytes  181 msec  45.7 msec  4x
UCS1   429 msec  45.7 msec  9.4x
UCS2   179 msec  92 msec    1.9x
UCS4   183 msec  183 msec   1x

If the idea is acceptable, I will create benchmarks for short strings.

----------
components: Interpreter Core
files: fast_hash.patch
keywords: patch
messages: 175093
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Faster hash implementation
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file27920/fast_hash.patch

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

From report at bugs.python.org  Wed Nov  7 15:46:49 2012
From: report at bugs.python.org (pythonick)
Date: Wed, 07 Nov 2012 14:46:49 +0000
Subject: [New-bugs-announce] [issue16428] turtle with compound shape doesn't
	get clicks
Message-ID: <1352299609.35.0.759398778926.issue16428@psf.upfronthosting.co.za>


New submission from pythonick:

In the standard turtle module, when a turtle has a custom shape of type "compound", it doesn't to respond to click events. No problem with polygon shapes.

Observed on Windows XP, python 3.2.3, turtle version 1.1b, and on Linux, python 2.7. 

Test code:

##################################################
import turtle
square = ((0,0),(0,20),(20,20),(20,0))
turtle.addshape("sq1", square) # sq1 = polygon shape
s = turtle.Shape("compound")
s.addcomponent(square, "red")
turtle.addshape("sq2", s) # sq2 = compound shape
t1 = turtle.Turtle(shape="sq1")
t2 = turtle.Turtle(shape="sq2")
t2.fd(20)
def click(x,y): print("click at",x,y)
t1.onclick(click)
t2.onclick(click)
turtle.mainloop()
##################################################

When you click on the black square (i.e. t1), the message "click at..." is printed. When you click on the red square (i.e. t2), nothing happens.

----------
components: Library (Lib)
messages: 175106
nosy: pythonick
priority: normal
severity: normal
status: open
title: turtle with compound shape doesn't get clicks
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Nov  7 15:59:26 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Nov 2012 14:59:26 +0000
Subject: [New-bugs-announce] [issue16429] Emit SyntaxWarning for code that
	risks UnboundLocalError
Message-ID: <1352300366.42.0.384864300614.issue16429@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The compiler is actually in a fairly good position to tell when code is at risk of triggering UnboundLocalError at runtime: specifically, in the section of the code that checks for duplicated parameter names [1]

Now, we can't emit SyntaxError here for backwards compatibility reasons (if you have an early reference that is never executed, your code is dodgy but will still run OK).

However, we should be able to emit a Syntax *Warning* when we detect an existing symbol at function scope having DEF_LOCAL applied for the first time *after* it has already been referenced in a way which doesn't create a local variable.

Something like:

SyntaxWarning: Local variable NAME bound after earlier reference (risks UnboundLocalError when function is called)

[1] http://hg.python.org/cpython/file/default/Python/symtable.c#l1002

----------
messages: 175107
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Emit SyntaxWarning for code that risks UnboundLocalError
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov  7 18:00:35 2012
From: report at bugs.python.org (Sebastien Estienne)
Date: Wed, 07 Nov 2012 17:00:35 +0000
Subject: [New-bugs-announce] [issue16430] re.match blocking and taking 100%
	CPU
Message-ID: <1352307635.84.0.490931242239.issue16430@psf.upfronthosting.co.za>


New submission from Sebastien Estienne:

Hello

re.match is blocked and takes 100% cpu forever

re_bug.py is an example of the bug.

thanx

----------
components: Regular Expressions
files: re_bug.py
messages: 175109
nosy: Sebastien.Estienne, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.match blocking and taking 100% CPU
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file27921/re_bug.py

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

From report at bugs.python.org  Wed Nov  7 20:26:17 2012
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Wed, 07 Nov 2012 19:26:17 +0000
Subject: [New-bugs-announce] [issue16431] CDecimal disregards subclass
	passed into __new__ when	value argument is an instance of Decimal
Message-ID: <1352316377.68.0.68538809412.issue16431@psf.upfronthosting.co.za>


New submission from Elvis Pranskevichus:

Consider the following:

import decimal

class MyDecimal(decimal.Decimal):
    def __new__(cls, value):
        return super().__new__(cls, value)

a = decimal.Decimal('1.0')
b = MyDecimal(a)
c = MyDecimal('1.0')

print(type(a), type(b), isinstance(b, MyDecimal), type(c), isinstance(c, MyDecimal))

Running the above in 3.3 produces:

<class 'decimal.Decimal'> <class 'decimal.Decimal'> False <class '__main__.MyDecimal'> True

Which shows that Decimal.__new__(cls, Decimal()) will always return its argument regardless of cls.

----------
messages: 175121
nosy: Elvis.Pranskevichus, skrah
priority: normal
severity: normal
status: open
title: CDecimal disregards subclass passed into __new__ when value argument is an instance of Decimal
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov  7 22:28:24 2012
From: report at bugs.python.org (Andrew Gorcester)
Date: Wed, 07 Nov 2012 21:28:24 +0000
Subject: [New-bugs-announce] [issue16432] Template strings documentation in
	Python 3 refers to %	substitution in present tense
Message-ID: <1352323704.72.0.0858754286751.issue16432@psf.upfronthosting.co.za>


New submission from Andrew Gorcester:

Documentation here: http://docs.python.org/3/library/string.html#template-strings says "Instead of the normal %-based substitutions, Templates support $-based substitutions..."

I believe it is confusing to refer to %-based substitutions in a way that implies they still exist in Python 3.  It would be better to fix this to either refer to {} substitution or to remove the reference comparing it to normal string substitution altogether.

----------
assignee: docs at python
components: Documentation
messages: 175123
nosy: andrewsg, docs at python
priority: normal
severity: normal
status: open
title: Template strings documentation in Python 3 refers to % substitution in present tense
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 10:05:13 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Nov 2012 09:05:13 +0000
Subject: [New-bugs-announce] [issue16433] unittest.TestCase.assertNotEqual
	has incorrect docstring.
Message-ID: <1352365513.53.0.838021442266.issue16433@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The TestCase.assertNotEqual docstring currently says:

  Fail if the two objects are equal as determined by the '==' operator.

This doesn't match the implementation, which checks that '!=' gives True (rather than checking that '==' gives False).  The online docs look fine.

----------
components: Library (Lib)
messages: 175142
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: unittest.TestCase.assertNotEqual has incorrect docstring.
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 13:33:10 2012
From: report at bugs.python.org (=?utf-8?q?Erik_G=C3=BCnther?=)
Date: Thu, 08 Nov 2012 12:33:10 +0000
Subject: [New-bugs-announce] [issue16434] SocketServer call shutdown in the
	wrong way
Message-ID: <1352377990.43.0.148428023395.issue16434@psf.upfronthosting.co.za>


New submission from Erik G?nther:

I have a small development WSGI-server using PythonPaste and when shutting it down I somtimes get the following error on one or two threads:


-----------------------8<-----------------------------------

Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/SocketServer.py", line 586, in process_request_thread
    self.shutdown_request(request)
  File "/usr/lib/python2.7/SocketServer.py", line 459, in shutdown_request
    request.shutdown(socket.SHUT_WR)
TypeError: shutdown() takes exactly 0 arguments (1 given)

--------------------->8-------------------------------------


/usr/lib/python2.7/SocketServer.py: ------------8<-----------

    def shutdown_request(self, request):
        """Called to shutdown and close an individual request."""
        try:
            #explicitly shutdown.  socket.close() merely releases
            #the socket and waits for GC to perform the actual close.
            request.shutdown(socket.SHUT_WR)
        except socket.error:
            pass #some platforms may raise ENOTCONN here
        self.close_request(request)

----------------->8------------------------------------------


So I recon its a bug...

----------
messages: 175152
nosy: Erik.G?nther
priority: normal
severity: normal
status: open
title: SocketServer call shutdown in the wrong way
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  8 14:50:11 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 13:50:11 +0000
Subject: [New-bugs-announce] [issue16435] Python 3 doc link to Python 2 FAQ
Message-ID: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/tutorial/whatnow.html

The last paragraph links to http://www.python.org/doc/faq/, which defaults to Python 2 FAQ.

----------
assignee: docs at python
components: Documentation
messages: 175156
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Python 3 doc link to Python 2 FAQ
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  8 14:59:17 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 13:59:17 +0000
Subject: [New-bugs-announce] [issue16436] Missing anchor in doc
Message-ID: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/functions.html#func-frozenset

http://docs.python.org/3/library/functions.html#func-set

frozenset and set function have no links to their definitions. Also the anchor name is prefixed with func, which is different to other builtin functions.

----------
assignee: docs at python
components: Documentation
messages: 175157
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Missing anchor in doc
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 15:04:40 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 14:04:40 +0000
Subject: [New-bugs-announce] [issue16437] issubclass doc improvement
Message-ID: <1352383480.96.0.515607744563.issue16437@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/functions.html#issubclass

"classinfo may be a tuple of class objects."

I suggest make it clear like isinstance, use something like this:

classinfo may be a tuple of class objects and such tuples.

----------
assignee: docs at python
components: Documentation
messages: 175158
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: issubclass doc improvement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 15:19:31 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 14:19:31 +0000
Subject: [New-bugs-announce] [issue16438] Numeric operator predecence
	confusing
Message-ID: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex

"All numeric types (except complex) support the following operations, sorted by ascending priority."

It list '-' after '+', '/' after '*'. That is to mean '-' has higher precedence than '+'. That is wrong, and is contradicting with here:

http://docs.python.org/3/reference/expressions.html#summary

This should be made clear.

----------
assignee: docs at python
components: Documentation
messages: 175163
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Numeric operator predecence confusing
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 16:08:23 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 15:08:23 +0000
Subject: [New-bugs-announce] [issue16439] Code not collapsed correctly
Message-ID: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/stdtypes.html#str.title

The second snippets is not collapsed correctly.

----------
assignee: docs at python
components: Documentation
messages: 175171
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Code not collapsed correctly
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 16:22:55 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 15:22:55 +0000
Subject: [New-bugs-announce] [issue16440] Exception type
Message-ID: <1352388175.4.0.551627843013.issue16440@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/stdtypes.html#methods

"Attempting to set a method attribute results in a TypeError being raised."

But in the example, if we do c.method.whoami = 'c', we get AttributeError instead of TypeError.

----------
assignee: docs at python
components: Documentation
messages: 175174
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Exception type
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 16:26:23 2012
From: report at bugs.python.org (Chris Withers)
Date: Thu, 08 Nov 2012 15:26:23 +0000
Subject: [New-bugs-announce] [issue16441] range usage in gzip module leads
	to excessive memory	usage.
Message-ID: <1352388383.51.0.371199818587.issue16441@psf.upfronthosting.co.za>


New submission from Chris Withers:

gzip.py uses range instead of xrange in two places.
This results in excessive memory usage when opening large .gz files.
I actually bumped into this using tarfile.

Am I right in thinking that range basically *is* xrange in 3.x? If so, this bug applies only to 2.6 and 2.7.

----------
assignee: cjw296
components: Library (Lib)
messages: 175176
nosy: cjw296
priority: normal
severity: normal
stage: needs patch
status: open
title: range usage in gzip module leads to excessive memory usage.
type: resource usage
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Nov  8 17:48:46 2012
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 08 Nov 2012 16:48:46 +0000
Subject: [New-bugs-announce] [issue16442] PATH_MAX vs MAXPATHLEN vs
	pathconf(..., _PC_PATH_MAX).
Message-ID: <1352393326.63.0.0902907389394.issue16442@psf.upfronthosting.co.za>


New submission from Trent Nelson:

Two immediate issues identified whilst trying to build on HP-UX and IRIX:

1.  Our source is wildly inconsistent with regards to using PATH_MAX versus MAXPATHLEN.

2.  The current logic in osdefs.h is insufficient for ensuring one or the other always has a value (complicated by issue 1 above).

Christian alluded to introducing a PY_PATH_MAX define, which I like.  So, my proposal is to fix the logic in osdefs.h so that it works on a wider range of platforms, with the end goal of defining PY_PATH_MAX, then replacing all occurrences of PATH_MAX|MAXPATHLEN in our tree with the new PY_PATH_MAX.

(It's worth mentioning that, technically, we shouldn't be using PATH_MAX or MAXPATHLEN.  We should be using pathconf(..., _PC_PATH_CONF) to determine the maximum length of the underlying filesystem at runtime and dynamically allocating buffers based on that value.

However, that's a huge, non-trivial change.  For another day.)

----------
assignee: trent
components: Build
messages: 175183
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX).
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 21:07:12 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Nov 2012 20:07:12 +0000
Subject: [New-bugs-announce] [issue16443] Add docstrings to regular
	expression match objects
Message-ID: <1352405232.66.0.722959472058.issue16443@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The match objects currently do not have useful docstrings.  An easy task is to add docstrings modeled after the text in the regular docs.

  import re
  mo = re.search('abc', 'abc')
  help(mo)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 175188
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Add docstrings to regular expression match objects
type: enhancement
versions: 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/issue16443>
_______________________________________

From report at bugs.python.org  Thu Nov  8 23:52:14 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Nov 2012 22:52:14 +0000
Subject: [New-bugs-announce] [issue16444] Use support.TESTFN_UNDECODABLE on
	UNIX
Message-ID: <1352415134.41.0.932872803675.issue16444@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch changes how support.TESTFN_UNDECODABLE is computed on UNIX: use the filesystem encoding in *strict* mode, not using the surrogateescape error handler.

So we can use support.TESTFN_UNDECODABLE to check if a function uses correctly the surrogateescape error handler and/or check if it behaves correctly with non-ASCII characters.

The patch uses also support.TESTFN_UNDECODABLE (only on UNIX) in test_cmd_line_script.test_non_ascii() to also check that the fix for #16218 works with UTF-8 locale encoding.

Please test the patch on UNIX, Windows and Mac OS X.

We may also use support.TESTFN_UNDECODABLE in test_cmd_line_script.test_non_ascii() on Windows, I will check.

Windows has some strange behaviour with undecodable characters: some of them are replaced a character with a similar glyph.

----------
components: Tests, Unicode
files: support_undecodable.patch
keywords: patch
messages: 175200
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use support.TESTFN_UNDECODABLE on UNIX
versions: Python 3.4
Added file: http://bugs.python.org/file27928/support_undecodable.patch

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

From report at bugs.python.org  Fri Nov  9 00:05:10 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 08 Nov 2012 23:05:10 +0000
Subject: [New-bugs-announce] [issue16445] SEGFAULT when deleting
	Exception.message
Message-ID: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

The script below segfaults cpython2.7. 
The cause is in BaseException_set_message(), which calls Py_XDECREF(self->message) and thus can call back into Python code with a dangling PyObject* pointer. Py_CLEAR should be used instead.


class Nasty(str):
    def __del__(self):
        del e.message

e = ValueError(Nasty("msg"))
e.args = ()
del e.message
del e

----------
messages: 175203
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: SEGFAULT when deleting Exception.message
type: crash

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

From report at bugs.python.org  Fri Nov  9 00:09:53 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 08 Nov 2012 23:09:53 +0000
Subject: [New-bugs-announce] [issue16446] pdb raises BdbQuit on 'quit' when
	started with set_trace
Message-ID: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Also, the two oldest frames of the stack are identical (sic),
according to the printed traceback.

$ python3 foo.py
> /tmp/foo.py(3)<module>()
-> x = 1
(Pdb) import sys; print(sys.version)
3.2.2 (default, Dec 27 2011, 17:35:55) 
[GCC 4.3.2]
(Pdb) list
  1     import pdb
  2     pdb.set_trace()
  3  -> x = 1
  4
[EOF]
(Pdb) quit
Traceback (most recent call last):
  File "foo.py", line 3, in <module>
    x = 1
  File "foo.py", line 3, in <module>
    x = 1
  File "/usr/local/lib/python3.2/bdb.py", line 46, in trace_dispatch
    return self.dispatch_line(frame)
  File "/usr/local/lib/python3.2/bdb.py", line 65, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit
$

----------
components: Library (Lib)
messages: 175205
nosy: xdegaye
priority: normal
severity: normal
status: open
title: pdb raises BdbQuit on 'quit' when started with set_trace
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Nov  9 01:09:20 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Nov 2012 00:09:20 +0000
Subject: [New-bugs-announce] [issue16447] SEGFAULT when setting type.__name__
Message-ID: <1352419760.39.0.728241030951.issue16447@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

Following script crashes all versions of Python.  Cause is the "Py_DECREF(et->ht_name)" in type_set_name().

class Nasty(str):
    def __del__(self):
        C.__name__ = "other"
class C(object):
    pass
C.__name__ = Nasty("abc")
C.__name__ = "normal"

----------
messages: 175210
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: SEGFAULT when setting type.__name__
type: crash

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

From report at bugs.python.org  Sat Nov 10 09:20:23 2012
From: report at bugs.python.org (jf)
Date: Sat, 10 Nov 2012 08:20:23 +0000
Subject: [New-bugs-announce] [issue16448] 'module' object has no attribute
	'font' when "import	tkinter" only.
Message-ID: <1352535623.44.0.876378351655.issue16448@psf.upfronthosting.co.za>


New submission from jf:

when i use tkinter.font, i meet a error "'module' object has no attribute 'font'". if i add "import tkinter.font", it's no error.

but when i use tkinter,messagebox, it's no error without "import tkinter.messagebox".

and, under the tkinter folder, "messagebox.py" and "font.py" have the same hierarchical filesystem.

why they have different import method?

here is my code:
1)tkinter.font -- only use "import tkinter" meet a error, must add "import tkinter.font".code is below:

import tkinter
#import tkinter.font
root = tkinter.Tk()
ft = tkinter.font.Font(family = 'Fixdsys',size = 20,weight = tkinter.font.BOLD)
tkinter.Label(root,text = 'hello sticky',font = ft ).grid()
root.mainloop()

2)tkinter.messagebox -- only use "import tkinter" is all ok.code is below:

import tkinter
def callback():
    if tkinter.messagebox.askokcancel("Quit", "Do you really wish to quit?"):
        root.destroy()
root = tkinter.Tk()
root.protocol("WM_DELETE_WINDOW", callback)
root.mainloop()


i am a beginner on python. if have a reply, please email me. thinks.

----------
components: Tkinter
messages: 175267
nosy: zaazbb
priority: normal
severity: normal
status: open
title: 'module' object has no attribute 'font' when "import tkinter" only.
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov 10 15:36:10 2012
From: report at bugs.python.org (Phil Connell)
Date: Sat, 10 Nov 2012 14:36:10 +0000
Subject: [New-bugs-announce] [issue16449] RotatingFileHandler rollover
	doesn't work on QNX shmem	filesystems
Message-ID: <1352558170.33.0.527628732316.issue16449@psf.upfronthosting.co.za>


New submission from Phil Connell:

logging.handlers.RotatingFileHandler.doRollover fails on QNX /dev/shmem filesystems (seen on a 6.4.0-based system).

QNX RAM filesystems don't support rename() (see http://www.qnx.com/developers/docs/6.4.0/neutrino/sys_arch/fsys.html#DEVSHMEM - it's a 'big filesystem' feature).

So for example, rename("/dev/shmem/foo", "/dev/shmem/bar") fails with EXDEV.


This is easily fixed by using shutils.move rather than os.rename where appropriate, falling back to copying if a rename() fails. It's not sufficient to set the rotator attribute, since there are other os.rename calls in in doRollover.

----------
components: Library (Lib)
files: rfh_rename_fix.patch
keywords: patch
messages: 175277
nosy: pconnell, vinay.sajip
priority: normal
severity: normal
status: open
title: RotatingFileHandler rollover doesn't work on QNX shmem filesystems
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file27941/rfh_rename_fix.patch

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

From report at bugs.python.org  Sat Nov 10 15:42:12 2012
From: report at bugs.python.org (Hans Mulder)
Date: Sat, 10 Nov 2012 14:42:12 +0000
Subject: [New-bugs-announce] [issue16450] test_missing_localfile masks
	problems in urlopen
Message-ID: <1352558532.09.0.890578567494.issue16450@psf.upfronthosting.co.za>


New submission from Hans Mulder:

Due to a misconfiguration, urllib.thishost() raises an IOError
on my laptop.  This causes urllib.urlopen to raise an exception.
A flaw in test_missing_localfile causes this exception to not be
reported.  The problem happens at line 230-235:

        try:
            self.assertTrue(os.path.exists(tmp_file))
            fp = urllib.urlopen(tmp_fileurl)
        finally:
            os.close(fd)
            fp.close()

On my laptop, urllib.urlopen raises a socket.gaierror.  This
means that the variable fp is never set, and the fp.close() at
line 235 raises an UnboundLoccalError, masking the socket error.

A quick fix would be:

        try:
            self.assertTrue(os.path.exists(tmp_file))
            fp = urllib.urlopen(tmp_fileurl)
            fp.close()
        finally:
            os.close(fd)

That way, the .close is only attempted if the open succeeds.

----------
components: Tests
messages: 175278
nosy: HansM
priority: normal
severity: normal
status: open
title: test_missing_localfile masks problems in urlopen
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 10 15:57:31 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Nov 2012 14:57:31 +0000
Subject: [New-bugs-announce] [issue16451] Remove duplication between
	slice_indices and	compute_slice_indices
Message-ID: <1352559451.13.0.963654733597.issue16451@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

(From #14794 ...)

compute_slice_indices in Objects/rangeobject.c and slice_indices in Objects/sliceobject.c implement essentially the same algorithm.  It would be nice to refactor to avoid the repetition.

----------
messages: 175281
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Remove duplication between slice_indices and compute_slice_indices
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 11 10:56:06 2012
From: report at bugs.python.org (Simon Feltman)
Date: Sun, 11 Nov 2012 09:56:06 +0000
Subject: [New-bugs-announce] [issue16452] Add support for weak reference to
	bound methods
Message-ID: <1352627766.58.0.403468077196.issue16452@psf.upfronthosting.co.za>


New submission from Simon Feltman:

This is a feature request to include a "WeakMethod" or similar object to the weakref module. The object decomposes a bound method and holds a weakref to the object and unbound function. This can be a very useful utility in signal and ui based programming.

The issue has come up a few times but I was unable to find a bug specifically requesting this feature. I think similar code has shown up in enough libraries at this point that it makes sense to just include it in pythons weakref module.

See also:
http://bugs.python.org/issue813299
http://bugs.python.org/issue7464

This is the recipes:
http://code.activestate.com/recipes/81253/
http://mindtrove.info/python-weak-references/

----------
components: None
messages: 175337
nosy: sfeltman
priority: normal
severity: normal
status: open
title: Add support for weak reference to bound methods
type: enhancement

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

From report at bugs.python.org  Sun Nov 11 19:07:35 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Nov 2012 18:07:35 +0000
Subject: [New-bugs-announce] [issue16453] Inconsistent dead weakref equality
Message-ID: <1352657255.44.0.0509101223416.issue16453@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Dead weakrefs to a given object happen to be equal if they don't have a callback, but unequal if they do. However, they are always equal when alive:

>>> class O: pass
... 
>>> o = O()
>>> def cb(_): pass
... 
>>> q = weakref.ref(o)
>>> r = weakref.ref(o)
>>> s = weakref.ref(o, cb)
>>> t = weakref.ref(o, cb)
>>> q == r
True
>>> s == t
True
>>> del o
>>> q() is None
True
>>> q == r
True
>>> s == t
False

This may be related to the following optimization (?):

>>> q is r
True
>>> s is t
False

----------
components: Library (Lib)
messages: 175378
nosy: fdrake, pitrou, tim_one
priority: normal
severity: normal
status: open
title: Inconsistent dead weakref equality
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov 11 22:49:34 2012
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 11 Nov 2012 21:49:34 +0000
Subject: [New-bugs-announce] [issue16454] Mostly for discussion: _winapi as
	builtin for	bootstrapping distutils.
Message-ID: <1352670574.14.0.083815608214.issue16454@psf.upfronthosting.co.za>


New submission from Ray Donnelly:

I'm submitting this patch as it was suggested I do so by Antoine Pitrou on #python-dev. As such, it's more a point of discussion than a patch I'm trying to get merged (for one thing, my build is a MinGW GCC compiled and I've not considered the MSVC Windows build).

I ran into a problem with a customisation I made to cygwinccompiler.py where I wanted to use Popen to ask gcc where it's ld is:

out = Popen(gcc+' --print-prog-name ld', shell=True, stdout=PIPE).stdout

This has worked fine before on 2.7.3, but with 3.3.0, subprocess can't be imported as _winapi isn't builtin, instead, it's built by setup.py as a module.

So is this the right thing to do? Or is distutils not supposed to use subprocess during bootstrapping?

----------
files: _winapi_as_builtin_for_distutils_bootstrap.patch
keywords: patch
messages: 175393
nosy: Ray.Donnelly, pitrou, sbt
priority: normal
severity: normal
status: open
title: Mostly for discussion: _winapi as builtin for bootstrapping distutils.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file27962/_winapi_as_builtin_for_distutils_bootstrap.patch

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

From report at bugs.python.org  Sun Nov 11 23:14:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Nov 2012 22:14:15 +0000
Subject: [New-bugs-announce] [issue16455] sys.getfilesystemencoding() is not
	the locale encoding	on FreeBSD and OpenSolaris when the
	locale is not set
Message-ID: <1352672055.11.0.23985291602.issue16455@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On FreeBSD and OpenIndiana, sys.getfilesystemencoding() is 'ascii' when the locale is not set, whereas the locale encoding is ISO-8859-1.

This inconsistency causes different issue. For example, os.fsencode(sys.argv[1]) fails if the argument is not ASCII because sys.argv are decoded from the locale encoding (by _Py_char2wchar()).

sys.getfilesystemencoding() is 'ascii' because nl_langinfo(CODESET) is used to to get the locale encoding and nl_langinfo(CODESET) announces ASCII (or an alias of this encoding).

Python should detect this case and set sys.getfilesystemencoding() to 'iso8859-1' if the locale encoding is 'iso8859-1' whereas nl_langinfo(CODESET) announces ASCII. We can for example decode b'\xe9' with mbstowcs() and check if it fails or if the result is U+00E9.

----------
components: Unicode
messages: 175401
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: sys.getfilesystemencoding() is not the locale encoding on FreeBSD and OpenSolaris when the locale is not set
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 11 23:51:36 2012
From: report at bugs.python.org (Wojtek Szymilowski)
Date: Sun, 11 Nov 2012 22:51:36 +0000
Subject: [New-bugs-announce] [issue16456] UnicodeDecodeError thrown for
	'encode' operation on	string
Message-ID: <1352674296.04.0.101357421426.issue16456@psf.upfronthosting.co.za>


New submission from Wojtek Szymilowski:

UnicodeDecodeError exception is reported for encode operation on strings.
This issue does not surface for the same operation on unicode string (UnicodeEncodeError exception is correctly reported).

---- string:
>>> 'AB\xff'.encode('ascii')

Traceback (most recent call last):
  File "<pyshell#27>", line 1, in <module>
    'AB\xff'.encode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 2: ordinal not in range(128)

---- unicode string:
>>> u'AB\xff'.encode('ascii')

Traceback (most recent call last):
  File "<pyshell#28>", line 1, in <module>
    u'AB\xff'.encode('ascii')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in position 2: ordinal not in range(128)

----------
components: Unicode
messages: 175404
nosy: Wojtek.Szymilowski, ezio.melotti
priority: normal
severity: normal
status: open
title: UnicodeDecodeError thrown for 'encode' operation on string
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 12 01:17:39 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Nov 2012 00:17:39 +0000
Subject: [New-bugs-announce] [issue16457] Allow operator 'getter' methods to
	take a list and	return a tuple
Message-ID: <1352679459.02.0.414122398053.issue16457@psf.upfronthosting.co.za>


New submission from R. David Murray:

Consider this code snippet, simplified from a real application:

def display(self, *columns)
    getter = attrgetter(*columns)
    toprint = [[str(x) for x in getter(row)] for row in self._rows]

This works great...as long as there are two or more columns to print.
If there is only one column, it bombs because the getter returns a value
instead of a tuple.

This would not be a problem in and of itself, but there is no way to
tell attrgetter that I want a tuple even if there is only one value.

I believe it would be backward compatible to allow:

    attrgetter(['a'])
    itemgetter(['a', 'b'])

to return a tuple, since a list cannot be an attribute name.  The same
would apply to itemgetter, since a list cannot be a dictionary key.

----------
components: Library (Lib)
messages: 175412
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow operator 'getter' methods to take a list and return a tuple
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 12 03:49:27 2012
From: report at bugs.python.org (Karthk Rajagopalan)
Date: Mon, 12 Nov 2012 02:49:27 +0000
Subject: [New-bugs-announce] [issue16458] subprocess.py throw "The handle is
	invalid" error on	duplicating the STD_INPUT_HANDLE
Message-ID: <1352688567.58.0.199976634188.issue16458@psf.upfronthosting.co.za>


New submission from Karthk Rajagopalan:

Please download subprocess.zip and extract the archive. Run - 

perl test.pl

you will notice 'invalid handle' error on duplicating STD_INPUT_HANDLE in python. This is observed in Windows XP SP3. Vista SP2 and higher platforms doesn't show this failure when I checked.

"test.pl" spawn a python process "test.py" using CREATE_NEW_PROCESS_GROUP flag. Before it does, it close STDIN and create a listening socket. Perl under the hood, convert the socket handle to file descriptor using open_osfhandle(..) call. When it does this, the C runtime set the standard input handle to this descriptor  for console app. [ See msvcr* osfinfo.c code - SetStdHandle( STD_INPUT_HANDLE, (HANDLE)value )  ]. As a result, when you get the STD_INPUT_HANDLE, you will get the new one. Duplicating this handle, hence throw the invalid handle error in Windows XP SP3. 

When I looked at MSDN for DuplicateHandle(..), it is mentioned not to duplicate socket handle using this call. So I suspect something going wrong in XP platform. To fix this issue, I have come up with a patch - python-2143_patch. Please take a look and let me know your comments.

-Karthik

----------
components: Windows
files: subprocess.zip
messages: 175416
nosy: kartlee05
priority: normal
severity: normal
status: open
title: subprocess.py throw "The handle is invalid" error on duplicating the STD_INPUT_HANDLE
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27966/subprocess.zip

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

From report at bugs.python.org  Mon Nov 12 07:51:28 2012
From: report at bugs.python.org (Firat Ozgul)
Date: Mon, 12 Nov 2012 06:51:28 +0000
Subject: [New-bugs-announce] [issue16459] sys.stdout.write printing length
	of string
Message-ID: <1352703088.16.0.793564052776.issue16459@psf.upfronthosting.co.za>


New submission from Firat Ozgul:

On Python 3.3 under Windows and GNU/Linux, sys.stdout.write prints the length of string along with the string itself:

>>> sys.stdout.write("a_string")

a_string8

Note the '8' at the end of 'a_string'.

Is it expected behavior?

----------
components: None
messages: 175419
nosy: firatozgul
priority: normal
severity: normal
status: open
title: sys.stdout.write printing length of string
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 12 09:25:05 2012
From: report at bugs.python.org (Tom Pohl)
Date: Mon, 12 Nov 2012 08:25:05 +0000
Subject: [New-bugs-announce] [issue16460] Strange results for floor division
	("//") with	non-integer divisors
Message-ID: <1352708705.94.0.0678979335127.issue16460@psf.upfronthosting.co.za>


New submission from Tom Pohl:

According to the documentation of the floor division (http://docs.python.org/2/reference/expressions.html#binary-arithmetic-operations), x//y should be equal to math.floor(x/y).

However, the result of 1//0.1 is 9.0 (tested on 2.6, 2.7, 3.2).

It might be related to the internal representation of floating-point numbers, but for this example I would expect it to come up with the correct values.

Cheers,
Tom

----------
components: None
messages: 175424
nosy: Tom.Pohl
priority: normal
severity: normal
status: open
title: Strange results for floor division ("//") with non-integer divisors
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Nov 12 16:04:11 2012
From: report at bugs.python.org (Christian Kern)
Date: Mon, 12 Nov 2012 15:04:11 +0000
Subject: [New-bugs-announce] [issue16461] wave module: wrong integer format
Message-ID: <1352732651.92.0.893248719316.issue16461@psf.upfronthosting.co.za>


New submission from Christian Kern:

Writing .wav files is limited to a file size of 2 Gib, while
the WAV file format itself supports up to 4 Gib.
Trying to write a file beyond 2 Gib (e.g. 203 minutes at
CD quality (i.e. 44.1 kHz, 2 channels, 16 bit)) will crash
at the moment when self._datawritten exceeds 2^31-1 bytes.
This is due to the fact that, in method "_patchheader",
the variable "self._datawritten" is written with
"struct.pack('<l')" (signed long integer)
instead of
"struct.pack('<L')" (unsigned long integer---which would
conform to the WAV file format spefication).

patch to wave.py:
476c476
<         self._file.write(struct.pack('<l', self._datalength))
---
>         self._file.write(struct.pack('<L', self._datalength))
485c485
<         self._file.write(struct.pack('<l', 36 + self._datawritten))
---
>         self._file.write(struct.pack('<L', 36 + self._datawritten))
487c487
<         self._file.write(struct.pack('<l', self._datawritten))
---
>         self._file.write(struct.pack('<L', self._datawritten))

This patch also patches the "_write_header" method, which
has the same problem (but will lead to a crash only
in very rare cases).

By the way: "_patchheader" should be renamed to "_patch_header"
in order to be in harmony with the other function/method names
of this module.

Attached you'll find a very simple python 2 script which will
reproduce the problem. Usage: mkdummywav.py $duration_in_minutes

Maybe the problem also occurs at python 3, I don't know.

----------
components: Extension Modules
files: mkdummywav.py
messages: 175450
nosy: ckern
priority: normal
severity: normal
status: open
title: wave module: wrong integer format
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file27971/mkdummywav.py

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

From report at bugs.python.org  Mon Nov 12 16:08:11 2012
From: report at bugs.python.org (mike.a)
Date: Mon, 12 Nov 2012 15:08:11 +0000
Subject: [New-bugs-announce] [issue16462] smtpd should return greeting
Message-ID: <1352732891.73.0.549374987784.issue16462@psf.upfronthosting.co.za>


New submission from mike.a:

The greeting value is required by SPF, and should be returned by SMTPChannel. This would involve a simple fix by adding self.__greeting to the list of returned values in the status object

----------
messages: 175451
nosy: mike.a
priority: normal
severity: normal
status: open
title: smtpd should return greeting
type: enhancement
versions: Python 2.6

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

From report at bugs.python.org  Mon Nov 12 22:53:37 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Nov 2012 21:53:37 +0000
Subject: [New-bugs-announce] [issue16463] test_timeout failure on the RHEL
	buildbot
Message-ID: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The RHEL buildbot consistently fails on test_timeout:



======================================================================
FAIL: testConnectTimeout (test.test_timeout.TCPTimeoutTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.coghlan-redhat/build/Lib/test/test_timeout.py", line 222, in testConnectTimeout
    self._sock_operation(1, 0.001, 'connect', self.addr_remote)
  File "/home/buildbot/buildarea/3.x.coghlan-redhat/build/Lib/test/test_timeout.py", line 126, in _sock_operation
    self.assertLess(delta, timeout + self.fuzz)
AssertionError: 5.0571630001068115 not less than 2.001


According to the build history, the failure appeared in http://buildbot.python.org/all/builders/x86%20RHEL%206%203.3/builds/133 , but the changes look unlikely to be related. Did the setup change?

----------
assignee: ncoghlan
components: Tests
keywords: buildbot
messages: 175476
nosy: ncoghlan, pitrou
priority: high
severity: normal
status: open
title: test_timeout failure on the RHEL buildbot
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov 13 02:57:33 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Nov 2012 01:57:33 +0000
Subject: [New-bugs-announce] [issue16464] urllib.request: opener not
	resetting content-length
Message-ID: <1352771853.32.0.535718799021.issue16464@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Code based on python-list post by a do-not-wish-to-register urllib user.

import urllib.request
opener = urllib.request.build_opener()
request = urllib.request.Request("http://example.com/", headers =
        {"Content-Type": "application/x-www-form-urlencoded"})
print(request.data, '\n', request.header_items())

opener.open(request, "1".encode("us-ascii"))
print(request.data, '\n', request.header_items())

opener.open(request, "123456789".encode("us-ascii"))
print(request.data, '\n', request.header_items())
>>> 
None 
 [('Content-type', 'application/x-www-form-urlencoded')]
b'1' 
 [('Content-length', '1'), ('Host', 'example.com'), ('User-agent', 'Python-urllib/3.3'), ('Content-type', 'application/x-www-form-urlencoded')]
b'123456789' 
 [('Content-length', '1'), ('Host', 'example.com'), ('User-agent', 'Python-urllib/3.3'), ('Content-type', 'application/x-www-form-urlencoded')]

The first opener.open adds data and several headers to request, including content-length. The second changes the data but not the content-length. The docs do not say anything about this either way.

----------
messages: 175485
nosy: orsenthil, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request: opener not resetting content-length
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov 13 17:19:04 2012
From: report at bugs.python.org (Philipp Hagemeister)
Date: Tue, 13 Nov 2012 16:19:04 +0000
Subject: [New-bugs-announce] [issue16465] dict creation performance
	regression
Message-ID: <1352823544.31.0.485629860142.issue16465@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister:

On my system, {}  has become significantly slower in 3.3:

$ python3.2 -m timeit -n 1000000 '{}'
1000000 loops, best of 3: 0.0314 usec per loop
$ python3.3 -m timeit -n 1000000 '{}'
1000000 loops, best of 3: 0.0892 usec per loop
$ hg id -i
ee7b713fec71+
$ ./python -m timeit -n 1000000 '{}'
1000000 loops, best of 3: 0.0976 usec per loop

Is this because of the dict randomization?

----------
components: Interpreter Core
messages: 175503
nosy: phihag
priority: normal
severity: normal
status: open
title: dict creation performance regression
type: performance
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov 13 19:02:39 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 13 Nov 2012 18:02:39 +0000
Subject: [New-bugs-announce] [issue16466] register command forgets password
	if no config file is	created
Message-ID: <1352829759.7.0.8937255807.issue16466@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Given:

1. there is no .pypirc
2. users enters credentials to register command
3. user refuses to create .pypirc

Outcome:

password is not being stored and subsequent (upload) command doesn't get it.

Attached is the test case.

----------
assignee: eric.araujo
components: Distutils
files: test_register.py.2.diff
keywords: patch
messages: 175512
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: register command forgets password if no config file is created
versions: Python 2.7
Added file: http://bugs.python.org/file27979/test_register.py.2.diff

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

From report at bugs.python.org  Tue Nov 13 19:33:14 2012
From: report at bugs.python.org (Anthony Tuininga)
Date: Tue, 13 Nov 2012 18:33:14 +0000
Subject: [New-bugs-announce] [issue16467] frozen importlib required for
	extending Python	interpreter not public
Message-ID: <1352831594.42.0.797931332936.issue16467@psf.upfronthosting.co.za>


New submission from Anthony Tuininga:

With Python 3.3, the ability to create a Python interpreter independent of a Python installation (as is done with cx_Freeze and other such freezing tools) has become more difficult to accomplish. Py_Initialize() requires the presence of a frozen importlib module which is found in importlib.h, but that include file is not available in the public include files section of a Python distribution. I have copied it for my use but that seems wrong. Please advise on how this should take place now. Thanks.

----------
components: None
messages: 175515
nosy: atuining
priority: normal
severity: normal
status: open
title: frozen importlib required for extending Python interpreter not public
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 14 05:32:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Nov 2012 04:32:19 +0000
Subject: [New-bugs-announce] [issue16468] argparse only supports iterable
	choices
Message-ID: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to ensure that argparse.ArgumentParser() accepts objects that support the "in" operator for the "choices" argument to ArgumentParser.add_argument().

As observed by Terry in the comments to issue 16418:

http://bugs.python.org/issue16418#msg175520

the argparse module does not in general support "choices" values that support the "in" operator, even though the argparse documentation says it does:

"Any object that supports the in operator can be passed as the choices value, so dict objects, set objects, custom containers, etc. are all supported."

(from http://docs.python.org/2/library/argparse.html#choices )

For example, passing a user-defined type that implements only self.__contains__() yields the following error message when calling ArgumentParser.parse_args():

File ".../Lib/argparse.py", line 1293, in add_argument
  raise ValueError("length of metavar tuple does not match nargs")

(The error message also gives the wrong reason for failure.  The swallowed exception is "TypeError: '<class>' object is not iterable.")

----------
components: Library (Lib)
messages: 175534
nosy: chris.jerdonek, terry.reedy
priority: normal
severity: normal
status: open
title: argparse only supports iterable choices
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 14 07:30:20 2012
From: report at bugs.python.org (Case Van Horsen)
Date: Wed, 14 Nov 2012 06:30:20 +0000
Subject: [New-bugs-announce] [issue16469] Exceptions raised by Fraction()
	from those raised by	int()
Message-ID: <1352874620.08.0.771603502235.issue16469@psf.upfronthosting.co.za>


New submission from Case Van Horsen:

When attempting to convert a float("nan"), float("inf"), or float("-inf"), fractions.Fraction() raises different exceptions than int()

>>> int(float("nan"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot convert float NaN to integer
>>> fractions.Fraction(float("nan"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python3.2/fractions.py", line 114, in __new__
    value = Fraction.from_float(numerator)
  File "/opt/local/lib/python3.2/fractions.py", line 186, in from_float
    raise TypeError("Cannot convert %r to %s." % (f, cls.__name__))
TypeError: Cannot convert nan to Fraction.
>>> int(float("inf"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: cannot convert float infinity to integer
>>> fractions.Fraction(float("inf"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python3.2/fractions.py", line 114, in __new__
    value = Fraction.from_float(numerator)
  File "/opt/local/lib/python3.2/fractions.py", line 186, in from_float
    raise TypeError("Cannot convert %r to %s." % (f, cls.__name__))
TypeError: Cannot convert inf to Fraction.
>>> int(float("-inf"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: cannot convert float infinity to integer
>>> fractions.Fraction(float("-inf"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python3.2/fractions.py", line 114, in __new__
    value = Fraction.from_float(numerator)
  File "/opt/local/lib/python3.2/fractions.py", line 186, in from_float
    raise TypeError("Cannot convert %r to %s." % (f, cls.__name__))
TypeError: Cannot convert -inf to Fraction.

Should the exceptions be changed to ValueError and OverflowError?

----------
components: Library (Lib)
messages: 175536
nosy: casevh
priority: normal
severity: normal
status: open
title: Exceptions raised by Fraction() from those raised by int()
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 14 08:43:37 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Wed, 14 Nov 2012 07:43:37 +0000
Subject: [New-bugs-announce] [issue16470] Backport set and dictionary
	comprehensions in tutorial	to 2.7
Message-ID: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

Dictionary and set comprehensions are backported to 2.7 in issue #2333. The are not documented in the tutorial of 2.7, though they are in the language reference. Is it OK to add these to the tutorial? I've uploaded a patch.

----------
assignee: docs at python
components: Documentation
files: set_and_dict_comprehensions.diff
keywords: patch
messages: 175547
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Backport set and dictionary comprehensions in tutorial to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file27982/set_and_dict_comprehensions.diff

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

From report at bugs.python.org  Wed Nov 14 11:27:50 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Nov 2012 10:27:50 +0000
Subject: [New-bugs-announce] [issue16471] upgrade to sphinx 1.1
Message-ID: <1352888870.05.0.523269386726.issue16471@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to upgrade Python's Sphinx from version 1.0 to 1.1.

I don't already see an issue for this, and I'm not sure what upgrading entails.

Personally, I'm interested in the enhanced indexing capabilities, e.g. the "see" and "seealso" entry types, as well as marking main index entries:

http://sphinx-doc.org/markup/misc.html#directive-index

I'm sure other reasons for upgrading have been floated, though I don't know what they are.

----------
assignee: docs at python
components: Documentation
messages: 175560
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
status: open
title: upgrade to sphinx 1.1
type: enhancement

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

From report at bugs.python.org  Wed Nov 14 14:34:01 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Wed, 14 Nov 2012 13:34:01 +0000
Subject: [New-bugs-announce] [issue16472] Distutils+mingw links agains
	msvcr90, while python27.dll is linked agains msvcrt
Message-ID: <1352900041.91.0.554679168644.issue16472@psf.upfronthosting.co.za>


New submission from V?clav ?milauer:

Compiling an extension with --compiler=mingw32 with official python 2.7.3 distribution on Windows (64bit) leads to unusable result - crash on module load ("invalid access to memory").

The reasons is that Lib/distutils/cygwincompiler.py#l62 links the resulting .pyd file against msvcr90.dll (version is determined by version of MSVC used to build python itself), while python27.dll is linked against msvcrt.dll (shows the Dependency Walker). 

Based on my own experience (above) and MSDN docs http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx,  http://msdn.microsoft.com/en-us/library/ms235460.aspx), loading 2 different runtimes is asking for trouble.

I raised this topic on distutils-sig, hoping for an explanation. Judging by the reaction, it is quite possibly historical relict which is no longer needed. This is also hinted at by comments at the beginning of Lib/distutils/cygwincompiler.py

   "if you use a msvc compiled python version (1.5.2)"
   "mingw gcc 3.2/ld 2.13 works"

I am aware of distutils being frozen for new features (unless you want to call bugfix a new feature).

----------
assignee: eric.araujo
components: Distutils
messages: 175569
nosy: eric.araujo, eudoxos, tarek
priority: normal
severity: normal
status: open
title: Distutils+mingw links agains msvcr90, while python27.dll is linked agains msvcrt
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 14 22:22:06 2012
From: report at bugs.python.org (=?utf-8?q?Alejandro_Javier_Peralta_Fr=C3=ADas?=)
Date: Wed, 14 Nov 2012 21:22:06 +0000
Subject: [New-bugs-announce] [issue16473] Minor difference in decoding
	quoted-printable text
Message-ID: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za>


New submission from Alejandro Javier Peralta Fr?as:

New to python-dev; I grab a beginner tasks "increase test coverage" and I decided to add coverage to this bit of code in the quopri module:

# quopri.py
L138            while n > 0 and line[n-1:n] in b" \t\r": 
L139                n = n-1

As far as I understand to get into that while-loop the line to decode should end in " \t\r\n".

So the I added the following test:

    def test_decodestring_badly_enconded(self):
        e = b"hello     \t\r\n"
        p = b"hello\n"
        s = self.module.decodestring(e)
        self.assertEqual(s, p)

but that only passes when the module doesn't use binascii. In fact I change test_quopri to use support.import_fresh_module to disable binascii and removed a decorator that was used.

The decode text when binascci is used is:

>>> quopri.decodestring("hello \t\r\n")
'hello \t\r\n'

which differs from

>>> quopri.a2b_qp = None
>>> quopri.b2a_qp = None
>>> quopri.decodestring("hello \t\r\n")
'hello\n

And what's the deal with:

>>> import quopri
>>> quopri.encodestring("hello \t\r")
'hello \t\r'
>>> "hello \t\r".encode("quopri")
'hello=20=09\r'

----------
components: Tests
files: test_quopri.diff
keywords: patch
messages: 175593
nosy: aleperalta
priority: normal
severity: normal
status: open
title: Minor difference in decoding quoted-printable text
versions: Python 3.3
Added file: http://bugs.python.org/file27985/test_quopri.diff

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

From report at bugs.python.org  Thu Nov 15 01:14:30 2012
From: report at bugs.python.org (alejandro david weil)
Date: Thu, 15 Nov 2012 00:14:30 +0000
Subject: [New-bugs-announce] [issue16474] More code coverage for imp module
Message-ID: <1352938470.43.0.179582544246.issue16474@psf.upfronthosting.co.za>


New submission from alejandro david weil:

Add some 5% more code-coverage for imp module in tests.

----------
components: Tests
files: imp_test_patch.diff
keywords: patch
messages: 175597
nosy: brett.cannon, tenuki
priority: normal
severity: normal
status: open
title: More code coverage for imp module
versions: Python 3.3
Added file: http://bugs.python.org/file27986/imp_test_patch.diff

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

From report at bugs.python.org  Thu Nov 15 09:54:38 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Nov 2012 08:54:38 +0000
Subject: [New-bugs-announce] [issue16475] Support object instancing and
	recursion in marshal
Message-ID: <1352969678.69.0.685980330217.issue16475@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

The format used by the marshal module does not support instancing.  This precludes certain data optimizations, such as sharing string constants, common tuples, even common code objects.  Since the marshal format is used to write compiled code, this makes it impossible to do data optimization on code prior to writing it out.

This patch adds proper instancing support for all the supported types and increases the default version to three.

(A separate defect/regression is that interned strings are no longer preserved as was implemented in version 1 of the original 2.x branch.  This also negates any interning done at compile time.  That is a separate defect.)

----------
components: Interpreter Core
files: marshalinstance.patch
keywords: patch
messages: 175603
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Support object instancing and recursion in marshal
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27987/marshalinstance.patch

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

From report at bugs.python.org  Thu Nov 15 12:15:36 2012
From: report at bugs.python.org (Leo Liu)
Date: Thu, 15 Nov 2012 11:15:36 +0000
Subject: [New-bugs-announce] [issue16476] Trailing spaces in pretty-printed
	JSON
Message-ID: <1352978136.54.0.595211017134.issue16476@psf.upfronthosting.co.za>


New submission from Leo Liu:

python -mjson.tool some_file.json > x.json

x.json will have trailing white spaces.

Also reported here: http://thread.gmane.org/gmane.comp.python.devel/135311

----------
messages: 175607
nosy: leoliu
priority: normal
severity: normal
status: open
title: Trailing spaces in pretty-printed JSON
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 15 13:49:47 2012
From: report at bugs.python.org (Sam Thursfield)
Date: Thu, 15 Nov 2012 12:49:47 +0000
Subject: [New-bugs-announce] [issue16477] tarfile fails to close file
	handles in case of exception
Message-ID: <1352983787.27.0.404679122442.issue16477@psf.upfronthosting.co.za>


New submission from Sam Thursfield:

Exceptions such as disk full during extraction cause tarfile to leak file handles. Besides being messy, it causes real problems if, for example, the target file is on a mount that should be unmounted before the program exits - in this case, the unmount will fail as there are still open file handles.

Simplest solution I can see is to change:

    def makefile(self, tarinfo, targetpath):
        """Make a file called targetpath.
        """
        source = self.extractfile(tarinfo)
        target = bltn_open(targetpath, "wb")
        copyfileobj(source, target)
        source.close()
        target.close()

to this:

    def makefile(self, tarinfo, targetpath):
        """Make a file called targetpath.
        """
        source = self.extractfile(tarinfo)
        try:
            with open(targetpath, "wb") as target:
                shutil.copyfileobj(source, target)
        finally:
            source.close()

----------
components: Library (Lib)
messages: 175616
nosy: ssam
priority: normal
severity: normal
status: open
title: tarfile fails to close file handles in case of exception
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 15 16:46:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Nov 2012 15:46:58 +0000
Subject: [New-bugs-announce] [issue16478] Fix division in tabnanny
Message-ID: <1352994418.48.0.449467913759.issue16478@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tabnanny should use floor division in calculation, the comment says about this. But in the current Python 3 code "/" was not changed to "//".

----------
components: Demos and Tools, Library (Lib)
files: tabnanny_div.patch
keywords: easy, patch
messages: 175622
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix division in tabnanny
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27989/tabnanny_div.patch

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

From report at bugs.python.org  Thu Nov 15 17:29:20 2012
From: report at bugs.python.org (Stephen)
Date: Thu, 15 Nov 2012 16:29:20 +0000
Subject: [New-bugs-announce] [issue16479] Can't install Python 3 on Redhat
	Linux, make failed
Message-ID: <1352996960.31.0.378819423594.issue16479@psf.upfronthosting.co.za>


New submission from Stephen:

Machine is Redhat Linux 6.2. Tried to install Python3.3 build failed in the make step.

-----------------------
[sliu at wtl-build-1 Python-3.3.0]$ uname -a    
Linux wtl-build-1 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[sliu at wtl-build-1 Python-3.3.0]$ pwd
/tmp/Python-3.3.0
[snip]
config.status: pyconfig.h is unchanged
creating Modules/Setup
creating Modules/Setup.local
creating Makefile
[sliu at wtl-build-1 Python-3.3.0]$ make 
Wrapping make for user sliu on hostname wtl-build-1...
gcc: Parser/acceler.o: No such file or directory
gcc: Parser/grammar1.o: No such file or directory
gcc: Parser/listnode.o: No such file or directory
gcc: Parser/node.o: No such file or directory
gcc: Parser/parser.o: No such file or directory
gcc: Parser/bitset.o: No such file or directory
gcc: Parser/metagrammar.o: No such file or directory
gcc: Parser/firstsets.o: No such file or directory
gcc: Parser/grammar.o: No such file or directory
gcc: Parser/pgen.o: No such file or directory
gcc: Objects/obmalloc.o: No such file or directory
gcc: Python/dynamic_annotations.o: No such file or directory
gcc: Python/mysnprintf.o: No such file or directory
gcc: Python/pyctype.o: No such file or directory
gcc: Parser/tokenizer_pgen.o: No such file or directory
gcc: Parser/printgrammar.o: No such file or directory
gcc: Parser/parsetok_pgen.o: No such file or directory
gcc: Parser/pgenmain.o: No such file or directory
make[1]: *** [Parser/pgen] Error 1
make: *** [Include/graminit.h] Error 2
Build with args "" took 0 seconds, status complete
[sliu at wtl-build-1 Python-3.3.0]$ 

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

Tried different Linux machines, same error. Tried Python 3.3, 3.1 and 3.0, same error.

Any idea?
Stephen

----------
components: Installation
messages: 175623
nosy: stephenlqn at gmail.com
priority: normal
severity: normal
status: open
title: Can't install Python 3 on Redhat Linux, make failed
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov 15 17:55:28 2012
From: report at bugs.python.org (Marco Amadori)
Date: Thu, 15 Nov 2012 16:55:28 +0000
Subject: [New-bugs-announce] [issue16480] pyvenv 3.3 fails to create
	symlinks for	<virtualenv>/local/{bin,
	lib} to <virtualenv>/{bin, lib}
Message-ID: <1352998528.6.0.478630003119.issue16480@psf.upfronthosting.co.za>


New submission from Marco Amadori:

The solution to work around the bug is there:

http://ipoveraviancarriers.blogspot.it/2012/11/python-33-and-pyvenv-hackish-solution.html

But probably pyvenv should be patched in order to create symlinks.

Thanks!

----------
components: None
messages: 175626
nosy: Marco.Amadori
priority: normal
severity: normal
status: open
title: pyvenv 3.3 fails to create symlinks for <virtualenv>/local/{bin,lib} to <virtualenv>/{bin,lib}
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov 15 18:44:09 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 15 Nov 2012 17:44:09 +0000
Subject: [New-bugs-announce] [issue16481] process handle leak on windows in
	multiprocessing
Message-ID: <1353001449.15.0.429236544802.issue16481@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

On Windows the handle for a child process is not closed when the popen/process object is garbage collected.

----------
messages: 175629
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: process handle leak on windows in multiprocessing
type: resource usage
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 15 18:55:25 2012
From: report at bugs.python.org (A Kaptur)
Date: Thu, 15 Nov 2012 17:55:25 +0000
Subject: [New-bugs-announce] [issue16482] pdb.set_trace() clobbering
	traceback on error
Message-ID: <1353002125.56.0.265106335805.issue16482@psf.upfronthosting.co.za>


New submission from A Kaptur:

pdb.set_trace() is overwriting the actual traceback when exiting with an error.  See minimal recreation here: https://gist.github.com/4079971

----------
messages: 175630
nosy: akaptur
priority: normal
severity: normal
status: open
title: pdb.set_trace() clobbering traceback on error
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov 15 22:17:12 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Nov 2012 21:17:12 +0000
Subject: [New-bugs-announce] [issue16483] Make int(float('inf')) raise
	ValueError rather than	OverflowError.
Message-ID: <1353014232.58.0.902552345028.issue16483@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

[Broken out of the issue 16469 discussion about infinity -> Fraction and nan -> Fraction conversions.]

Conversions from float('inf') or Decimal('inf') to int (or Fraction) currently generate an OverflowError, while conversions from nan give a ValueError.  I'm of the opinion that it would make more sense for both conversions to generate ValueError, and I'm opening this issue to track discussion for that.  There's also a reasonable case that the behaviour is fine as it is, and there's little to be gained by changing it.

----------
messages: 175642
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Make int(float('inf')) raise ValueError rather than OverflowError.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 16 11:46:29 2012
From: report at bugs.python.org (Marius Gedminas)
Date: Fri, 16 Nov 2012 10:46:29 +0000
Subject: [New-bugs-announce] [issue16484] Missing/broken documentation
	redirect for	http://docs.python.org/library/xml.etree.ElementTree
Message-ID: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

Do this:

  pydoc2.7 xml.etree.ElementTree

then click on the MODULE DOCS link, which is http://docs.python.org/library/xml.etree.ElementTree

You're redirected to http://docs.python.org/2/library/xml.etree.ElementTree which is a 404 page.

----------
assignee: docs at python
components: Documentation
messages: 175675
nosy: docs at python, mgedmin
priority: normal
severity: normal
status: open
title: Missing/broken documentation redirect for http://docs.python.org/library/xml.etree.ElementTree
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 16 13:49:33 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Nov 2012 12:49:33 +0000
Subject: [New-bugs-announce] [issue16485] FD leaks in aifc module
Message-ID: <1353070173.54.0.899587497228.issue16485@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Aifc_write.close() can raise exception and left the internal file object not closed.  The patch closes the file object even in case of error and reset _file to None even in case of the file object close() raises an exception, so that Aifc_write.close() can be called repeatedly.

----------
components: Library (Lib)
files: aifc_close.patch
keywords: patch
messages: 175683
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: FD leaks in aifc module
type: resource usage
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27996/aifc_close.patch

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

From report at bugs.python.org  Fri Nov 16 14:39:23 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Nov 2012 13:39:23 +0000
Subject: [New-bugs-announce] [issue16486] Add context manager support to
	aifc module
Message-ID: <1353073163.72.0.969679362142.issue16486@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds context manager support aifc module.  Now objects returned by aifc.open() will support context manager protocol.

This issue required first fixing issue16485 to pass tests.

----------
components: Library (Lib)
files: aifc_context_manager.patch
keywords: patch
messages: 175687
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add context manager support to aifc module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28001/aifc_context_manager.patch

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

From report at bugs.python.org  Fri Nov 16 16:10:15 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 16 Nov 2012 15:10:15 +0000
Subject: [New-bugs-announce] [issue16487] Allow ssl certificates to be
	speficfied from memory	rather than files.
Message-ID: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

The _ssl module (and indeed the openssl lib) relies heaviliy on actual filesystem locations to load certificates.  A client or a server may not want to rely on physical filesystem locations to load certificates for authentication or verification.  Physical disc files are cumbersome and present a management burden in the presence of multiple processes.

This patch adds extensions to the _ssl.c file which allows certificates, keys and certification chains to be provided by file contents, rather than file name.  

The ctx.load_cert_chain and ctx.load_verify_locations take additional arguments to specify the data on this form.

the ssl.wrap_socket does not add arguments, rather the function is polymorphic in that the conents of the certfil/keyfile are examined and treated as file-data if beginning with -----BEGIN.  the ca_certs is similarly treated as a list of file contents, if it is a list, (rather than a string)

This patch is the result of work at CCP for deploying ssl clients and servers in an isolated environment without having to resort to temporary disk files.

----------
components: Extension Modules
files: sslpatch1.patch
keywords: patch
messages: 175691
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Allow ssl certificates to be speficfied from memory rather than files.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28002/sslpatch1.patch

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

From report at bugs.python.org  Fri Nov 16 16:14:09 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Nov 2012 15:14:09 +0000
Subject: [New-bugs-announce] [issue16488] Add context manager support to
	epoll object
Message-ID: <1353078849.09.0.752588026545.issue16488@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds support of context manager protocol to epoll objects.

----------
components: Extension Modules
files: select_epoll_context_manager.patch
keywords: patch
messages: 175693
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add context manager support to epoll object
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28003/select_epoll_context_manager.patch

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

From report at bugs.python.org  Fri Nov 16 18:32:11 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 16 Nov 2012 17:32:11 +0000
Subject: [New-bugs-announce] [issue16489] importlib find_loader returns a
	loader for a non	existent module
Message-ID: <1353087131.58.0.826431992367.issue16489@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Create the following tree:

    foo.py
    mypackage
        __init__.py

and get a loader for the non existent module 'mypackage.foo'.

$ mkdir tmp
$ cd tmp
$ >foo.py
$ mkdir mypackage
$ >mypackage/__init__.py
$ ./python
Python 3.4.0a0 (default:53a7c2226a2b, Nov  9 2012, 16:47:41) 
[GCC 4.3.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib
>>> importlib.find_loader('mypackage').get_filename()
'./mypackage/__init__.py'
>>> importlib.find_loader('mypackage.foo').get_filename()
'./foo.py'
>>>


find_loader should return None in this case.

----------
components: Library (Lib)
messages: 175697
nosy: xdegaye
priority: normal
severity: normal
status: open
title: importlib find_loader returns a loader for a non existent module
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 17 04:36:29 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 17 Nov 2012 03:36:29 +0000
Subject: [New-bugs-announce] [issue16490] "inspect.getargspec()" and
	"inspect.getcallargs()" don't	work with builtins
Message-ID: <1353123389.46.0.245856363901.issue16490@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Yesterday I was attending a conference about a MOCK like library and the speaker told us about some "inspect" functionalities not working correctly with builtins. For instance:

"""
Python 3.3.0 (default, Oct  2 2012, 02:07:16) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> def f(a=None) :
...   pass
... 
>>> inspect.getcallargs(f)
{'a': None}
>>> inspect.getargspec(f)
ArgSpec(args=['a'], varargs=None, keywords=None, defaults=(None,))
>>> inspect.getcallargs(list)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/inspect.py", line 993, in getcallargs
    spec = getfullargspec(func)
  File "/usr/local/lib/python3.3/inspect.py", line 850, in getfullargspec
    raise TypeError('{!r} is not a Python function'.format(func))
TypeError: <class 'list'> is not a Python function
>>> inspect.getargspec(list)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/inspect.py", line 823, in getargspec
    getfullargspec(func)
  File "/usr/local/lib/python3.3/inspect.py", line 850, in getfullargspec
    raise TypeError('{!r} is not a Python function'.format(func))
TypeError: <class 'list'> is not a Python function
>>> 
"""

Can we annotate builtins to support this?. What about types defined in CModules?

----------
messages: 175725
nosy: jcea
priority: normal
severity: normal
status: open
title: "inspect.getargspec()" and "inspect.getcallargs()" don't work with builtins
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 17 09:32:23 2012
From: report at bugs.python.org (Hans Larsen)
Date: Sat, 17 Nov 2012 08:32:23 +0000
Subject: [New-bugs-announce] [issue16491] try-except-raise-bug
Message-ID: <9C3C06E7F0934B209166A3DC454F8D19@HansPc>


New submission from Hans Larsen:

Med venlig hilsen:
Hans Larsen
Galgebakken S?nder 4-11A
DK-2620 Albertslund
Danmark/Danio
I has found a bug in Python3.3 on Windows!
Why are all 3 try-statements equal?
I don?t see a ?..During handling of above exception, another exception occured: ...?
Where is the bug!
I use Windows 7 64bit!

----------
files: Hans.vcf, try-execpt-raise-bug.rtf
messages: 175728
nosy: Jocjo
priority: normal
severity: normal
status: open
title: try-except-raise-bug
Added file: http://bugs.python.org/file28007/Hans.vcf
Added file: http://bugs.python.org/file28008/try-execpt-raise-bug.rtf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16491>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hans.vcf
Type: text/x-vcard
Size: 71 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20121117/7da1f8e2/attachment-0001.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: try-execpt-raise-bug.rtf
Type: application/rtf
Size: 1131 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20121117/7da1f8e2/attachment-0001.rtf>

From report at bugs.python.org  Sat Nov 17 15:38:51 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Nov 2012 14:38:51 +0000
Subject: [New-bugs-announce] [issue16492] Add a load_parents argument to
	importlib.find_loader()
Message-ID: <1353163131.46.0.896555939151.issue16492@psf.upfronthosting.co.za>


New submission from Brett Cannon:

To make using importlib.find_loader() easier, there should be a flag that says to automatically import all parent packages for the desired submodule so as to not force the user to do it::

  def find_loader(name, path=None, *, load_parents=False): ...

That way people who are okay with loading some packages implicitly to get at a specific loader can do so without having to do boilerplate name.split('.'); import each parent code. Also means people don't have to worry about the path argument (unless they explicitly want to trigger loading from a different location).

----------
components: Library (Lib)
messages: 175742
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Add a load_parents argument to importlib.find_loader()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 17 16:52:47 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Nov 2012 15:52:47 +0000
Subject: [New-bugs-announce] [issue16493] Document the 'optimize' argument
	to compile()
Message-ID: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Looks like Georg added the flag in 2010 after Python 2.7 was already out, so this doesn't need to be backported.

The possible values are:

-1 : optimization level the interpreter is already executing with
0 : no optimization
1 : -O
2 : -OO

----------
assignee: docs at python
components: Documentation
messages: 175757
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document the 'optimize' argument to compile()
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 17 17:00:17 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Nov 2012 16:00:17 +0000
Subject: [New-bugs-announce] [issue16494] Method on importlib.SourceLoader
	for creating bytecode	file format/container
Message-ID: <1353168017.12.0.0693705888433.issue16494@psf.upfronthosting.co.za>


New submission from Brett Cannon:

With issue #15031 providing a way to take a bytecode file and get a code object out of it, there should probably be a comparable method that takes a code object and a path stats dict and returns the bytes to write out to a file.

This could also be a slight performance win for subclasses of SourceLoader which can read bytecode files but not write them (e.g. zip files where the cost of modifying a zip file is too high). That way the method could raise NotImplementedError (or return None) to signify it doesn't want anything written out by SourceLoader.get_code() and thus skip the entire step of preparing the bytecode file bytes instead of what happens now where set_data() raises NotImplementedError after the whole set of bytes is constructed.

More importantly, it would clean up py_compile once issue #15627 is in with an 'optimize' flag as py_compile.compile() would essentially become ``source = loader.get_source(...); code = loader.compile_source(source, optimize=...); pyc_bytes = loader.create_bytecode_file(code, loader.path_stats(...))``. Otherwise get_code() will need to grow an 'optimize' flag and that doesn't seem necessary.

----------
components: Library (Lib)
messages: 175762
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Method on importlib.SourceLoader for creating bytecode file format/container
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 17 22:29:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 17 Nov 2012 21:29:49 +0000
Subject: [New-bugs-announce] [issue16495] bytes_decode() unnecessarily
	examines encoding
Message-ID: <1353187789.37.0.881944433109.issue16495@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The code below in bytes_decode() is unnecessary:

    if (encoding == NULL)
        encoding = PyUnicode_GetDefaultEncoding();

(from http://hg.python.org/cpython/file/e9af9b1ca67e/Objects/bytesobject.c#l2230 )

because PyUnicode_FromEncodedObject() already handles the case of NULL encoding (inside normalize_encoding() called by PyUnicode_Decode()):

http://hg.python.org/cpython/file/e9af9b1ca67e/Objects/unicodeobject.c#l2811

----------
components: Interpreter Core
keywords: easy
messages: 175811
nosy: chris.jerdonek, haypo
priority: normal
severity: normal
status: open
title: bytes_decode() unnecessarily examines encoding
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 17 22:32:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Nov 2012 21:32:44 +0000
Subject: [New-bugs-announce] [issue16496] Simplify and optimize random_seed()
Message-ID: <1353187964.7.0.945658199305.issue16496@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Now random_seed() use an ineffective quadratic-time algorithm.  It can reuse _PyLong_AsByteArray(), decreasing code size and increasing performance.

----------
components: Extension Modules
files: random_seed.patch
keywords: patch
messages: 175812
nosy: mark.dickinson, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify and optimize random_seed()
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file28014/random_seed.patch

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

From report at bugs.python.org  Sun Nov 18 00:39:59 2012
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Nov 2012 23:39:59 +0000
Subject: [New-bugs-announce] [issue16497]
	zipimport.zipimporter.find_module() does not work with	dotted
	module names
Message-ID: <1353195599.47.0.873270280839.issue16497@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I am trying to write a test for issue 8585. The `zipimport.zipimporter.find_module()`
docs says:

"Search for a module specified by fullname. fullname must be the fully qualified
(dotted) module name."

(from http://docs.python.org/3.4/library/zipimport.html#zipimport.zipimporter.find_module )

However, the `zipimport.zipimporter.find_module()` method does not work as
expected. See the output of reproducer.py:

    spam <zipimporter object "zipimport_example.zip">
    package.eggs None

----------
components: Library (Lib)
files: reproducer.py
messages: 175830
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: zipimport.zipimporter.find_module() does not work with dotted module names
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28016/reproducer.py

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

From report at bugs.python.org  Sun Nov 18 14:38:57 2012
From: report at bugs.python.org (Terry Cooper)
Date: Sun, 18 Nov 2012 13:38:57 +0000
Subject: [New-bugs-announce] [issue16498] Unwanted link between volatile and
	shelve storage
Message-ID: <1353245937.97.0.646518309195.issue16498@psf.upfronthosting.co.za>


New submission from Terry Cooper:

The Python statement gList1[i1][1] += gList2[i2][1] modifies not only gList1 (a volatile storage object) but dBasis[163] (a record within shelve object dBasis).  Both gList and dBasis[163] are printed before and after execution of the statement by cFract2.combine.  They are obviously not the same record, but the statement modifies gList1[2][1] and dBasis[163][2][1] simultaniously.

----------
components: Windows
files: bugMail.py
messages: 175871
nosy: ttcooper
priority: normal
severity: normal
status: open
title: Unwanted link between volatile and shelve storage
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28023/bugMail.py

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

From report at bugs.python.org  Sun Nov 18 15:26:11 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Nov 2012 14:26:11 +0000
Subject: [New-bugs-announce] [issue16499] CLI option for isolated mode
Message-ID: <1353248771.63.0.703024605939.issue16499@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I like to propose a new option for the Python interpreter:

  python -I

It shall start the interpreter in isolated mode which ignores any
environment variables set by the user and any files installed by the
user. The mode segregate a Python program from anything an unpriviliged
user is able to modify and uses only files that are installed by a
system adminstrator.

The isolated mode implies -E (ignore all PYTHON* environment vars) and
-s (don't add user site directory). It also refrains from the inclusion
of '' or getcwd() to sys.path. TKinter doesn't load and execute Python
scripts from the user's home directory. Other parts of the stdlib should
be checked, too.

The option is intended for OS and application scripts that doesn't want
to become affected by user installed files or files in the current
working path of a user.

The idea is motivated by a couple of bug reports, for example:

https://bugs.launchpad.net/bugs/938869  lsb_release crashed with SIGABRT
in Py_FatalError()

http://bugs.python.org/issue16202  sys.path[0] security issues

http://bugs.python.org/issue16248  Security bug in tkinter allows for
untrusted, arbitrary code execution.

---

The idea has been discussed at http://mail.python.org/pipermail/python-ideas/2012-November/017766.html.

----------
assignee: christian.heimes
messages: 175874
nosy: barry, christian.heimes, lemburg
priority: normal
severity: normal
stage: patch review
status: open
title: CLI option for isolated mode
type: security
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 18 16:20:05 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Nov 2012 15:20:05 +0000
Subject: [New-bugs-announce] [issue16500] Add an 'afterfork' module
Message-ID: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I propose the addition of an 'afterfork' module. The module shall fulfill a similar task as the 'atexit' module except that it handles process forks instead of process shutdown.

The 'afterfork' module shall allow libraries to register callbacks that are executed on fork() inside the child process and as soon as possible. Python already has a function that must be called by C code: PyOS_AfterFork(). The 'afterfork' callbacks are called as the last step in PyOS_AfterFork().

Use case example:
The tempfile module has a specialized RNG that re-initialized the RNG after fork() by comparing os.getpid() to an instance variable every time the RNG is accessed. The check can be replaced with an afterfork callback.

Open questions:
How should the afterfork() module handle exceptions that are raised by callbacks?

Implementation:
I'm going to use as much code from atexitmodule.c as possible. I'm going to copy common code to a template file and include the template from atexitmodule.c and afterforkmodule.c with some preprocessor tricks.

----------
assignee: christian.heimes
components: Extension Modules, Interpreter Core
keywords: needs review
messages: 175878
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add an 'afterfork' module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 18 18:15:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Nov 2012 17:15:07 +0000
Subject: [New-bugs-announce] [issue16501] deprecate RISCOS "support"
Message-ID: <1353258907.33.0.855880480918.issue16501@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

There are a couple of places in our code with references to RISCOS (mostly as #ifdef's). I propose we record this platform as deprecated in 3.4 and removed in 3.5. This needs PEP 11 to be updated.

Wikipedia mentions the existence of two operating systems named "RISC OS". I conjecture we are talking about this one: http://en.wikipedia.org/wiki/RISC_OS
In any case, there hasn't been any report of people actually running Python on that OS for years, so it's unlikely to work at all.

----------
components: Interpreter Core
messages: 175889
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: deprecate RISCOS "support"
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov 18 18:33:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Nov 2012 17:33:29 +0000
Subject: [New-bugs-announce] [issue16502] PEP 305: eaten backslashes
Message-ID: <1353260009.13.0.210575226551.issue16502@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In PEP 305 '\r\n' rendered as 'rn' in one place.  The proposed patch should fix this.

----------
assignee: docs at python
components: Documentation
files: pep-0305_rn.patch
keywords: patch
messages: 175891
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: PEP 305: eaten backslashes
Added file: http://bugs.python.org/file28028/pep-0305_rn.patch

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

From report at bugs.python.org  Sun Nov 18 18:35:16 2012
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 18 Nov 2012 17:35:16 +0000
Subject: [New-bugs-announce] [issue16503] Unclear documentation regarding
	apply(), 'extended call syntax'
Message-ID: <1353260116.84.0.175308282069.issue16503@psf.upfronthosting.co.za>


New submission from Zachary Ware:

(Reported by Kevin Leeds on docs at python.org)

The documentation for the apply() built-in function in 2.7 says that it is deprecated and to use "extended call syntax" instead.  There is no mention of "extended call syntax" anywhere else in the docs.  The simplest solution I can see is in the attached patch; it merely adds a link to the tutorial section about arbitrary argument lists within the deprecation warning.  I wonder though if the wording should be changed to something more findable.  What is the common wording of *args and **kwargs usage?

----------
assignee: docs at python
components: Documentation
files: arbitraryargs_2.7.patch
keywords: patch
messages: 175894
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Unclear documentation regarding apply(), 'extended call syntax'
versions: Python 2.7
Added file: http://bugs.python.org/file28029/arbitraryargs_2.7.patch

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

From report at bugs.python.org  Sun Nov 18 18:37:09 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 18 Nov 2012 17:37:09 +0000
Subject: [New-bugs-announce] [issue16504] IDLE - fatal error when opening a
	file with certain	tokenizing errors
Message-ID: <1353260229.78.0.447155145539.issue16504@psf.upfronthosting.co.za>


New submission from Roger Serwy:

IDLE's IndentSearcher class in EditorWindow.py can raise an uncaught IndentationError when opening a file. The attached patch fixes the problem by catching everything that the tokenize module can raise explicitly, namely IndentationError, TokenError, and SyntaxError.

Alternatively, the except clause can be left bare, as it is disappointing to crash IDLE when simply guessing the indent width of a file. (See "guess_indent" in EditorWindow.py)

----------
components: IDLE
files: editor_token_error.patch
keywords: patch
messages: 175895
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE - fatal error when opening a file with certain tokenizing errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28030/editor_token_error.patch

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

From report at bugs.python.org  Sun Nov 18 21:00:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Nov 2012 20:00:14 +0000
Subject: [New-bugs-announce] [issue16505] Drop Py_TPFLAGS_INT_SUBCLASS
Message-ID: <1353268814.03.0.789884448045.issue16505@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Py_TPFLAGS_INT_SUBCLASS is not used in Python 3. Lets drop it and free a one bit for some other interesting flag.

----------
components: Interpreter Core
files: drop_int_tpflag.patch
keywords: patch
messages: 175913
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Drop Py_TPFLAGS_INT_SUBCLASS
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28035/drop_int_tpflag.patch

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

From report at bugs.python.org  Sun Nov 18 23:24:37 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 18 Nov 2012 22:24:37 +0000
Subject: [New-bugs-announce] [issue16506] devguide should have table of
	contents
Message-ID: <1353277477.34.0.0074204417651.issue16506@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, the devguide does not have a table of contents.  For example, clicking the "Table of Contents" link in the left column does nothing.  My feeling is that a proper table of contents will make it easier to understand how the devguide is organized at a high level and to track what parts one has read and not read.  It is currently not so easy to do this.

----------
components: Devguide
messages: 175926
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: devguide should have table of contents

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

From report at bugs.python.org  Sun Nov 18 23:32:54 2012
From: report at bugs.python.org (Trent Nelson)
Date: Sun, 18 Nov 2012 22:32:54 +0000
Subject: [New-bugs-announce] [issue16507] Patch selectmodule.c to support
	WSAPoll on Windows
Message-ID: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za>


New submission from Trent Nelson:

Attached patch adds select.poll() support on Windows via WSAPoll.

It's hacky; I was curious to see whether or not it could be done, and whether or not tulip's pollster would work with it.

It compiles and works, but doesn't play very nicely with tulip.  Also, just about every lick of code that tests poll() does so in a UNIX-specific way, so it's hard to test.

As with select, WSAPoll() will barf if you feed it anything other than SOCKETs (i.e. it doesn't work against non-socket file descriptors).

----------
files: wsapoll.patch
keywords: patch
messages: 175927
nosy: trent
priority: normal
severity: normal
status: open
title: Patch selectmodule.c to support WSAPoll on Windows
Added file: http://bugs.python.org/file28038/wsapoll.patch

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

From report at bugs.python.org  Mon Nov 19 01:14:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 19 Nov 2012 00:14:41 +0000
Subject: [New-bugs-announce] [issue16508] include the "object" type in the
	lists of documented	types
Message-ID: <1353284081.12.0.684350303879.issue16508@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add the "object" type to the list of types documented in the language reference's standard type hierarchy and the library reference's list of built-in types:

http://docs.python.org/dev/reference/datamodel.html#the-standard-type-hierarchy
http://docs.python.org/dev/library/stdtypes.html#other-built-in-types

The constructor is documented here:

http://docs.python.org/dev/library/functions.html#object

In the documentation, it might also be worth stating explicitly which of the special methods the object type defines:

http://docs.python.org/dev/reference/datamodel.html#special-method-names

For example, object.__str__ is defined, but object.__bytes__ is not.  By doing this, users will know which special methods user-defined classes will automatically inherit.

----------
assignee: docs at python
components: Documentation
messages: 175938
nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: include the "object" type in the lists of documented types
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov 19 08:40:51 2012
From: report at bugs.python.org (Daniel Micay)
Date: Mon, 19 Nov 2012 07:40:51 +0000
Subject: [New-bugs-announce] [issue16509] sqlite3 docs do not explain
	check_same_thread
Message-ID: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>


New submission from Daniel Micay:

The sqlite3 documentation now includes a Multithreading section explaining issues with older sqlite versions, but still doesn't directly cover disabling check_same_thread beyond listing it as a possible parameter.

As far as I can tell, reusing sqlite connections in different threads (such as from a pool) is safe, as long as no attempt is made to use them from multiple threads with no locking.

----------
assignee: docs at python
components: Documentation
messages: 175946
nosy: docs at python, strcat
priority: normal
severity: normal
status: open
title: sqlite3 docs do not explain check_same_thread
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 19 11:44:18 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Nov 2012 10:44:18 +0000
Subject: [New-bugs-announce] [issue16510] Using appropriate checks in tests
Message-ID: <1353321858.76.0.504726837876.issue16510@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch upgrades tests to use specialized checks added in 3.1 and 3.2 (assertIsNone(x) instead assertTrue(x is None), assertLess(a, b) instead assertTrue(a < b), etc).  This modern checks provide a more useful error message in case of a fail.

Replaced only those checks that are not related to the tested operators.  For example, assertTrue(a < b) preserved if the operator "<" is tested.

----------
components: Tests
files: tests_asserts.patch
keywords: patch
messages: 175953
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Using appropriate checks in tests
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28041/tests_asserts.patch

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

From report at bugs.python.org  Tue Nov 20 10:11:23 2012
From: report at bugs.python.org (Trung Doan)
Date: Tue, 20 Nov 2012 09:11:23 +0000
Subject: [New-bugs-announce] [issue16511] IDLE configuration file: blank
	height and width fields	trip up IDLE
Message-ID: <1353402683.59.0.506153006404.issue16511@psf.upfronthosting.co.za>


New submission from Trung Doan:

In Python 2.5.4's config-main.cfg file, if [EditorWindow]'s width and height are left blank or set to zero, then IDLE window won't show. Uninstalling and re-installing Python didn't help. Problem solved only when the config-main.cfg file was manually edited to give non-zero values.

----------
components: IDLE
messages: 175979
nosy: doanviettrung
priority: normal
severity: normal
status: open
title: IDLE configuration file: blank height and width fields trip up IDLE
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Nov 20 11:21:20 2012
From: report at bugs.python.org (Joril)
Date: Tue, 20 Nov 2012 10:21:20 +0000
Subject: [New-bugs-announce] [issue16512] imghdr doesn't support jpegs with
	an ICC profile
Message-ID: <1353406880.2.0.236043197389.issue16512@psf.upfronthosting.co.za>


New submission from Joril:

imghdr doesn't support jpegs that include an ICC Profile.
This is because imghdr looks for "JFIF" somewhere at the beginning of the file, but the ICC_PROFILE shifts that further.
(The ICC spec is here http://www.color.org/specification/ICC1v43_2010-12.pdf, annex B)

----------
files: peanuts15.jpg
messages: 175984
nosy: joril
priority: normal
severity: normal
status: open
title: imghdr doesn't support jpegs with an ICC profile
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file28046/peanuts15.jpg

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

From report at bugs.python.org  Tue Nov 20 15:09:36 2012
From: report at bugs.python.org (moonflow)
Date: Tue, 20 Nov 2012 14:09:36 +0000
Subject: [New-bugs-announce] [issue16513] SGMLParser processing <tr> which
	include two <a> will	have problem
Message-ID: <1353420576.69.0.980129168556.issue16513@psf.upfronthosting.co.za>


New submission from moonflow:

if a <tr> include two <a> or more,SGMLParser processing has a problem

for example:
    <tr>
    <td align="center" valign="top" nowrap>
    <script language="Javascript">
    <!--
      if ( 4 == 4 ) document.write("<strong class=\"Critical small\">Critical</strong>");
      if ( 4 == 3 ) document.write("<strong class=\"High small\">High</strong>");
      if ( 4 == 2 ) document.write("<strong class=\"Medium small\">Medium</strong>");
      if ( 4 == 1 ) document.write("<strong class=\"Low small\">Low</strong>");
    //--> 
    </script>
    </td>
    <td valign="top" align="center" nowrap>
    <small><script type="text/javascript">document.write(FormatDate("%d-%b-%y", "2012", "11", "18"));</script></small>
    </td>
    <td valign="top" align="center" nowrap><small>
    <a title="CPAI-2012-809" style="text-transform:uppercase" href="2012/cpai-08-nov.html">
    CPAI-2012-809</a></small>
    </td>
    <td valign="top" nowrap align="center"><small>
    <a target="_blank" href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2089">CVE-2011-2089</a><br /></small>
    </td>
    <td valign="top"><small>SCADA ICONICS WebHMI ActiveX Stack Overflow (2011-2089)</small></td>
    </tr>

def start_a(self, attrs):
        if self.is_td:       
            cve_href = [v for k, v in attrs if k == "target" and v == "_blank"]
            if cve_href:
                self.is_a = True
                self.is_cve = True

            #for SGMLParser maybe have a bug,a <tr> have two <a> has problem
            vul_href = [v for k, v in attrs if k == "style"]
            print vul_href
            if vul_href:
                vul_href = "".join([v for k, v in attrs if k == "href"])
                if vul_href.find("cve") == -1:
                    self.href_name = vul_href     
            else:
                self.href_name = ""

here print vul_href but print nothing.Is it ok?

----------
components: Library (Lib)
files: testbug.py
messages: 175990
nosy: moonflow
priority: normal
severity: normal
status: open
title: SGMLParser processing <tr> which include two <a> will have problem
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28049/testbug.py

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

From report at bugs.python.org  Tue Nov 20 16:17:15 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 20 Nov 2012 15:17:15 +0000
Subject: [New-bugs-announce] [issue16514] Cryptic traceback when sys.path[0]
	is None
Message-ID: <1353424635.18.0.600046275263.issue16514@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

When sys.path[0] is None, attempting to import a module produces a cryptic chained traceback.  This is a regression from 3.2 where the import would succeed.

The basic issue is that in 3.2's import.c, non-string/bytes items on sys.path are essentially ignored (see the loop in import.c:1708 find_module()) while they are not ignored in 3.3's importlib.  This means that because zipimporter.zipimiporter is by default the first thing on sys.path_hooks, zipimporter.zipimporter(None) gets called.  This raises a TypeError which starts the chained exception.  Note that the fact that zipimporter.zipimporter(None) raises a TypeError is *not* a regression.  The regression is that None makes its way to sys.path_hooks at all.

I think this will be relatively easy to fix, if we agree that the current regressive behavior is a bug.

----------
assignee: barry
components: Interpreter Core
keywords: 3.3regression
messages: 175996
nosy: barry
priority: high
severity: normal
status: open
title: Cryptic traceback when sys.path[0] is None
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov 20 23:36:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 20 Nov 2012 22:36:57 +0000
Subject: [New-bugs-announce] [issue16515] TypeError message incorrect for
	max() with no args
Message-ID: <1353451017.11.0.598123114389.issue16515@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The below should probably say something along the lines of "max expected 1 positional arguments" (since the foo value is an argument):

>>> max(foo=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: max expected 1 arguments, got 0

I imagine this affects other functions, but I haven't looked into which ones.

Here is an example of another built-in function that provides a better message:

>>> sorted(foo=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Required argument 'iterable' (pos 1) not found

----------
components: Interpreter Core
messages: 176034
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: TypeError message incorrect for max() with no args
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 04:28:27 2012
From: report at bugs.python.org (Joel Nothman)
Date: Wed, 21 Nov 2012 03:28:27 +0000
Subject: [New-bugs-announce] [issue16516] argparse types (and actions) must
	be hashable
Message-ID: <1353468507.9.0.0965555550975.issue16516@psf.upfronthosting.co.za>


New submission from Joel Nothman:

The argparse documentation states that "type= can take any callable that takes a single string argument and returns the converted value". The following is an exception:

    >>> import argparse
    >>> ap = argparse.ArgumentParser()
    >>> ap.add_argument('foo', type={}.get)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3/argparse.py", line 1294, in add_argument
        type_func = self._registry_get('type', action.type, action.type)
      File "/usr/lib/python3/argparse.py", line 1236, in _registry_get
        return self._registries[registry_name].get(value, default)
    TypeError: unhashable type: 'dict'

Sadly, a method bound to an unhashable type is unhashable! (Of course, is trivial to use partial or lambda to make any function hashable.)

The offending line in _registry_get is intended to look up named types (or actions), so it perhaps only relevant for string type= and action= values, which could be handled explicitly instead of using dict.get(x, x) to handle both cases. Alternatively, the TypeError could be caught and default returned.

----------
components: Library (Lib)
messages: 176040
nosy: bethard, jnothman
priority: normal
severity: normal
status: open
title: argparse types (and actions) must be hashable
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 06:32:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 21 Nov 2012 05:32:27 +0000
Subject: [New-bugs-announce] [issue16517] address merge conflicts in
	devguide null-merge	instructions
Message-ID: <1353475947.45.0.611310875151.issue16517@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The null-merge instructions in the devguide (in the "note" box in the section linked to below):

http://docs.python.org/devguide/committing.html#porting-within-a-major-version

are incomplete if the merge created conflicts.  It would help to include instructions on how to resolve this scenario.  Proposed patch attached.  (Am I right that the `hg resolve` is required?)

[Also adding David since this or a related topic came up with him on IRC a couple(?) months back.]

----------
assignee: chris.jerdonek
components: Devguide
files: issue-null-merge-1.patch
keywords: easy, patch
messages: 176041
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: address merge conflicts in devguide null-merge instructions
type: enhancement
Added file: http://bugs.python.org/file28059/issue-null-merge-1.patch

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

From report at bugs.python.org  Wed Nov 21 07:03:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 21 Nov 2012 06:03:27 +0000
Subject: [New-bugs-announce] [issue16518] add "buffer protocol" to glossary
Message-ID: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add "buffer protocol" (or perhaps "buffer object") to the glossary.  The concept is currently described here:

http://docs.python.org/dev/c-api/buffer.html#buffer-protocol

?ric initially suggested doing this in the comments to issue 13538.

Such a glossary entry would be useful because the buffer protocol (or buffer object) should likely be cited, for example, wherever a function accepts a bytes object, bytearray object, or any object that supports the buffer protocol.  The str() constructor is one example where this is done:

http://hg.python.org/cpython/file/59acd5cac8b5/Doc/library/functions.rst#l1275

"Buffer object" might be the more useful term to add to the glossary because it would help to have a briefer way of saying "any object that supports the buffer protocol."  (I'm assuming this is what "buffer object" actually means.)

The patch for this issue should also do a comprehensive review of occurrences of buffer object/protocol throughout the docs and add or update links and index entries where appropriate.

----------
assignee: docs at python
components: Documentation
messages: 176042
nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, pitrou
priority: normal
severity: normal
status: open
title: add "buffer protocol" to glossary
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 08:58:54 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Nov 2012 07:58:54 +0000
Subject: [New-bugs-announce] [issue16519] site.venv() should use
	abspath(executable)
Message-ID: <1353484734.27.0.00447607755708.issue16519@psf.upfronthosting.co.za>


New submission from Christian Heimes:

While I was testing #16499 I found a small bug in the venv code of the site module. The code in site.venv() doesn't use abspath() to sanitize the path to executable_dir. This leads to wrong behavior when a venv is created in the root of a hg checkout and the non-venv interpreter is called with a relative path:

(venv) heimes at hamiller:~/dev/python/cpython/venv$ ../python -c "import sys; print(sys.path)"
['', '/usr/local/lib/python34.zip', '/home/heimes/dev/python/cpython/Lib', '/home/heimes/dev/python/cpython/Lib/plat-linux', '/home/heimes/dev/python/cpython/build/lib.linux-x86_64-3.4-pydebug', '/home/heimes/dev/python/cpython/venv/lib/python3.4/site-packages']

The fix is simple, straight forward and totally harmless:
--- a/Lib/site.py
+++ b/Lib/site.py
@@ -484,7 +484,7 @@
         executable = os.environ['__PYVENV_LAUNCHER__']
     else:
         executable = sys.executable
-    executable_dir, executable_name = os.path.split(executable)
+    executable_dir, executable_name = os.path.split(os.path.abspath(executable))
     site_prefix = os.path.dirname(executable_dir)
     sys._home = None
     if sys.platform == 'win32':

----------
components: Interpreter Core
messages: 176043
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: site.venv() should use abspath(executable)
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 09:45:12 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 21 Nov 2012 08:45:12 +0000
Subject: [New-bugs-announce] [issue16520] subprocess.Popen() TypeError
	message incorrect without	args argument
Message-ID: <1353487512.93.0.371965893186.issue16520@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The TypeError message when a call to subprocess.Popen() lacks the args argument is incorrect.

For 3.3 and 3.4, the message incorrectly says that a positional argument is required when a keyword argument will do:

>>> import subprocess
>>> subprocess.Popen()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() missing 1 required positional argument: 'args'
>>> subprocess.Popen(args=['test'])
<subprocess.Popen object at 0x10bed4840>

For 3.2 and 2.7, the problem is slightly different.  It says that two arguments are needed and that two have been given:

>>> subprocess.Popen()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() takes at least 2 arguments (1 given)
>>> subprocess.Popen(shell=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() takes at least 2 arguments (2 given)

I don't know if this issue affects other functions in the standard library, but I suspect it might.

----------
components: Library (Lib)
messages: 176047
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: subprocess.Popen() TypeError message incorrect without args argument
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 13:18:21 2012
From: report at bugs.python.org (Jovik)
Date: Wed, 21 Nov 2012 12:18:21 +0000
Subject: [New-bugs-announce] [issue16521] logging.basicConfig creates empty
	file when using	handlers
Message-ID: <1353500301.35.0.410282518937.issue16521@psf.upfronthosting.co.za>


New submission from Jovik:

Using logging.basicConfig() with Python 3.2.3 accepts handlers options without any errors. It creates an empty file. I don't think this should be default behaviour, sice it's very missleading (no exception thrown; no warning on standard output or in the file)

----------
components: Library (Lib)
files: logginghandler.py
messages: 176052
nosy: Jovik
priority: normal
severity: normal
status: open
title: logging.basicConfig creates empty file when using handlers
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file28060/logginghandler.py

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

From report at bugs.python.org  Wed Nov 21 14:39:39 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Nov 2012 13:39:39 +0000
Subject: [New-bugs-announce] [issue16522] Add 'FAIL_FAST' flag to doctest
Message-ID: <1353505179.63.0.615985281982.issue16522@psf.upfronthosting.co.za>


New submission from R. David Murray:

When debugging using tests or doing test driven development, I find it very useful to have the test run exit immediately on the first failure.  Doctest currently has a feature to suppress all output after the first failure, but not to exit on the first failure.  Exiting on the first failure in doctest is even more important than in unit test for me, since a typical way to debug using doctest is to add prints to sys.stderr to the code.  If the doctest run continues, other tests that follow the same code path may also dump debugging output, making it harder to find the output related specifically to the test failure.

The attached patch does the easy part: adds a FAIL_FAST flag.  I don't have time right at the moment to finish the patch with docs and tests.  If someone wants to work on this before I get back to it they should feel free (just post a note here that you are working on it).

----------
assignee: r.david.murray
files: doctest_fail_fast.patch
keywords: easy, patch
messages: 176059
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Add 'FAIL_FAST' flag to doctest
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28063/doctest_fail_fast.patch

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

From report at bugs.python.org  Wed Nov 21 16:16:06 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Nov 2012 15:16:06 +0000
Subject: [New-bugs-announce] [issue16523] attrgetter and itemgetter
	signatures in docs need cleanup
Message-ID: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za>


New submission from R. David Murray:

It looks like the use of the 'args' formal parameter was cut and pasted from the methodcaller docs, when it is not appropriate for itemgetter and attrgetter.

     http://docs.python.org/3/library/operator.html#operator.attrgetter

----------
assignee: docs at python
components: Documentation
messages: 176060
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: attrgetter and itemgetter signatures in docs need cleanup
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 17:18:02 2012
From: report at bugs.python.org (Antoine Brodin)
Date: Wed, 21 Nov 2012 16:18:02 +0000
Subject: [New-bugs-announce] [issue16524] File access not always working
	with Python for Windows	32 bits on Windows 64 bits OS
Message-ID: <1353514682.16.0.187525940709.issue16524@psf.upfronthosting.co.za>


New submission from Antoine Brodin:

I have a file:

>dir c:\Windows\System32\scext.dll
14/07/2009  02:41            89?088 scext.dll

With Python 32 bits it fails:

>c:\Python27\python.exe
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat('c:\Windows\System32\scext.dll')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 2] Le fichier sp?cifi? est introuvable: 'c:\\Windows\\Syste
m32\\scext.dll'

With Python 64bits it succeeds:

>c:\Python27-x64\python.exe
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat('c:\Windows\System32\scext.dll')
nt.stat_result(st_mode=33206, st_ino=0L, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=89088L, st_atime=1247527874L, st_mtime=1247535713L, st_ctime=1247527874L)

----------
components: Windows
messages: 176064
nosy: Antoine.Brodin
priority: normal
severity: normal
status: open
title: File access not always working with Python for Windows 32 bits on Windows 64 bits OS
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 21 21:13:47 2012
From: report at bugs.python.org (Sebastian Kraft)
Date: Wed, 21 Nov 2012 20:13:47 +0000
Subject: [New-bugs-announce] [issue16525] wave file module does not support
	32bit float format
Message-ID: <1353528827.37.0.543069044809.issue16525@psf.upfronthosting.co.za>


New submission from Sebastian Kraft:

The wave module cannot read audio WAV files containing 32bit float values. This is a very common file type for professional audio!

There has already been a patch some years ago which works fine but was finally not applied. I can confirm that it does not break anything and only adds support for a new number format.

http://bugs.python.org/issue1144504

----------
components: Extension Modules, IO
messages: 176077
nosy: Sebastian.Kraft
priority: normal
severity: normal
status: open
title: wave file module does not support 32bit float format
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 21 22:58:03 2012
From: report at bugs.python.org (Lothsahn)
Date: Wed, 21 Nov 2012 21:58:03 +0000
Subject: [New-bugs-announce] [issue16526] Python does not cross compile
	properly
Message-ID: <1353535083.98.0.533437922947.issue16526@psf.upfronthosting.co.za>


New submission from Lothsahn:

Python doesn't really support cross compilation.  I've created a patch for Python 2.7.3 which compiles nearly all of Python (except a couple modules).  Patches for Python 3 are also included, but I didn't have anything to do with them.

My patch allows for cross compilation as well as the building of modules.

The only issue I'm aware of is that the ELFCLASS of the modules that are to be built must be the same.  This is because python uses sys.platform to determine which folder to generate the modules in, and so the sys.platform is always that of the host system.  When generating the modules, we should probably generate them twice, once for the host system (using sys.platform), and once for the cross-compiled system (using the cross-compiled system's sys.platform).

The patches can be found here:
http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html

Given the rise of embedded systems, it's a big drawback that cross compiling Python is so difficult.

----------
components: Build, Cross-Build
messages: 176080
nosy: Lothsahn
priority: normal
severity: normal
status: open
title: Python does not cross compile properly
type: compile error
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Nov 22 00:41:01 2012
From: report at bugs.python.org (Alexis Daboville)
Date: Wed, 21 Nov 2012 23:41:01 +0000
Subject: [New-bugs-announce] [issue16527] (very) long list of elif causes
	segfault
Message-ID: <1353541261.75.0.656206042402.issue16527@psf.upfronthosting.co.za>


New submission from Alexis Daboville:

Hi,

It looks like using a very long list of elif makes CPython segfault. You can try it with the attached file, which looks like this:

if False:
   pass
elif False:
   pass
   # thousands of elifs
elif False:
   pass

$ python elif_segfault.py
Segmentation fault.

CPython versions tested:
3.x (all segfaults):
3.1 on Debian
3.2 on Arch Linux
3.3 on Windows

2.6 on Debian: segfaults with a longer list of elifs than the one in the attached file.

The PyPy behaviour seems better: it raises 'RuntimeError: maximum recursion depth exceeded'.

A possible cause (if I understood <http://greentreesnakes.readthedocs.org/en/latest/nodes.html#If> well) is that there are no elif nodes in the AST, elif are just plain ifs which are stored recursively in the else part of the previous if.

(I'm not sure if that's an issue as it's not a real use case, but it makes CPython segfault and I was advised on #python-fr to report it anyway.)

----------
files: elif_segfault.py
messages: 176081
nosy: alexis.d
priority: normal
severity: normal
status: open
title: (very) long list of elif causes segfault
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file28068/elif_segfault.py

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

From report at bugs.python.org  Thu Nov 22 03:30:09 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 22 Nov 2012 02:30:09 +0000
Subject: [New-bugs-announce] [issue16528] 3.2 docs not updating on
	docs.python.org
Message-ID: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The 3.2 docs haven't updated since Oct 28, 2012:

http://docs.python.org/3.2/

The commits for the Doc folder around that time are as follows.  I observed that the top commit was not built, but I'm not sure about the ones previous:

$ hg log -b 3.2 Doc | more

changeset:   80018:40aedc7da30f
branch:      3.2
parent:      79798:16493102f9b1
user:        Andrew Svetlov <andrew.svetlov at gmail.com>
date:        Sun Oct 28 14:10:30 2012 +0200
summary:     Issue #14570: Document json sort_keys parameter properly.

changeset:   79996:e02d49db3f5b
branch:      3.2
parent:      79989:f6d04f5cff31
user:        Georg Brandl <georg at python.org>
date:        Sun Oct 28 07:59:42 2012 +0100
summary:     #8040: fix jQuery incompatibility

changeset:   79984:36a35b86e3b0
branch:      3.2
parent:      79980:740be7346c92
user:        Ezio Melotti <ezio.melotti at gmail.com>
date:        Sat Oct 27 23:12:48 2012 +0300
summary:     #8040: fix the version.

changeset:   79980:740be7346c92
branch:      3.2
parent:      79976:35a2a0e166d0
user:        Ezio Melotti <ezio.melotti at gmail.com>
date:        Sat Oct 27 22:28:48 2012 +0300
summary:     #8040: enable the versionswitcher for the autobuild-dev target.

changeset:   79976:35a2a0e166d0
branch:      3.2
parent:      79972:abbfb89055d3
user:        Ezio Melotti <ezio.melotti at gmail.com>
date:        Sat Oct 27 22:09:16 2012 +0300
summary:     #8040: add a version switcher to the documentation.  Patch by Yury Selivanov.

----------
assignee: docs at python
components: Documentation
messages: 176090
nosy: chris.jerdonek, docs at python, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: 3.2 docs not updating on docs.python.org
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 22 09:49:45 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 22 Nov 2012 08:49:45 +0000
Subject: [New-bugs-announce] [issue16529] Compiler error when trying to
	compile ceval.c on	OpenSUSE 11.3
Message-ID: <1353574185.01.0.323738312876.issue16529@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

When trying to compile the hg checkout (2012-11-22), I'm getting a compiler error from GCC when trying to compile ceval.c on OpenSUSE 11.3 x64:

gcc -pthread -c -Wno-unused-result -DNDEBUG -g -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c
Python/ceval.c: In function PyEval_EvalFrameEx:
Python/ceval.c:3168:1: internal compiler error: in save_call_clobbered_regs, at caller-save.c:911
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.opensuse.org/> for instructions.
make: *** [Python/ceval.o] Error 1

Here's the gcc version info:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux)

Interestingly, this error does not happen when compiling the 3.3.0 release version.

It looks similar to these two bugs that are related to some optimization bug in GCC:

 * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259 (I can't reproduce this one)
 * https://bugzilla.redhat.com/show_bug.cgi?id=622060 (This was detected in Fedora for Python 3.1.2)

I guess you could say that the compiler is broken, but I still think that Python's configure script should detect this and then disable --with-computed-gotos.

----------
components: Build, Interpreter Core
messages: 176101
nosy: lemburg
priority: normal
severity: normal
status: open
title: Compiler error when trying to compile ceval.c on OpenSUSE 11.3
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 22 17:28:58 2012
From: report at bugs.python.org (George Yoshida)
Date: Thu, 22 Nov 2012 16:28:58 +0000
Subject: [New-bugs-announce] [issue16530] documentation of os.wait3
Message-ID: <1353601738.51.0.504098475316.issue16530@psf.upfronthosting.co.za>


New submission from George Yoshida:

Documentation defines os.wait3 function as :
> os.wait3([options])
but, this argument is required(no default options are set), so
> os.wait3(options)
is the correct definition.

http://docs.python.org/3.3/library/os.html#os.wait3

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 176112
nosy: docs at python, quiver
priority: low
severity: normal
status: open
title: documentation of os.wait3
type: behavior
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/issue16530>
_______________________________________

From report at bugs.python.org  Thu Nov 22 22:59:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Nov 2012 21:59:26 +0000
Subject: [New-bugs-announce] [issue16531] Allow IPNetwork to take a tuple
Message-ID: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I am in a situation where I'm building an IPNetwork from separate address and mask information. So roughly I'd like to write either:

 addr = IPAddress('192.168.0.0')
 network = IPNetwork((addr, '255.255.0.0'))

or

 addr = '192.168.0.0'
 network = IPNetwork((addr, '255.255.0.0'))

Of course it seems like this would be equivalent to:

 network = IPNetwork('%s/%s' % (addr, '255.255.0.0.'))

(but more user-friendly :-))

----------
components: Library (Lib)
messages: 176129
nosy: ncoghlan, pitrou, pmoody
priority: low
severity: normal
status: open
title: Allow IPNetwork to take a tuple
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 22 23:11:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Nov 2012 22:11:24 +0000
Subject: [New-bugs-announce] [issue16532] AMD64 Windows 7 build failures
Message-ID: <1353622284.34.0.503862642537.issue16532@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The AMD64 Windows 7 buildbot shows weird build failures in ctypes:
http://buildbot.python.org/all/buildslaves/kloth-win64

----------
keywords: buildbot
messages: 176131
nosy: jeremy.kloth, jkloth, pitrou
priority: high
severity: normal
status: open
title: AMD64 Windows 7 build failures
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 22 23:18:32 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 22 Nov 2012 22:18:32 +0000
Subject: [New-bugs-announce] [issue16533] HPUX: Unable to fork() in thread
Message-ID: <1353622712.14.0.676507060266.issue16533@psf.upfronthosting.co.za>


New submission from Stefan Krah:

There's an error on the HPUX-IA64 buildbot that might be due to
some kernel limits. Trent, could you check if the following helps
(requires root)?

http://zensonic.dk/?p=326



test_forkinthread (test.test_thread.TestForkInThread) ... Fatal Python error: Invalid thread state for this thread
test test_thread failed -- Traceback (most recent call last):
  File "/home/cpython/buildslave/2.7.snakebite-hpux11iv3-ia64-1/build/Lib/test/test_support.py", line 1265, in decorator
    return func(*args)
  File "/home/cpython/buildslave/2.7.snakebite-hpux11iv3-ia64-1/build/Lib/test/test_thread.py", line 246, in test_forkinthread
    "Unable to fork() in thread")
AssertionError: Unable to fork() in thread

----------
components: Tests
messages: 176132
nosy: skrah, trent
priority: normal
severity: normal
status: open
title: HPUX: Unable to fork() in thread
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 22 23:23:46 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 22 Nov 2012 22:23:46 +0000
Subject: [New-bugs-announce] [issue16534] test_float failure on IA64 (HPUX)
Message-ID: <1353623026.18.0.63278964149.issue16534@psf.upfronthosting.co.za>


New submission from Stefan Krah:

There's a test_float failure on HPUX (and many compiler warnings):

test test_float failed -- Traceback (most recent call last):
  File "/home/cpython/buildslave/2.7.snakebite-hpux11iv3-ia64-1/build/Lib/test/test_float.py", line 622, in test_format_testfile
    self.assertEqual(fmt % arg, rhs)
AssertionError: '9999999999999999464902769475481793200000000000000' != '9999999999999999464902769475481793196872414789632'

----------
components: Tests
messages: 176133
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: test_float failure on IA64 (HPUX)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 22 23:45:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Nov 2012 22:45:38 +0000
Subject: [New-bugs-announce] [issue16535] json encoder unable to handle
	decimal
Message-ID: <1353624338.46.0.574343718645.issue16535@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

In 2.7 and other versions, the json module has incomplete support for decimals:

>>> json.loads('0.2', parse_float=Decimal)
Decimal('0.2')
>>> json.dumps(json.loads('0.2', parse_float=Decimal))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
  File "/usr/lib/python2.7/json/encoder.py", line 201, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python2.7/json/encoder.py", line 264, in iterencode
    return _iterencode(o, 0)
  File "/usr/lib/python2.7/json/encoder.py", line 178, in default
    raise TypeError(repr(o) + " is not JSON serializable")
TypeError: Decimal('0.2') is not JSON serializable

simplejson encodes decimals out of the box, but json can?t round-trip.

----------
messages: 176135
nosy: eric.araujo, ezio.melotti, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: json encoder unable to handle decimal
type: behavior

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

From report at bugs.python.org  Fri Nov 23 00:38:38 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 22 Nov 2012 23:38:38 +0000
Subject: [New-bugs-announce] [issue16536] test_cmd_line: failure on Ubuntu
	Shared
Message-ID: <1353627518.27.0.770445773645.issue16536@psf.upfronthosting.co.za>


New submission from Stefan Krah:

======================================================================
FAIL: test_unknown_options (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_cmd_line.py", line 393, in test_unknown_options
    self.assertIn(b'Unknown option', err)
AssertionError: b'Unknown option' not found in b'/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/python: error while loading shared libraries: libpython3.4dm.so.1.0: cannot open shared object file: No such file or directory'

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

----------
components: Tests
messages: 176139
nosy: skrah
priority: normal
severity: normal
status: open
title: test_cmd_line: failure on Ubuntu Shared
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 23 02:14:17 2012
From: report at bugs.python.org (Jonathan Hosmer)
Date: Fri, 23 Nov 2012 01:14:17 +0000
Subject: [New-bugs-announce] [issue16537] setup.py throws a ValueError when
	self.extensions is	empty
Message-ID: <1353633257.31.0.391670680901.issue16537@psf.upfronthosting.co.za>


New submission from Jonathan Hosmer:

When disabled_module_list contains all the module names that are not built by Modules/Setup.dist, self.extensions in setup.py will be an empty list and when build_extensions tries to determine the max length of all extension names it raises a ValueError with the following traceback:

Traceback (most recent call last):
  File "./setup.py", line 2143, in <module>
    main()
  File "./setup.py", line 2138, in main
    'Lib/smtpd.py']
  File "/Users/pythonforios/Python_for_iOS/trunk/Python_for_iOS/python2.7/Lib/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/Users/pythonforios/Python_for_iOS/trunk/Python_for_iOS/python2.7/Lib/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/Users/pythonforios/Python_for_iOS/trunk/Python_for_iOS/python2.7/Lib/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Users/pythonforios/Python_for_iOS/trunk/Python_for_iOS/python2.7/Lib/distutils/command/build.py", line 127, in run
    self.run_command(cmd_name)
  File "/Users/pythonforios/Python_for_iOS/trunk/Python_for_iOS/python2.7/Lib/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/Users/pythonforios/Python_for_iOS/trunk/Python_for_iOS/python2.7/Lib/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Users/pythonforios/Python_for_iOS/trunk/Python_for_iOS/python2.7/Lib/distutils/command/build_ext.py", line 339, in run
    self.build_extensions()
  File "./setup.py", line 282, in build_extensions
    longest = max([len(e.name) for e in self.extensions])
ValueError: max() arg is an empty sequence
make: *** [sharedmods] Error 1

~~~ An example disabled_module_list from setup.py: ~~~

disabled_module_list = [
# Modules not compatible/not applicable for the iOS
'dl', 'nis', 'gdbm', 'spwd', '_bsddb', '_curses', '_tkinter', 'readline', 'bsddb185', 'ossaudiodev', 'sunaudiodev', '_curses_panel', 'linuxaudiodev',  
# Modules appended to inittab before embedded initialization
'_multiprocessing', 'future_builtins', '_ctypes_test', '_testcapi', '_sqlite3', '_hashlib', '_hotshot', '_scproxy', '_pybsddb', 'imageop', '_ctypes', '_lsprof', '_heapq', '_yaml', '_json', 'math', 'zlib', '_io', 'bz2', 'dbm'
]

~~~ Example Modules/Setup.dist: ~~~

DESTLIB=$(LIBDEST)
MACHDESTLIB=$(BINLIBDEST)
DESTPATH=
SITEPATH=
TESTPATH=
MACHDEPPATH=:plat-$(MACHDEP)
EXTRAMACHDEPPATH=
TKPATH=:lib-tk
OLDPATH=:lib-old
COREPYTHONPATH=$(DESTPATH)$(SITEPATH)$(TESTPATH)$(MACHDEPPATH)$(EXTRAMACHDEPPATH)$(TKPATH)$(OLDPATH)
PYTHONPATH=$(COREPYTHONPATH)

*static*

posix posixmodule.c
errno errnomodule.c
pwd pwdmodule.c
_sre _sre.c
_codecs _codecsmodule.c
zipimport zipimport.c
_symtable symtablemodule.c
array arraymodule.c
cmath cmathmodule.c _math.c
_struct _struct.c
time timemodule.c -lm
operator operator.c
_weakref _weakref.c
_random _randommodule.c
_collections _collectionsmodule.c
itertools itertoolsmodule.c
strop stropmodule.c
_functools _functoolsmodule.c
_elementtree -I$(srcdir)/Modules/expat -DHAVE_EXPAT_CONFIG_H -DUSE_PYEXPAT_CAPI _elementtree.c
datetime datetimemodule.c
_bisect _bisectmodule.c
unicodedata unicodedata.c
_locale _localemodule.c
fcntl fcntlmodule.c
grp grpmodule.c
select selectmodule.c
mmap mmapmodule.c
_csv _csv.c
_socket socketmodule.c
SSL=/usr/local/OpenSSL_for_iOS
_ssl _ssl.c -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl -L$(SSL)/lib -lssl -lcrypto
crypt cryptmodule.c
termios termios.c
resource resource.c
audioop audioop.c
imageop imageop.c
_md5 md5module.c md5.c
_sha shamodule.c
_sha256 sha256module.c
_sha512 sha512module.c
timing timingmodule.c
syslog syslogmodule.c
binascii binascii.c
parser parsermodule.c
cStringIO cStringIO.c
cPickle cPickle.c
fpectl fpectlmodule.c
fpetest fpetestmodule.c
pyexpat expat/xmlparse.c expat/xmlrole.c expat/xmltok.c pyexpat.c -I$(srcdir)/Modules/expat -DHAVE_EXPAT_CONFIG_H -DUSE_PYEXPAT_CAPI
_multibytecodec cjkcodecs/multibytecodec.c
_codecs_cn cjkcodecs/_codecs_cn.c
_codecs_hk cjkcodecs/_codecs_hk.c
_codecs_iso2022 cjkcodecs/_codecs_iso2022.c
_codecs_kr cjkcodecs/_codecs_kr.c
_codecs_tw cjkcodecs/_codecs_tw.c
_codecs_jp cjkcodecs/_codecs_jp.c
xxsubtype xxsubtype.c

----------
components: Build
messages: 176142
nosy: jhosmer
priority: normal
severity: normal
status: open
title: setup.py throws a ValueError when self.extensions is empty
type: compile error
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/issue16537>
_______________________________________

From report at bugs.python.org  Fri Nov 23 14:09:19 2012
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 23 Nov 2012 13:09:19 +0000
Subject: [New-bugs-announce] [issue16538] The docs doesn't describe
	MAKE_CLOSURE correctly
Message-ID: <1353676159.67.0.844924036734.issue16538@psf.upfronthosting.co.za>


New submission from Daniel Urban:

The documentation of the dis module describes the MAKE_CLOSURE opcode incorrectly. The description of MAKE_FUNCTION was updated in 242d3f8e8c50 (issue14349) to include the qualified name, but MAKE_CLOSURE wan't. A patch is attched.

----------
assignee: docs at python
components: Documentation
files: make_closure.patch
keywords: needs review, patch
messages: 176166
nosy: daniel.urban, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: The docs doesn't describe MAKE_CLOSURE correctly
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28086/make_closure.patch

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

From report at bugs.python.org  Fri Nov 23 14:53:28 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Nov 2012 13:53:28 +0000
Subject: [New-bugs-announce] [issue16539] Turn off 'No handlers could be
	found for logger' message
Message-ID: <1353678808.84.0.584809464228.issue16539@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

It is very annoying. Take this as an example. 'patch' is a module (library) that is meant to be used from other programs. Therefore it can not (should not) setup handlers for itself.

>>> import patch
>>> patch.PatchSet().parse('7745')
No handlers could be found for logger "patch"

Is it the same for Python 3?

----------
components: Library (Lib)
messages: 176170
nosy: techtonik, vinay.sajip
priority: normal
severity: normal
status: open
title: Turn off 'No handlers could be found for logger' message
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 23 17:51:40 2012
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 23 Nov 2012 16:51:40 +0000
Subject: [New-bugs-announce] [issue16540] Make itertools count, cycle,
	and repeat objects subscriptable like range.
Message-ID: <1353689500.44.0.874231567129.issue16540@psf.upfronthosting.co.za>


New submission from Neil Girdhar:

When using sequence types polymorphically, range, list, and tuple are both iterable and subscriptable.  Unfortunately, itertools.count, cycle, and repeat objects are not subscriptable, although this is not a hard change.

Please consider making these objects subscriptable for polymorphic usage.

----------
components: Library (Lib)
messages: 176183
nosy: Neil.Girdhar
priority: normal
severity: normal
status: open
title: Make itertools count, cycle, and repeat objects subscriptable like range.
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Nov 23 18:24:51 2012
From: report at bugs.python.org (Helmut Jarausch)
Date: Fri, 23 Nov 2012 17:24:51 +0000
Subject: [New-bugs-announce] [issue16541] tk_setPalette doesn't accept
	keyword parameters
Message-ID: <1353691491.46.0.777146427691.issue16541@psf.upfronthosting.co.za>


New submission from Helmut Jarausch:

import tkinter as Tk
root= Tk.Tk()
root.tk_setPalette(background = 'AntiqueWhite1', foreground = 'blue')

but python-3.3:0+ (3.3:27cb1a3d57c8+) gives

Traceback (most recent call last):
  File "Matr_Select.py", line 174, in <module>
    root.tk_setPalette(background = 'AntiqueWhite1', foreground = 'blue')
  File "/usr/lib64/python3.3/tkinter/__init__.py", line 390, in 
tk_setPalette
    + _flatten(args) + _flatten(kw.items()))
TypeError: argument must be sequence

Thanks for looking into it,
Helmut.

----------
components: Tkinter
messages: 176193
nosy: HJarausch
priority: normal
severity: normal
status: open
title: tk_setPalette doesn't accept keyword parameters
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 23 18:38:36 2012
From: report at bugs.python.org (joko suwito)
Date: Fri, 23 Nov 2012 17:38:36 +0000
Subject: [New-bugs-announce] [issue16542] http//bugs.python/joko.suwito
Message-ID: <CAJO910B=Sz9cr+Fb8nCCF=AirBFSMTvjyfYwb3uw9cO7DtLB0w@mail.gmail.com>


New submission from joko suwito:

thank you

----------
messages: 176194
nosy: joko.suwito
priority: normal
severity: normal
status: open
title: http//bugs.python/joko.suwito

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

From report at bugs.python.org  Fri Nov 23 19:03:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 18:03:13 +0000
Subject: [New-bugs-announce] [issue16543] Use "positional arguments" in
	PyArg_UnpackTuple
Message-ID: <1353693793.28.0.492811281384.issue16543@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

This came up in #16515.
While using PyArg_UnpackTuple to parse the positional arguments in a function that receives both positional and keyword arguments, the error message returned when the number of arguments is incorrect is misleading, e.g.:
>>> max(foo=1)
TypeError: max expected 1 arguments, got 0

This can be fixed by adding "positional" before "arguments" in the error message.  The attached patch fixes this and the pluralization of "argument(s)".

----------
assignee: ezio.melotti
components: Interpreter Core
files: unpacktuple.diff
keywords: patch
messages: 176202
nosy: ezio.melotti
priority: normal
severity: normal
stage: test needed
status: open
title: Use "positional arguments" in PyArg_UnpackTuple
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28090/unpacktuple.diff

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

From report at bugs.python.org  Fri Nov 23 21:20:32 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 23 Nov 2012 20:20:32 +0000
Subject: [New-bugs-announce] [issue16544] Add external link to ast docs
Message-ID: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

http://greentreesnakes.readthedocs.org/en/latest/index.html
is excellent and comprehensive documentation for ast tree structures.
It would be nice to incorporate that docs into stdlib documentation, but adding *see also* section is good enoigh as first step.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 176239
nosy: asvetlov, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Add external link to ast docs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 23 23:40:46 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Nov 2012 22:40:46 +0000
Subject: [New-bugs-announce] [issue16545] ast.FunctionDef sets a bad value
	for kw_defaults when	keyword-only arguments present
Message-ID: <1353710446.83.0.371653706627.issue16545@psf.upfronthosting.co.za>


New submission from Brett Cannon:

When there are no keyword-only arguments, the value of kw_defaults for FunctionDef is []. But when keyword-only arguments are present with no default values, it becomes [None]. That's bad as every other value in FunctionDef has a default of [] when there is nothing of value there (currently you can trust that [None] means no default value as None isn't anything in the AST).


>>> ast.dump(ast.parse('def func(*, name):pass'))
"Module(body=[FunctionDef(name='func', args=arguments(args=[], vararg=None, varargannotation=None, kwonlyargs=[arg(arg='name', annotation=None)], kwarg=None, kwargannotation=None, defaults=[], kw_defaults=[None]), body=[Pass()], decorator_list=[], returns=None)])"

>>> ast.dump(ast.parse('def func(name):pass'))
"Module(body=[FunctionDef(name='func', args=arguments(args=[arg(arg='name', annotation=None)], vararg=None, varargannotation=None, kwonlyargs=[], kwarg=None, kwargannotation=None, defaults=[], kw_defaults=[]), body=[Pass()], decorator_list=[], returns=None)])"

----------
components: Library (Lib)
keywords: 3.3regression
messages: 176260
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: ast.FunctionDef sets a bad value for kw_defaults when keyword-only arguments present
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 23 23:42:35 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Nov 2012 22:42:35 +0000
Subject: [New-bugs-announce] [issue16546] ast.YieldFrom needlessly has its
	expr value as optional
Message-ID: <1353710555.66.0.299462157611.issue16546@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The grammar guarantees that 'yield from' statements have an expression to evaluate, plus a 'yield from' without an expression makes no sense.

----------
components: Library (Lib)
messages: 176261
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: ast.YieldFrom needlessly has its expr value as optional
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 24 20:23:20 2012
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 24 Nov 2012 19:23:20 +0000
Subject: [New-bugs-announce] [issue16547] IDLE segfaults in tkinter after
	fresh file's text has	been rendered
Message-ID: <1353785000.68.0.88975991365.issue16547@psf.upfronthosting.co.za>


New submission from Lukas Lueg:

IDLE crashes due to what seems to be a use-after-free bug. Opening a file from the 'Open...'-menu leads to a segfault after the text has been rendered. It seems this can be reproduced 100% of the time if the file is big (e.g. 150kb) and the window receives events (clicks...) while the colorization is going on.

I've been able to reproduce this behaviour on MacOS 10.6 (3.2, 3.3 and 3.4a) and Windows 7 (3.3) but not on Fedora 17.

Python 3.4.0a0 (default:a728056347ec, Nov 23 2012, 19:52:20) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin




I'll attach a backtrace and a malloc_history (from a different trace). Any guidance on further debugging on this?

----------
components: IDLE
files: backtrace.txt
messages: 176307
nosy: ebfe
priority: normal
severity: normal
status: open
title: IDLE segfaults in tkinter after fresh file's text has been rendered
type: crash
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28098/backtrace.txt

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

From report at bugs.python.org  Sat Nov 24 23:04:13 2012
From: report at bugs.python.org (masterid)
Date: Sat, 24 Nov 2012 22:04:13 +0000
Subject: [New-bugs-announce] [issue16548] os.system won't run any command
	and there is no error	message when memory cannot be allocated
Message-ID: <1353794653.18.0.461930270371.issue16548@psf.upfronthosting.co.za>


New submission from masterid:

os.system won't run any command and there is no error message when memory cannot be allocated.

It looks like Python is running a command but actually nothing happens.

I used subprocess.Popen instead and found out that
OSError: [Errno 12] Cannot allocate memory

I also tried gc.collect() to release memory, but it does not work.

----------
components: Extension Modules
messages: 176321
nosy: masterid
priority: normal
severity: normal
status: open
title: os.system won't run any command and there is no error message when memory cannot be allocated
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov 25 00:19:00 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Nov 2012 23:19:00 +0000
Subject: [New-bugs-announce] [issue16549] regression: -m json.tool module
Message-ID: <1353799140.48.0.264325786565.issue16549@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Awesome json tool doesn't work anymore in Python 3 (needs tests?).
http://stackoverflow.com/questions/352098/how-to-pretty-print-json-script

C:\Python27>python -m json.tool stdlibx.json
{
    "distutils": [
        "Doc/distutils",
        "Lib/distutils",
        "Lib/test/test_distutils.py"
    ],
    "json": [
        "Doc/library/json.rst",
        "Lib/json",
        "Lib/test/json_tests",
        "Lib/test/test_json.py"
    ]
}

C:\Python33>python -m json.tool stdlibx.json
Traceback (most recent call last):
  File "C:\Python33\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python33\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "C:\Python33\lib\json\tool.py", line 37, in <module>
    main()
  File "C:\Python33\lib\json\tool.py", line 29, in main
    obj = json.load(infile)
  File "C:\Python33\lib\json\__init__.py", line 264, in load
    parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "C:\Python33\lib\json\__init__.py", line 309, in loads
    return _default_decoder.decode(s)
  File "C:\Python33\lib\json\decoder.py", line 352, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
TypeError: can't use a string pattern on a bytes-like object

----------
files: stdlibx.json
messages: 176324
nosy: techtonik
priority: normal
severity: normal
status: open
title: regression: -m json.tool module
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file28100/stdlibx.json

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

From report at bugs.python.org  Sun Nov 25 13:17:16 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Nov 2012 12:17:16 +0000
Subject: [New-bugs-announce] [issue16550] pickletools.py treats 32bit
	lengths as signed, but pickle.py as unsigned
Message-ID: <1353845836.76.0.0245039537422.issue16550@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since issue12848 some lengths in pickle module treated as unsigned, however pyckletools module treats all 32-bit lengths as signed. The proposed patch adds support of unsigned 32-bit lengths.

----------
components: Library (Lib)
files: pickletools_uint4.patch
keywords: patch
messages: 176344
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: pickletools.py treats 32bit lengths as signed, but pickle.py as unsigned
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28110/pickletools_uint4.patch

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

From report at bugs.python.org  Sun Nov 25 13:17:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Nov 2012 12:17:36 +0000
Subject: [New-bugs-announce] [issue16551] Cleanup the pure Python pickle
	implementation
Message-ID: <1353845856.16.0.80578311869.issue16551@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This issue inspired by issue12848. The proposed patch get rid of the marshal module (the struct module used instead), removes some redundant code, and changes the code to use more modern idioms.

----------
components: Library (Lib)
files: pickle_cleanup.patch
keywords: patch
messages: 176345
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Cleanup the pure Python pickle implementation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28111/pickle_cleanup.patch

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

From report at bugs.python.org  Sun Nov 25 20:47:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 25 Nov 2012 19:47:03 +0000
Subject: [New-bugs-announce] [issue16552] os.path.basename() docs should
	link to os.path.split()
Message-ID: <1353872823.17.0.910563008076.issue16552@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The docs for os.path.abspath(), os.path.basename(), and os.path.dirname():

http://docs.python.org/dev/library/os.path.html#os.path.abspath

should hyperlink to os.path.normpath() and os.path.split() as appropriate for easier navigability.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 176386
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: os.path.basename() docs should link to os.path.split()
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov 25 21:38:07 2012
From: report at bugs.python.org (yop)
Date: Sun, 25 Nov 2012 20:38:07 +0000
Subject: [New-bugs-announce] [issue16553] named kwd form of OrderedDict ctor
	yield random key order
Message-ID: <1353875887.57.0.785753219375.issue16553@psf.upfronthosting.co.za>


New submission from yop:

tested on 2.7.3 with -R or stock 3.3, the following:

OrderedDict(foo=0,bar=0).keys()

is nondeterminstic as a result of hash randomization. 
probably since **kwds creates a dict.

what is the proper idiom for constructing an ordered-key
dictionary other then (ugly, verbose) piecemeal insertion?

----------
components: Library (Lib)
messages: 176387
nosy: benjamin.peterson, rhettinger, yop
priority: normal
severity: normal
status: open
title: named kwd form of OrderedDict ctor yield random key order
versions: 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/issue16553>
_______________________________________

From report at bugs.python.org  Sun Nov 25 23:15:40 2012
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 25 Nov 2012 22:15:40 +0000
Subject: [New-bugs-announce] [issue16554] The description of the argument of
	MAKE_FUNCTION and	MAKE_CLOSURE is incorrect
Message-ID: <1353881740.2.0.222803994959.issue16554@psf.upfronthosting.co.za>


New submission from Daniel Urban:

The description of the argument of the MAKE_FUNCTION and MAKE_CLOSURE opcodes in the documentation of the dis module is incorrect. Patch attached.

----------
assignee: docs at python
components: Documentation
files: make_function_closure.patch
keywords: needs review, patch
messages: 176390
nosy: daniel.urban, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: The description of the argument of MAKE_FUNCTION and MAKE_CLOSURE is incorrect
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28125/make_function_closure.patch

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

From report at bugs.python.org  Mon Nov 26 02:24:47 2012
From: report at bugs.python.org (=?utf-8?q?Leiser_Fern=C3=A1ndez_Gallo?=)
Date: Mon, 26 Nov 2012 01:24:47 +0000
Subject: [New-bugs-announce] [issue16555] Add es_cu to locale library.
Message-ID: <1353893087.2.0.125230690111.issue16555@psf.upfronthosting.co.za>


Changes by Leiser Fern?ndez Gallo <leiserfg at gmail.com>:


----------
components: Library (Lib)
nosy: Leiser.Fern?ndez.Gallo
priority: normal
severity: normal
status: open
title: Add es_cu to locale library.
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 26 05:11:33 2012
From: report at bugs.python.org (Taavi Burns)
Date: Mon, 26 Nov 2012 04:11:33 +0000
Subject: [New-bugs-announce] [issue16556] Update string.Formatter.vformat
	documentation to say	"**kwargs"
Message-ID: <1353903093.51.0.301727912961.issue16556@psf.upfronthosting.co.za>


New submission from Taavi Burns:

The documentation says "**kwds" instead of "**kwargs", which is what the function signature uses.

I noticed some other (internally-consistent) occurrences in string.rst. Is there any interest in replacing "**kwds" generally with "**kwargs"? It looks like 327 vs 932 ratio in the docs, and closer to 1185 vs 2361 in the source tree as a whole.

Thanks!

----------
assignee: docs at python
components: Documentation
files: kwds_kwargs.diff
keywords: patch
messages: 176393
nosy: docs at python, taavi-burns
priority: normal
severity: normal
status: open
title: Update string.Formatter.vformat documentation to say "**kwargs"
type: enhancement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file28127/kwds_kwargs.diff

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

From report at bugs.python.org  Mon Nov 26 13:07:18 2012
From: report at bugs.python.org (Masami HIRATA)
Date: Mon, 26 Nov 2012 12:07:18 +0000
Subject: [New-bugs-announce] [issue16557] PEP 380 isn't reflected in the
	Functional Programming	HOWTO
Message-ID: <1353931638.82.0.313274646017.issue16557@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

Although PEP 380 says:
> 2. In a generator, the statement ::
> 
>     return value
> 
> is semantically equivalent to ::
> 
>     raise StopIteration(value)

Functional Programming HOWTO (Doc/howto/functional.rst) says:
> ``return`` with a value, such as ``return 5``, is a syntax error inside a generator function.

----------
assignee: docs at python
components: Documentation
messages: 176407
nosy: docs at python, msmhrt
priority: normal
severity: normal
status: open
title: PEP 380 isn't reflected in the Functional Programming HOWTO
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 26 15:50:16 2012
From: report at bugs.python.org (Brian Candler)
Date: Mon, 26 Nov 2012 14:50:16 +0000
Subject: [New-bugs-announce] [issue16558] multiprocessing fails to raise
	exception with parameters
Message-ID: <1353941416.92.0.941736825081.issue16558@psf.upfronthosting.co.za>


New submission from Brian Candler:

Probably best demonstrated by example.

~~~~~~~~~~~~~~~~
import multiprocessing

class Myerror(ValueError):
    def __init__(self,a):
        self.a = a
    def __str__(self):
        return repr(self.a)
        
def foo(arg):
    raise Myerror(arg)
    
#foo("1")   #<= this works fine, raises exception as expected

#But this breaks:
pool = multiprocessing.Pool(2)
pool.map(foo, ["1","2","3"])
~~~~~~~~~~~~~~~~

The result seen:

~~~~~~~~~~~~~~~~
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 353, in _handle_results
    task = get()
TypeError: ('__init__() takes exactly 2 arguments (1 given)', <class '__main__.Myerror'>, ())
~~~~~~~~~~~~~~~~

At this point the application hangs. Worse: pressing ctrl-C shows a traceback and KeyboardInterrupt, but the worker keeps getting restarted, so it's impossible to stop. You have to go to another shell and do somthing like

    killall python

to terminate the program.

A real-world example (which caused me to track this down) is a CalledProcessError raised by subprocess.check_call

~~~~~~~~~~~~~~~~
import multiprocessing
import subprocess

def foo(arg):
    subprocess.check_call("nonexistent", shell=True)
    #raise subprocess.CalledProcessError(127, "nonexistent")

pool = multiprocessing.Pool(2)
pool.map(foo, ["1","2","3"])
~~~~~~~~~~~~~~~~

which fails in the same way:

~~~~~~~~~~~~~~~~
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 353, in _handle_results
    task = get()
TypeError: ('__init__() takes at least 3 arguments (1 given)', <class 'subprocess.CalledProcessError'>, ())
~~~~~~~~~~~~~~~~

Behaviour tested on:
python 2.7.3 on Ubuntu 12.04
python 2.7.1 on OSX 10.7.5

Workaround: re-raise a parameter-less exception instead.

    try:
        ...
    except Exception as e:
        raise RuntimeError

----------
components: Library (Lib)
messages: 176416
nosy: candlerb
priority: normal
severity: normal
status: open
title: multiprocessing fails to raise exception with parameters
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 26 16:40:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Nov 2012 15:40:14 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue16559=5D_Update_JSON=C2=A0t?=
	=?utf-8?q?ests?=
Message-ID: <1353944414.37.0.762531579456.issue16559@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The json module tests contain testcases from the official testsuite (http://json.org/JSON_checker/test.zip). At the moment these testcases differ slightly and the proposed patch updates testcases to conform with the current official testsuite (which was changed 2007-10-05 last time).

I think tests updating can be applied to old Python versions.

----------
components: Tests
files: json_tests.patch
keywords: patch
messages: 176421
nosy: ezio.melotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Update JSON?tests
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28129/json_tests.patch

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

From report at bugs.python.org  Mon Nov 26 18:12:00 2012
From: report at bugs.python.org (Zdenek Pavlas)
Date: Mon, 26 Nov 2012 17:12:00 +0000
Subject: [New-bugs-announce] [issue16560] Python sighandlers delayed for no
	reason
Message-ID: <1353949920.26.0.627240187448.issue16560@psf.upfronthosting.co.za>


New submission from Zdenek Pavlas:

Quoting from "signal" module docs:

# Although Python signal handlers are called asynchronously as far as the Python user is concerned, they can only occur between the ?atomic? instructions of the Python interpreter.

Yes, that's reasonable.

# This means that signals arriving during long calculations implemented purely in C (such as regular expression matches on large bodies of text) may be delayed for an arbitrary amount of time.

IMO, A does not imply B.  Long computation in C with GIL released does not need to be atomic, as it happens "between" Python instructions.  

The thunk that's called asynchronously should preempt the C computation and issue a Python callback when possible.  Otherwise, Python handlers are useless when interfacing C code.

----------
components: Interpreter Core
files: trip-signal.patch
keywords: patch
messages: 176428
nosy: zdenek.pavlas
priority: normal
severity: normal
status: open
title: Python sighandlers delayed for no reason
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28133/trip-signal.patch

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

From report at bugs.python.org  Mon Nov 26 21:02:33 2012
From: report at bugs.python.org (Redoute)
Date: Mon, 26 Nov 2012 20:02:33 +0000
Subject: [New-bugs-announce] [issue16561] Windows installer doesn't use UAC,
	then crashes
Message-ID: <1353960153.53.0.844150162265.issue16561@psf.upfronthosting.co.za>


New submission from Redoute:

Windows installers crash without useful explanation, when Python is located in /Program Files/Python27 and the installer is started without admin rights/UAC. I experienced this with Windows 8 and installers for packages pandas and rtree.

a) show error message instead of crash

As I don't use distutils for packaging, I am just guessing it would make sense to:

b) let bdist_wininst --user-access-control default to 'auto'

----------
assignee: eric.araujo
components: Distutils
messages: 176449
nosy: Redoute, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Windows installer doesn't use UAC, then crashes
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 26 21:26:14 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Nov 2012 20:26:14 +0000
Subject: [New-bugs-announce] [issue16562] Optimize dict equality test
Message-ID: <1353961574.84.0.437047945536.issue16562@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The code for dict_equal() in Objects/dictobject.c currently loops over the key/value pairs in self and uses PyDict_GetItem() to check for the corresponding key/value pair in the other dictionary.  This causes an unnecessary call to PyObject_Hash().

Instead, the code should loop over the key/value/hash triplets in self and do a direct lookup in the other dictionary with " ep = (otherdict->ma_lookup)(otherdict, key, hash)".   The reuses the known hash value for the key; thereby avoiding the potentially slow call to PyObject_Hash().

See _PyDict_Contains() for an example of how to do a lookup when the hash value is already known.

Note, the optimized path should be used only when PyDict_CheckExact() is true.

----------
components: Interpreter Core
keywords: easy
messages: 176453
nosy: rhettinger
priority: low
severity: normal
status: open
title: Optimize dict equality test
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 27 01:07:43 2012
From: report at bugs.python.org (L. Peter Deutsch)
Date: Tue, 27 Nov 2012 00:07:43 +0000
Subject: [New-bugs-announce] [issue16563] re.match loops forever on simple
	regexp
Message-ID: <1353974863.42.0.0697393533738.issue16563@psf.upfronthosting.co.za>


New submission from L. Peter Deutsch:

I've read a number of reports of exponential-time regexp matching, but this regexp uses no unusual features, requires no backtracking, and only loops "forever" on certain input strings.

I listed the Python version # as 2.6; I actually observed the behavior in 2.5.1 and 2.5.2, but I'm almost certain it's still there, because I saw the same behavior in a very recent build of Google's V8 interpreter, which I believe uses the same regexp engine.

Here's the test case:

import re
re_utf8 = r'^([\x00-\x7f]+|[\xc0-\xdf][\x80-\xbf]|[\xe0-\xef][\x80-\xbf][\x80-\xbf]|[\xf0-\xf7][\x80-\xbf][\x80-\xbf][\x80-\xbf])*$'
s = "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x14\x00\x00\x00\x01\x00\x00,`\x00\x00\x004\x00\x01\x8d"
print re.match(re_utf8, s)

If you pass s[0:34] or s[34:35] as the argument of re.match, it returns the correct answer, but the code above loops apparently forever.

----------
components: Regular Expressions
messages: 176458
nosy: ezio.melotti, lpd, mrabarnett
priority: normal
severity: normal
status: open
title: re.match loops forever on simple regexp
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Nov 27 15:38:50 2012
From: report at bugs.python.org (Alexander Kruppa)
Date: Tue, 27 Nov 2012 14:38:50 +0000
Subject: [New-bugs-announce] [issue16564] email.generator.BytesGenerator
	fails with bytes payload
Message-ID: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>


New submission from Alexander Kruppa:

I'm trying to use the email.* functions to craft HTTP POST data for file upload. Trying something like

filedata = open("data", "rb").read()
postdata = MIMEMultipart()
fileattachment = MIMEApplication(filedata, _encoder=email.encoders.encode_noop)
postdata.attach(fileattachment)
fp = BytesIO()
g = BytesGenerator(fp)
g.flatten(postdata, unixfrom=False)

fails with 

Traceback (most recent call last):
  File "./minetest.py", line 30, in <module>
    g.flatten(postdata, unixfrom=False)
  File "/usr/lib/python3.2/email/generator.py", line 91, in flatten
    self._write(msg)
  File "/usr/lib/python3.2/email/generator.py", line 137, in _write
    self._dispatch(msg)
  File "/usr/lib/python3.2/email/generator.py", line 163, in _dispatch
    meth(msg)
  File "/usr/lib/python3.2/email/generator.py", line 224, in _handle_multipart
    g.flatten(part, unixfrom=False, linesep=self._NL)
  File "/usr/lib/python3.2/email/generator.py", line 91, in flatten
    self._write(msg)
  File "/usr/lib/python3.2/email/generator.py", line 137, in _write
    self._dispatch(msg)
  File "/usr/lib/python3.2/email/generator.py", line 163, in _dispatch
    meth(msg)
  File "/usr/lib/python3.2/email/generator.py", line 192, in _handle_text
    raise TypeError('string payload expected: %s' % type(payload))
TypeError: string payload expected: <class 'bytes'>

This is because BytesGenerator._handle_text() expects str payload in which byte values that are non-printable in ASCII have been replaced by surrogates. The example above creates a bytes payload, however, for which super(BytesGenerator,self)._handle_text(msg) = Generator._handle_text(msg) throws the exception.

Note that using any email.encoders other than encode_noop does not really fit the HTTP POST bill, as those define a Content-Transfer-Encoding which HTTP does not know.

It would seem better to me to let BytesGenerator accept a bytes payload and just copy that to the output, rather than making the application encode the bytes as a string, hopefully in a way that s.encode('ascii', 'surrogateescape') can invert.

E.g., a workaround class I use now does

class FixedBytesGenerator(BytesGenerator):
    def _handle_bytes(self, msg):  
        payload = msg.get_payload()
        if payload is None:
            return
        if isinstance(payload, bytes):
            self._fp.write(payload)   
        elif isinstance(payload, str):
            super(FixedBytesGenerator,self)._handle_text(msg)
        else:
            # Payload is neither bytes not string - this can't be right
            raise TypeError('bytes or str payload expected: %s' % type(payload))
    _writeBody = _handle_bytes

----------
components: Library (Lib)
messages: 176476
nosy: Alexander.Kruppa
priority: normal
severity: normal
status: open
title: email.generator.BytesGenerator fails with bytes payload
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 27 21:37:34 2012
From: report at bugs.python.org (Felipe Cruz)
Date: Tue, 27 Nov 2012 20:37:34 +0000
Subject: [New-bugs-announce] [issue16565] Increase Py_AddPendingCall array
	size
Message-ID: <1354048654.58.0.545467206879.issue16565@psf.upfronthosting.co.za>


New submission from Felipe Cruz:

Current pending calls limit is too small and it can be easily reached in very intensive async file io applications.

There is a little hack in pyaio[1] which sleeps if Py_AddPendingCall returns < 0 but It's not totally clear to me why the size of pendind calls array is only 32.


[1] https://github.com/felipecruz/pyaio

----------
components: IO
messages: 176491
nosy: felipecruz
priority: normal
severity: normal
status: open
title: Increase Py_AddPendingCall array size
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Nov 27 22:29:49 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 27 Nov 2012 21:29:49 +0000
Subject: [New-bugs-announce] [issue16566] Structure._anonymous_ should not
	allow strings
Message-ID: <1354051789.98.0.293941478089.issue16566@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/2/library/ctypes.html#ctypes.Structure._anonymous_

  "An optional sequence that lists the names of unnamed (anonymous) fields".

If you feed it a string, such as _offset, it will print a very interesting error:

...
  File "C:\roundup\.\roundup\backends\portalocker.py", line 70, in <module>
    class A_OFFSET_UNION(Union):
AttributeError: type object '_OFFSET_UNION' has no attribute '_'

Considering complexity that ctypes already has, the simple check that _anonymous_ is a sequence (and not a string) will make our lifes easier.

----------
components: ctypes
messages: 176494
nosy: techtonik
priority: normal
severity: normal
status: open
title: Structure._anonymous_ should not allow strings
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 28 08:37:22 2012
From: report at bugs.python.org (Erik VanderWerf)
Date: Wed, 28 Nov 2012 07:37:22 +0000
Subject: [New-bugs-announce] [issue16567] Implementing .= for variable
	operator
Message-ID: <1354088242.01.0.122460016578.issue16567@psf.upfronthosting.co.za>


New submission from Erik VanderWerf:

I don't know if this has been suggested before, none of my searches returned anything. Sorry if it has been rejected already.

Anyone who has used Python at least a little bit will know that you can use +=, -=, *=, and /= to apply a change to a variable and store it in the same variable in one step. (a = a + 1) == (a += 1)

Would it be possible to add a fifth operator, .= (period-equals) to apply a method to a variable in one step? ex:

>> a = "SPAM"
>> a .= lower()
>> a
'spam'

It would make code look a lot better, and easier to write for any longer-named variables. I can see where passing a method of an object by itself would cause an error, but might it be possible for the .= to override this?

----------
components: None
messages: 176519
nosy: yos233
priority: normal
severity: normal
status: open
title: Implementing .= for variable operator
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 28 10:03:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 09:03:32 +0000
Subject: [New-bugs-announce] [issue16568] allow constructors to be
	documented separately from class
Message-ID: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to settle on and provide a way to document the constructor of a class separately from the overall summary/description of a class.

This is something that Ezio, Nick, and I discussed briefly on IRC a few hours ago.  We all see the value in it.

Currently, Sphinx's "class" directive is used in many places to document the constructor of a class.  One drawback of this approach is that linking to the class using the :class: role links to the constructor as opposed to the class summary.  As a result, in many cases the class description needs to be added before the class directive, and a second link needs to be created and used for the overall description.

One way to address this would be to create a new "constructor" directive similar to directives like method, classmethod, and staticmethod.  The constructor documentation could then be hyperlinked to using a new :constructor: role (or perhaps :ctor: to go with the pattern of 4-letter roles).  The class summary could then go immediately after the class directive, with the constructor directive following, as follows:

.. class:: Foo

   Description of Foo.

   .. constructor:: Foo(bar=1)
   
      Return a Foo.

This could render as--

class **Foo**

   Description of Foo.
   
   *constructor* **Foo**(bar=1)

      Return a Foo.

It is possible that something similar could be achieved by abusing the method directive for constructors and linking to them using :meth:`~Foo.Foo`, but that wouldn't be ideal in a few respects.

Nick also raised a related issue for base classes, etc.  I will let him speak to that issue, which might be best as part of another new issue.

----------
assignee: docs at python
components: Documentation
messages: 176524
nosy: chris.jerdonek, docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: allow constructors to be documented separately from class
type: enhancement

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

From report at bugs.python.org  Wed Nov 28 15:21:51 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Nov 2012 14:21:51 +0000
Subject: [New-bugs-announce] [issue16569] Preventing errors of simultaneous
	access in zipfile
Message-ID: <1354112511.94.0.436567820333.issue16569@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

If the ZipFile was created by passing in a file-like object as the first argument to the constructor, then simultaneous reading or writing of different file results in an non-consistent state. There is a warning about this in the documentation. The proposed patch forces this condition, raising the early exception if you attempt to simultaneously access.

I'm not sure whether it's worth apply to older versions.

----------
components: Library (Lib)
files: zipfile_simultaneous.patch
keywords: patch
messages: 176544
nosy: alanmcintyre, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Preventing errors of simultaneous access in zipfile
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28147/zipfile_simultaneous.patch

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

From report at bugs.python.org  Wed Nov 28 15:46:11 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 28 Nov 2012 14:46:11 +0000
Subject: [New-bugs-announce] [issue16570] Absolute imports fail to take full
	path into account?
Message-ID: <1354113971.91.0.733086645605.issue16570@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman:

This seems confusing:

djc at enrai test $ ls -lR
.:
total 0
drwxr-xr-x 4 djc users 160 Nov 28 15:35 pkg

./pkg:
total 4
-rw-r--r-- 1 djc users  39 Nov 28 15:37 http.py
-rw-r--r-- 1 djc users   0 Nov 28 15:34 __init__.py
drwxr-xr-x 3 djc users 136 Nov 28 15:40 tests

./pkg/tests:
total 8
-rw-r--r-- 1 djc users  21 Nov 28 15:37 http.py
-rw-r--r-- 1 djc users  27 Nov 28 15:40 __init__.py

djc at enrai test $ cat pkg/__init__.py
djc at enrai test $ cat pkg/http.py
from http.client import HTTPConnection
djc at enrai test $ cat pkg/tests/__init__.py
from pkg.tests import http
djc at enrai test $ cat pkg/tests/http.py
from pkg import http
djc at enrai test $ python3
Python 3.2.3 (default, May 28 2012, 09:27:08)
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg import http
>>>
djc at enrai test $ python3
Python 3.2.3 (default, May 28 2012, 09:27:08)
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg.tests import http
>>>
djc at enrai test $ PYTHONPATH=. python3 pkg/tests/__init__.py
Traceback (most recent call last):
  File "pkg/tests/__init__.py", line 1, in <module>
    from pkg.tests import http
  File "/home/djc/src/test/pkg/tests/__init__.py", line 1, in <module>
    from pkg.tests import http
  File "/home/djc/src/test/pkg/tests/http.py", line 1, in <module>
    from pkg import http
  File "/home/djc/src/test/pkg/http.py", line 1, in <module>
    from http.client import HTTPConnection
  File "/home/djc/src/test/pkg/tests/http.py", line 1, in <module>
    from pkg import http
ImportError: cannot import name http

----------
components: Interpreter Core
messages: 176545
nosy: brett.cannon, djc, ncoghlan
priority: normal
severity: normal
status: open
title: Absolute imports fail to take full path into account?
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov 28 17:02:00 2012
From: report at bugs.python.org (Brian Berard)
Date: Wed, 28 Nov 2012 16:02:00 +0000
Subject: [New-bugs-announce] [issue16571] Iterating over
	inconsistently-indented code block causes	execution of code
	only on last iteration of loop
Message-ID: <1354118520.63.0.69805798217.issue16571@psf.upfronthosting.co.za>


New submission from Brian Berard:

When a loop (for loop in this case) contains multiple lines of code, if the lines are inconsistently indented, the for loop will only execute those lines on the final pass through the loop with no type of warning regarding indentation error. 

Ex. 

for i in range(0,10):
    print "I will print on every iteration: %d" % i  # TAB indented
    print "I will only print on the final iteration: %d" % i # 4 spaces

----------
components: Interpreter Core
files: python_test.py
messages: 176551
nosy: dimitriprosser
priority: normal
severity: normal
status: open
title: Iterating over inconsistently-indented code block causes execution of code only on last iteration of loop
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28149/python_test.py

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

From report at bugs.python.org  Wed Nov 28 22:35:08 2012
From: report at bugs.python.org (Thomas Chiroux)
Date: Wed, 28 Nov 2012 21:35:08 +0000
Subject: [New-bugs-announce] [issue16572] Bad multi-inheritance support in
	some libs like	threading or multiprocessing
Message-ID: <1354138508.41.0.9459136379.issue16572@psf.upfronthosting.co.za>


New submission from Thomas Chiroux:

when using multi-inheritance and super() in __init__(), super() tries to run each constructor once.
For this to work correctly, it is needed to call super() in each constructor, including for Classes directly inherited from object.

The sample below does not execute correctly because threading.Thread constructor does not call super()
(and because Thread inherit from _Verbose, _Verbose should also call super() )

Sample:
from threading import Thread


class Foo(object):
    def __init__(self):
        super(Foo, self).__init__()
        print('Foo constructor')
        self.param1 = 'foo param1'


class Bar(Thread, Foo):
    def __init__(self):
        super(Bar, self).__init__()
        print('Bar constructor')
        self.another_param1 = "bar another_param1"

    def run(self):
        print("Running (%s - %s)" % (self.another_param1, self.param1))


if __name__ == '__main__':
    threads = []
    for i in range(1, 10):
        thread = Bar()
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()


This sample work by simply inverting Thread and Foo :

(...)
class Bar(Foo, Thread):
(...)

The sample is about threading.Thread, but it's also the same for multiprocessing.Process, and maybe for other modules in stdlib.

attached is a proposed path for threading.Tread in 2.7

I've tested the issue and have the same behavior in 2.7 and in 3.3

----------
components: Library (Lib)
files: diff_threading.py_2.7.patch
keywords: patch
messages: 176576
nosy: thomas.chiroux
priority: normal
severity: normal
status: open
title: Bad multi-inheritance support in some libs like threading or multiprocessing
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file28150/diff_threading.py_2.7.patch

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

From report at bugs.python.org  Thu Nov 29 00:58:00 2012
From: report at bugs.python.org (Jonathan Kotta)
Date: Wed, 28 Nov 2012 23:58:00 +0000
Subject: [New-bugs-announce] [issue16573] 2to3 should treat enumerate like
	sorted for zip, map, filter, dict, xrange
Message-ID: <1354147080.22.0.730661642804.issue16573@psf.upfronthosting.co.za>


New submission from Jonathan Kotta:

enumerate() is a "consuming_call", as defined in fixer_util.py, because it takes an iterable (not necessarily a collection).  Therefore whenever we have something like enumerate(zip(...)), we don't need to replace it with enumerate(list(zip(...))) in 2to3, because enumerate doesn't care that zip no longer returns a list.

Patch attached.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: enumerate.patch
keywords: patch
messages: 176590
nosy: jpkotta
priority: normal
severity: normal
status: open
title: 2to3 should treat enumerate like sorted for zip, map, filter, dict, xrange
type: behavior
Added file: http://bugs.python.org/file28152/enumerate.patch

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

From report at bugs.python.org  Thu Nov 29 01:56:55 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 00:56:55 +0000
Subject: [New-bugs-announce] [issue16574] clarify policy on updates to final
	peps
Message-ID: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to clarify the policy in PEP 1 regarding non-substantive changes to PEPs in the Final state (minor clarifications, rephrasings, etc).

Currently, PEP 1 says, "In general, Standards track PEPs are no longer modified after they have reached the Final state."

(from http://www.python.org/dev/peps/pep-0001/#pep-maintenance )

However, others have pointed out that minor clarifications and rephrasings are in fact allowed:

http://bugs.python.org/issue15990#msg176575

The updated wording should also state the policy or process regarding such changes (who is allowed to make them and whether and from whom approval is needed to make such changes, etc).

----------
assignee: docs at python
components: Documentation
messages: 176598
nosy: barry, chris.jerdonek, docs at python, eric.araujo, ezio.melotti, goodger, ncoghlan
priority: normal
severity: normal
status: open
title: clarify policy on updates to final peps
type: enhancement

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

From report at bugs.python.org  Thu Nov 29 05:24:04 2012
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 29 Nov 2012 04:24:04 +0000
Subject: [New-bugs-announce] [issue16575] ctypes: unions as arguments
Message-ID: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>


New submission from Armin Rigo:

ctypes pretends to support passing arguments to C functions that are unions (not pointers to unions), but that's a lie.  In fact, the underlying libffi does not support it.  The attached example misbehaves on Linux x86-64.

----------
components: ctypes
files: test184_lib.tgz
messages: 176627
nosy: arigo
priority: normal
severity: normal
status: open
title: ctypes: unions as arguments
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file28155/test184_lib.tgz

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

From report at bugs.python.org  Thu Nov 29 05:53:32 2012
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 29 Nov 2012 04:53:32 +0000
Subject: [New-bugs-announce] [issue16576] ctypes: structure with bitfields
	as argument
Message-ID: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>


New submission from Armin Rigo:

ctypes pretends to support passing arguments to C functions that are structures containing bitfields, or at least does not explicitly forbid it.  But doing so results in misbehavior or segfaults in libffi itself.  Indeed, libffi has no support for this, and ctypes just describes a field like "int x:1;" as "int x;".  The attached example segfaults on Linux x86-64.

----------
components: ctypes
files: test185_lib.tgz
messages: 176629
nosy: arigo
priority: normal
severity: normal
status: open
title: ctypes: structure with bitfields as argument
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file28156/test185_lib.tgz

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

From report at bugs.python.org  Thu Nov 29 13:51:48 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 29 Nov 2012 12:51:48 +0000
Subject: [New-bugs-announce] [issue16577]
	Suspect	test.test_codeccallbacks.test_mutatingdecodehandler
Message-ID: <1354193508.42.0.911887136635.issue16577@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

The test created by 504084c04ac0 passes for bad reasons, at least for the second part:
- "test.mutating" error handler is never used.
- If I replace the last line of the test, it still passes, but the TypeError is raised by exc.object[:] = b"" (bytes are not mutable!)

I suggest to revert this old change completely. The premises ("the decoder might use memory that's no longer in use") are no longer true.

----------
components: Unicode
messages: 176645
nosy: amaury.forgeotdarc, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Suspect test.test_codeccallbacks.test_mutatingdecodehandler

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

From report at bugs.python.org  Thu Nov 29 18:16:26 2012
From: report at bugs.python.org (=?utf-8?q?Gabriel_Rodr=C3=ADguez_Alberich?=)
Date: Thu, 29 Nov 2012 17:16:26 +0000
Subject: [New-bugs-announce] [issue16578] Regular expressions with empty
	named groups breaks	isname check
Message-ID: <1354209386.4.0.0657079011573.issue16578@psf.upfronthosting.co.za>


New submission from Gabriel Rodr?guez Alberich:

>>> import re
>>> re.compile("(?P<>)")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/re.py", line 190, in compile
    return _compile(pattern, flags)
  File "/usr/lib/python2.7/re.py", line 240, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/usr/lib/python2.7/sre_compile.py", line 500, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/lib/python2.7/sre_parse.py", line 673, in parse
    p = _parse_sub(source, pattern, 0)
  File "/usr/lib/python2.7/sre_parse.py", line 308, in _parse_sub
    itemsappend(_parse(source, state))
  File "/usr/lib/python2.7/sre_parse.py", line 544, in _parse
    if not isname(name):
  File "/usr/lib/python2.7/sre_parse.py", line 218, in isname
    if not isident(name[0]):
IndexError: string index out of range

isname() shouldn't be blindly accessing name[0].

----------
components: Regular Expressions
messages: 176664
nosy: Gabriel.Rodr?guez.Alberich, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regular expressions with empty named groups breaks isname check
type: crash
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Nov 29 18:45:45 2012
From: report at bugs.python.org (Alex stein)
Date: Thu, 29 Nov 2012 17:45:45 +0000
Subject: [New-bugs-announce] [issue16579] .pyw disturb multiprocessing
	behavior
Message-ID: <1354211145.86.0.68056435154.issue16579@psf.upfronthosting.co.za>


New submission from Alex stein:

I made a software synchronizing every 2 seconds files from the network through SSH using Paramiko library.

The software works normally on Linux and Windows 32 and 64 bits (never tried on Mac).

At the office, I use Windows XP 32 bits:
By comfort I made a link on the desktop pointing to the __init__.py file. I had no problems. Then I switched the extension file to .pyw.
The files are not synchronized every 2 seconds anymore but typically some time after 5 minutes. At the restart the files are immediately detected and synchronized.

The software runs multiples threads and processes.

I tryed to update Python interpreter but the bug remains.

----------
components: Windows
messages: 176667
nosy: Alex.stein
priority: normal
severity: normal
status: open
title: .pyw disturb multiprocessing behavior
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 29 20:25:09 2012
From: report at bugs.python.org (Paddy McCarthy)
Date: Thu, 29 Nov 2012 19:25:09 +0000
Subject: [New-bugs-announce] [issue16580] Add examples to int.to_bytres and
	int.from_bytes
Message-ID: <1354217109.61.0.534443148437.issue16580@psf.upfronthosting.co.za>


New submission from Paddy McCarthy:

http://docs.python.org/3.3/library/stdtypes.html?highlight=to_bytes#int.to_bytes and http://docs.python.org/3.3/library/stdtypes.html?highlight=to_bytes#int.to_bytes would benefit from an example showing what they do based on simpler coding.

I have such an example that I wrote here: http://paddy3118.blogspot.co.uk/2012/11/some-identities-for-python-inttobytes.html that you can use.

I.e.

>>> n = 2491969579123783355964723219455906992268673266682165637887
>>> length = 25
>>> n2bytesbig    = n.to_bytes(length, 'big')
>>> n2byteslittle = n.to_bytes(length, 'little')
>>> assert n2bytesbig    == bytes( (n >> i*8) & 0xff for i in reversed(range(length)))
>>> assert n2byteslittle == bytes( (n >> i*8) & 0xff for i in range(length))
>>> assert n == sum( n2bytesbig[::-1][i] << i*8 for i in range(length) )
>>> assert n == sum( n2byteslittle[i]    << i*8 for i in range(length) )
>>> assert n == int.from_bytes(n2bytesbig,    byteorder='big')
>>> assert n == int.from_bytes(n2byteslittle, byteorder='little')
>>>

----------
assignee: docs at python
components: Documentation
messages: 176671
nosy: docs at python, paddy3118
priority: normal
severity: normal
status: open
title: Add examples to int.to_bytres and int.from_bytes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 30 03:00:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 30 Nov 2012 02:00:10 +0000
Subject: [New-bugs-announce] [issue16581] define "PEP editor" in PEP 1
Message-ID: <1354240810.61.0.280116049987.issue16581@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to define "PEP editor" (or "PEP editors") in PEP 1 before it is used in the document and to provide certain clarifying information.

In particular, PEP 1 should say whether editorship is an invitation-only status and/or how one becomes a PEP editor.  It would also be good if it said (for transparency) how to go about seeing the current list of editors.

There is also inconsistent singular/plural usage that I think would be good to clear up.  Currently, in many places PEP 1 says "the PEP editor" (singular), so it's not clear if each PEP has its own editor, if there is a single PEP editor for all PEPs at any one time, or if it simply means "the PEP editor that happens to reply to an e-mail to peps at python.org".

PEP 0 also has this issue because its introduction says, "[This] PEP contains the index of all Python Enhancement Proposals, known as PEPs.  PEP numbers are assigned by the PEP Editor, and once assigned are never changed."

----------
assignee: docs at python
components: Documentation
messages: 176678
nosy: Jeremy.Hylton, barry, chris.jerdonek, docs at python, goodger, ncoghlan
priority: normal
severity: normal
status: open
title: define "PEP editor" in PEP 1
type: enhancement

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

From report at bugs.python.org  Fri Nov 30 19:03:53 2012
From: report at bugs.python.org (Abraham Karplus)
Date: Fri, 30 Nov 2012 18:03:53 +0000
Subject: [New-bugs-announce] [issue16582] Tkinter calls SystemExit with
	string
Message-ID: <1354298633.36.0.337905476432.issue16582@psf.upfronthosting.co.za>


New submission from Abraham Karplus:

Exiting a Tkinter application normally results in printing '0' and exiting with error code 1. This is a result of Tkinter's _exit function, whose default argument for code is the string '0'. It then calls SystemExit with the code argument. However, according to the SystemExit documentation "if [the argument] has another type (such as a string), the object?s value is printed and the exit status is one". A simple fix for this would be to change the Tkinter _exit function to convert code to an int before passing it to SystemExit.

----------
components: Tkinter
messages: 176696
nosy: Abraham Karplus
priority: normal
severity: normal
status: open
title: Tkinter calls SystemExit with string
type: behavior
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/issue16582>
_______________________________________

From report at bugs.python.org  Fri Nov 30 19:14:43 2012
From: report at bugs.python.org (Abraham Karplus)
Date: Fri, 30 Nov 2012 18:14:43 +0000
Subject: [New-bugs-announce] [issue16583] Tkinter nested SystemExit
Message-ID: <1354299283.97.0.595004930549.issue16583@psf.upfronthosting.co.za>


New submission from Abraham Karplus:

When a callback function gets called from Tkinter and raises SystemExit (either directly or through sys.exit), a new SystemExit exception is raised with the original exception as its code field, such as
SystemExit(SystemExit(),)
This is due to a bug in Tkinter's CallWrapper, where it has
except SystemExit as msg:
    raise SystemExit(msg)
which since msg is a SystemExit instance, creates the nesting. This bug did not exist in Python 2 because there the code was
except SystemExit, msg:
    raise SystemExit, msg
and this raises msg, as it already is a SystemExit instance. I suspect the bug was introduced by using the 2to3 tool, as it will do the conversion. If so, this is a bug in 2to3, as the two snippets are not functionally identical.

----------
components: Tkinter
messages: 176698
nosy: Abraham Karplus
priority: normal
severity: normal
status: open
title: Tkinter nested SystemExit
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/issue16583>
_______________________________________

From report at bugs.python.org  Fri Nov 30 19:27:20 2012
From: report at bugs.python.org (Till Maas)
Date: Fri, 30 Nov 2012 18:27:20 +0000
Subject: [New-bugs-announce] [issue16584] unhandled IOError
	filecmp.cmpfiles() if file not readable
Message-ID: <1354300040.38.0.588944499058.issue16584@psf.upfronthosting.co.za>


New submission from Till Maas:

If filecmp is used with files that the user is not allowed to read, it creates an IOError exception instead of returning the file's name as an file that could not compared. The documentation says:

http://docs.python.org/2/library/filecmp.html
Returns three lists of file names: match, mismatch, errors. [...] errors lists the names of files which could not be compared. Files are listed in errors if they don?t exist in one of the directories, the user lacks permission to read them or if the comparison could not be done for some other reason.

The attached file fails with an IOError:
$ python filecmp-minimal.py 
Traceback (most recent call last):
  File "filecmp-minimal.py", line 21, in <module>
    print filecmp.cmpfiles(join(t, "a"), join(t, "b"), ["testfile"], shallow=False)
  File "/usr/lib64/python2.7/filecmp.py", line 258, in cmpfiles
    res[_cmp(ax, bx, shallow)].append(x)
  File "/usr/lib64/python2.7/filecmp.py", line 270, in _cmp
    return not abs(cmp(a, b, sh))
  File "/usr/lib64/python2.7/filecmp.py", line 53, in cmp
    outcome = _do_cmp(f1, f2)
  File "/usr/lib64/python2.7/filecmp.py", line 66, in _do_cmp
    with open(f1, 'rb') as fp1, open(f2, 'rb') as fp2:
IOError: [Errno 13] Permission denied: '/tmp/tmpp93pmt/a/testfile'

A quick glance at the current code in hg shows, that this bug is probably also present in all later Python versions than 2.7. I will attach a small patch that fixes this bug.

----------
components: Library (Lib)
files: filecmp-minimal.py
messages: 176700
nosy: till
priority: normal
severity: normal
status: open
title: unhandled IOError filecmp.cmpfiles() if file not readable
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file28168/filecmp-minimal.py

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

From report at bugs.python.org  Fri Nov 30 21:20:22 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 30 Nov 2012 20:20:22 +0000
Subject: [New-bugs-announce] [issue16585] surrogateescape broken w/
	multibytecodecs' encode
Message-ID: <1354306822.13.0.130768178209.issue16585@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

surrogateescape claims to be "implemented by all standard Python codecs"

http://docs.python.org/3/library/codecs.html#codec-base-classes

However it fails w/ multibytecodecs on encode:

Python 3.2.3+ (3.2:eb999002916c, Oct 26 2012, 16:11:03) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "\u30fb".encode('gb18030')
b'\x819\xa79'
>>> "\u30fb\udc80".encode('gb18030', 'surrogateescape')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: encoding error handler must return (unicode, int) tuple

The problem being that multibytecodec.c forces error handler return results to always be unicode and surrogateescape returns bytes here.

(surrogatepass also similarly returns bytes but it claims to be utf-8 only)

The error handler spec seems to imply that error handlers should always return unicode, because "The encoder will encode the replacement"

http://docs.python.org/3/library/codecs.html#codecs.register_error

but obviously that's not really the case: some codecs special case bytes results and copy them directly to the output, e.g.:

http://hg.python.org/cpython/file/ce3f0399ea33/Objects/unicodeobject.c#l6305

----------
components: Interpreter Core
messages: 176711
nosy: pjenvey
priority: normal
severity: normal
status: open
title: surrogateescape broken w/ multibytecodecs' encode
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov 30 22:40:45 2012
From: report at bugs.python.org (Dustin Boswell)
Date: Fri, 30 Nov 2012 21:40:45 +0000
Subject: [New-bugs-announce] [issue16586] json library can't parse large (>
	2^31) strings
Message-ID: <1354311645.71.0.363130090165.issue16586@psf.upfronthosting.co.za>


New submission from Dustin Boswell:

Here's a command-line that parses a json string containing a large array of short strings:

python -c "import simplejson as json; json.loads('[' + '''\"asdfadf\", ''' * 100000000 + '\"asdfasf\"]') "

That works, but if you increase the size a little bit (so the string is > 2^31)

python -c "import simplejson as json; json.loads('[' + '''\"asdfadf\", ''' * 300000000 + '\"asdfasf\"]') "

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/pymodules/python2.6/simplejson/__init__.py", line 307, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/pymodules/python2.6/simplejson/decoder.py", line 338, in decode
    raise ValueError(errmsg("Extra data", s, end, len(s)))
ValueError: Extra data: line 1 column -994967285 - line 1 column 3300000011 (char -994967285 - 3300000011)


Here's my version:

$ python
Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36) 
[GCC 4.4.3] on linux2
>>> import sys;print("%x" % sys.maxsize, sys.maxsize > 2**32)
('7fffffffffffffff', True)


Also note that the test above requires at least 20GB of memory (that's not a bug, just a heads-up).

----------
components: Library (Lib)
messages: 176722
nosy: Dustin.Boswell
priority: normal
severity: normal
status: open
title: json library can't parse large (> 2^31) strings
type: crash
versions: Python 2.6, Python 2.7

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