From report at bugs.python.org  Sun Jul  1 02:21:26 2012
From: report at bugs.python.org (Benjamin S Wolf)
Date: Sun, 01 Jul 2012 00:21:26 +0000
Subject: [New-bugs-announce] [issue15230] runpy.run_path broken: Breaks
	scoping; pollutes sys.modules; doesn't set __package__
Message-ID: <1341102085.69.0.0233636107843.issue15230@psf.upfronthosting.co.za>


New submission from Benjamin S Wolf <jokeserver at gmail.com>:

(Python 3.2.3)

1. After discarding the module run_path used to run the code in, all references to variables from local scopes (even if they are references to global variables) are bound to None, preventing any code in functions from running properly.

/tmp/a.py --------------------------------------
FOO = 'bar'

def f():
    print(FOO)

f()
------------------------------------------------
/tmp/b.py --------------------------------------
# Hack needed for:
#  python3 /tmp/b.py,
#  python3 -m /tmp/b
#  runpy.run_path('/tmp/b.py')
from os.path import dirname
__path__ = [dirname(__file__)]
del dirname

# Hack needed for:
#  python3 -m /tmp/b
if __name__ == '__main__' and not __package__:
    __package__ = '__main__'

from . import a

def g():
    print(a.FOO)

g()
------------------------------------------------

~$ python3
>>> import runpy
>>> d = runpy.run_module('/tmp/a')
bar
>>> d2 = runpy.run_path('/tmp/a.py')
bar
>>> d['f']
<function f at 0xb7451b6c>
>>> d['FOO']
'bar'
>>> d['f']()
bar
>>> d2['f']
<function f at 0xb7451bac>
>>> d2['FOO']
'bar'
>>> d2['f']()
None
>>> d3 = runpy.run_path('/tmp/b.py')
bar
bar
>>> d3['g']
<function g at 0xb746e26c>
>>> d3['a']
<module '<run_path>.a' from '/tmp/a.py'>
>>> d3['g']()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/b.py", line 15, in g
    print(a.FOO)
AttributeError: 'NoneType' object has no attribute 'FOO'

Notice that run_module gets this right, as d['f']() prints 'bar' but d2['f']() and d3['g']() do not.


2. run_path pollutes the module namespace when running a module that uses relative imports. This prevents any code that imports the same module in the same manner from running.

Continuing from #1 without having closed the interpreter:
>>> d4 = runpy.run_path('/tmp/b.py')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/runpy.py", line 250, in run_path
    return _run_module_code(code, init_globals, run_name, path_name)
  File "/usr/lib/python3.2/runpy.py", line 83, in _run_module_code
    mod_name, mod_fname, mod_loader, pkg_name)
  File "/usr/lib/python3.2/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/tmp/b.py", line 12, in <module>
    from . import a
ImportError: cannot import name a
>>> '<run_path>' in sys.modules
False
>>> '<run_path>.a' in sys.modules
True
>>> d3['a'].f()
bar
>>> del sys.modules['<run_path>.a']
>>> d4 = runpy.run_path('/tmp/b.py')
bar
bar
>>>

run_module, on the other hand, also alters sys.modules, but this does not prevent the module from being run, only from the secondary module from being re-imported:
[Create an empty file /tmp/__init__.py]
>>> sys.path = ['/'] + sys.path
>>> d5 = runpy.run_module('tmp.b')
bar
bar
>>> d6 = runpy.run_module('tmp.b')
bar
>>> d7 = runpy.run_module('tmp.b')
bar
>>> 'tmp' in sys.modules
True
>>> 'tmp.b' in sys.modules
False
>>> 'tmp.a' in sys.modules
True

[This was the only way I could get run_module to run /tmp/b.py, regardless of the presence or lack of the path and __package__ hacks at the top of the file, or any other changes I've experimented with. runpy.run_module('/tmp/b'), runpy.run_module('b') [with '/tmp' in sys.path] would generally result in:
  ValueError: Attempted relative import in non-package
and setting run_name='__main__' alongside any of the other changes would result in:
  ImportError: cannot import name a

python3 /tmp/b.py and python3 -m /tmp/b run fine.]


3. And finally, an examination of the run_path code shows that it doesn't, as the docs indicate, set __package__ to be run_name.rpartition('.')[0], but either the empty string or None: http://hg.python.org/cpython/file/3.2/Lib/runpy.py#l269

----------
components: Library (Lib)
messages: 164437
nosy: Benjamin.S.Wolf
priority: normal
severity: normal
status: open
title: runpy.run_path broken: Breaks scoping; pollutes sys.modules; doesn't set __package__
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul  1 04:34:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 01 Jul 2012 02:34:33 +0000
Subject: [New-bugs-announce] [issue15231] update PyPI upload doc to say
	--no-raw passed to	rst2html.py
Message-ID: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I had an issue whereby my reST long_description wasn't getting rendered as HTML when uploaded to PyPI.  Following the instructions here did not work as-is:

http://docs.python.org/dev/distutils/uploading.html#pypi-package-display

It seems that PyPI passes --no-raw (no HTML allowed) to rst2html.py, in which case the guidance would be better updated to read--

$ python setup.py --long-description | rst2html.py --no-raw > output.html

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164445
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: update PyPI upload doc to say --no-raw passed to rst2html.py
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  1 07:02:25 2012
From: report at bugs.python.org (Chris Pickett)
Date: Sun, 01 Jul 2012 05:02:25 +0000
Subject: [New-bugs-announce] [issue15232] maildir parsing can split up
	messages with 'From ' at	the start of a line
Message-ID: <1341118945.33.0.829442271947.issue15232@psf.upfronthosting.co.za>


New submission from Chris Pickett <cpicke at gmail.com>:

tar xvfz maildir_bug.tar.gz
cd maildir_bug
./bug.sh

The attachment contains a maildir with a single message.  This message has two body lines beginning with 'From '.  When converted to mbox using the maildir2mbox.py, only the second line gets a '>' at the beginning.  Thunderbird subsequently splits the message in two.  I think the fix is to put a '>' in front of each 'From ' line and not just the second one.  However, when I did that, Thunderbird displayed the '>', so either it is not the right fix, or Thunderbird has a bug.

I am using Python 2.7.1.  I searched the bug tracker and didn't see this issue, so decided to file even though I don't have the latest version.

Chris

----------
files: maildir_bug.tar.gz
messages: 164450
nosy: Chris.Pickett
priority: normal
severity: normal
status: open
title: maildir parsing can split up messages with 'From ' at the start of a line
Added file: http://bugs.python.org/file26221/maildir_bug.tar.gz

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

From report at bugs.python.org  Sun Jul  1 09:58:41 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 07:58:41 +0000
Subject: [New-bugs-announce] [issue15233] atexit: guarantee order of
	execution of registered	functions?
Message-ID: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Currently, the atexit docs state

"The order in which the functions are called is not defined" in the introduction and

"all functions registered are called in last in, first out order" in the docs of the atexit() function.

While the latter is correct, I don't think we should guarantee that behaviour by documenting it.  Suggestions?

----------
assignee: docs at python
components: Documentation
messages: 164454
nosy: docs at python, georg.brandl, loewis, pitrou
priority: normal
severity: normal
status: open
title: atexit: guarantee order of execution of registered functions?
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  1 10:29:14 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Jul 2012 08:29:14 +0000
Subject: [New-bugs-announce] [issue15234] avoid runtime library path for
	extensions found in	system directories
Message-ID: <1341131354.31.0.215672210129.issue15234@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

if a runtime library path is passed to build an extension, it always ends up in the .so file. it's not needed, so avoid runtime library path for extensions found in system directories.

----------
assignee: doko
components: Build
files: rpath.diff
keywords: patch
messages: 164460
nosy: doko
priority: normal
severity: normal
status: open
title: avoid runtime library path for extensions found in system directories
versions: Python 3.3
Added file: http://bugs.python.org/file26222/rpath.diff

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

From report at bugs.python.org  Sun Jul  1 10:36:08 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Jul 2012 08:36:08 +0000
Subject: [New-bugs-announce] [issue15235] allow newer berkley db versions
Message-ID: <1341131768.44.0.275273067892.issue15235@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

setup.py still has a version check for berkley db, currently only allowing versions up to 5.1.x. I'm checking in a patch to bump this to allow versions up to 5.3.x.

Maybe this version check should be disabled (after 3.3), using berkley db as a backend for the dbm module doesn't rely on any fancy berkley db features.

----------
assignee: doko
components: Build
messages: 164461
nosy: doko
priority: normal
severity: normal
status: open
title: allow newer berkley db versions
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  1 11:46:23 2012
From: report at bugs.python.org (Kai Sterker)
Date: Sun, 01 Jul 2012 09:46:23 +0000
Subject: [New-bugs-announce] [issue15236] SEGFAULT in visit_decref
Message-ID: <1341135983.73.0.665812827799.issue15236@psf.upfronthosting.co.za>


New submission from Kai Sterker <kai.sterker at gmail.com>:

Since update to Python 2.7.3 (as distributed by Ubuntu 12.04 64bit), I experience occasional crashes in the application I am developing (which uses Python scripting). The crash either happens at the first key press or it does not happen at all. Smells like a race condition to me.

I installed the debug version of Python 2.7.3 and compiled my project against that, which gave the attached stack trace. The crash also appears to be easier to reproduce with the debug version, but it still does not occur every time.

The application that exhibits the crash can be found here:
https://github.com/ksterker/adonthell

The Python method executed when the crash happens is this one:

    def estimate_speed (self, terrain):
        try:
            return self.Dic[terrain]
        except: return 0


Don't think it will be possible to construct a minimum example to demonstrate the issue, but if there is any other information helpful to shed more light on the issue, I'm happy to provide it.

Regards,

Kai

----------
files: stacktrace.txt
messages: 164468
nosy: Kai.Sterker
priority: normal
severity: normal
status: open
title: SEGFAULT in visit_decref
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file26223/stacktrace.txt

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

From report at bugs.python.org  Sun Jul  1 12:02:51 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 Jul 2012 10:02:51 +0000
Subject: [New-bugs-announce] [issue15237] Add capsule API to _decimal
Message-ID: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za>


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

Unfortunately, this won't make it into 3.3. -- The self-review of mpdecimal.c had priority and was extremely time consuming.

----------
assignee: skrah
messages: 164469
nosy: lemburg, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add capsule API to _decimal
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul  1 17:13:29 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 15:13:29 +0000
Subject: [New-bugs-announce] [issue15238] shutil.copystat should copy Linux
	extended attributes
Message-ID: <1341155609.31.0.707694531282.issue15238@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

3.3 adds the *xattr() extended attribute functions on Linux.  shutil implements a new internal function(_copyxattr) which copies these extended attributes.  However, it's only used in shutil.copy2().  I assert that shutil.copystat() should also preserve this metadata.  (Which, having subsumed this functionality, means that shutil.copy2() would no longer need to explicitly call it.)

Also: it might be worth considering taking the same approach _copyxattr uses for the other conditional functionality (see "def lookup" inside copystat).  Computing platform support at import time instead of runtime looks cleaner.

Georg, how much of this (if any) do you consider a 3.3 bugfix?

----------
assignee: larry
messages: 164483
nosy: georg.brandl, larry, storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: shutil.copystat should copy Linux extended attributes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  1 19:36:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jul 2012 17:36:14 +0000
Subject: [New-bugs-announce] [issue15239] Abandoned
	Tools/unicode/mkstringprep.py
Message-ID: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

It seems that Tools/unicode/mkstringprep.py has not been used for many years. Now it is not valid Python3 code nor Python2 code. The proposed patch fixes all porting errors.

Apparently, Lib/stringprep.py would have regenerated. Tools/unicode/mkstringprep.py output is a bit different from Lib/stringprep.py (in b3_exceptions).

----------
components: Demos and Tools, Unicode
messages: 164489
nosy: ezio.melotti, storchaka
priority: normal
severity: normal
status: open
title: Abandoned Tools/unicode/mkstringprep.py
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul  2 21:29:42 2012
From: report at bugs.python.org (Vincent Pelletier)
Date: Mon, 02 Jul 2012 19:29:42 +0000
Subject: [New-bugs-announce] [issue15240] ctype Structure keeps reference to
	function pointers
Message-ID: <1341257382.75.0.880502955632.issue15240@psf.upfronthosting.co.za>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

When storing a ctype function pointer in a ctype structure field, a reference remains even when that field is overwritten with some values:
- None
- None cast into a function pointer
But the reference is somehow removed when overwriting the field with a "real" function pointer (a lambda in attached test case).

This causes problem when the structure is a class property and function pointer is created out of a method of the same class: a circular reference is created, which is not garbage-collected.

To run the attached test case, you need objgraph[1], and to uncomment one (or none) of the commented-out lines in "close" method.

[1] http://mg.pov.lt/objgraph/

----------
components: ctypes
files: reproduce.py
messages: 164534
nosy: vpelletier
priority: normal
severity: normal
status: open
title: ctype Structure keeps reference to function pointers
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file26234/reproduce.py

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

From report at bugs.python.org  Tue Jul  3 06:22:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:22:54 +0000
Subject: [New-bugs-announce] [issue15241] venv module and pyvenv script
	documented, but not python behavior itself
Message-ID: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I did not find any doc or test for the behavior of the interpreter in virtual mode, only for venv and pyvenv.

A new paragraph in site.py exists, but it?s missing from site.rst, contains what I think is an error (saying that sys.prefix is always the real prefix), and should be somewhere more obvious than the site docs or linked from somewhere more obvious, like the Usage and Setup docs or maybe the tutorial.

----------
assignee: docs at python
components: Documentation, Tests
messages: 164563
nosy: docs at python, eric.araujo, vinay.sajip
priority: normal
severity: normal
status: open
title: venv module and pyvenv script documented, but not python behavior itself
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  3 08:54:12 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 03 Jul 2012 06:54:12 +0000
Subject: [New-bugs-announce] [issue15242] PyImport_GetMagicTag() should use
	the same const char *	as sys.implementation.cache_tag
Message-ID: <1341298452.58.0.698952095948.issue15242@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

There was some concern with PyImport_GetMagicTag() extracting its value from sys.implementation.cache_tag.  One solution is to have the two use a common underlying value.  However, that's basically what was already in import.c and I'd rather minimize that file at this point.

An alternative is to have the underlying value defined in a more amenable spot, but I'm not convinced that buys a whole lot over simply exposing the underlying value in PyImport_GetMagicTag().  If we could deprecate that function...

Another possibility is to move the underlying value to configure.  The down-side is that it's platform-specific.  I've attached a patch that does this.  While it may do too much as-is, it demonstrates my point.

----------
components: Interpreter Core
files: cache_tag_via_configure.diff
keywords: patch
messages: 164582
nosy: amaury.forgeotdarc, brett.cannon, eric.snow
priority: normal
severity: normal
stage: patch review
status: open
title: PyImport_GetMagicTag() should use the same const char * as sys.implementation.cache_tag
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26237/cache_tag_via_configure.diff

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

From report at bugs.python.org  Tue Jul  3 17:08:38 2012
From: report at bugs.python.org (William Schwartz)
Date: Tue, 03 Jul 2012 15:08:38 +0000
Subject: [New-bugs-announce] [issue15243] Misleading documentation for
	__prepare__
Message-ID: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>


New submission from William Schwartz <wkschwartz at gmail.com>:

Section 3.3.3.2. "Preparing the class namespace" of the documentation (http://docs.python.org/dev/reference/datamodel.html#preparing-the-class-namespace) states that "If the metaclass has a __prepare__ attribute, it is called as ``namespace = metaclass.__prepare__(name, bases, **kwds)``...." This isn't quite true. By just defining a ``__prepare__`` method in a metaclass, the interpreter calls it as it would a static method -- there is no implicit first argument referring to ``metaclass`` as the documentation implies. The documentation should be amended to say that users can decorate ``__prepare__`` as a class method to get ``metaclass`` passed in as the implicit first argument.

----------
assignee: docs at python
components: Documentation, Tests
messages: 164606
nosy: William.Schwartz, docs at python
priority: normal
severity: normal
status: open
title: Misleading documentation for __prepare__
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  3 21:14:54 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 03 Jul 2012 19:14:54 +0000
Subject: [New-bugs-announce] [issue15244] Support for opening files with
	FILE_SHARE_DELETE on	Windows
Message-ID: <1341342894.98.0.559958462018.issue15244@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

On Unix, files (unless specifically locked) can be renamed and deleted while file descriptors for the file remain open.  The file descriptors remain valid even after deletion of the file.

On Windows this is not possible for files opened using io.open() or os.open().  However, by using the FILE_SHARE_DELETE flag in CreateFile() one can get Unix-like behaviour.

Unfortunately, FILE_SHARE_DELETE is only available through the Win32 API, not through the CRT.  Also, Issue #14243 concerns the fact that on Windows temporary files cannot be reopened unless one uses the FILE_SHARE_DELETE flag.  One can only reopen a file by using a share mode that is at least as permissive as the share mode for all the currently open handles.

The attached patch adds a module "share" (bad name?) with functions share.open() and share.os_open() which act as substitutes for io.open() and os.open().  These by default use FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE as the share mode.  (io.open() and os.open() use FILE_SHARE_READ | FILE_SHARE_WRITE instead.)

To run the full regression test suite with builtins.open(), io.open() and os.open() monkey patched to use these replacements you can do

    python -m test.test_share --regrtest

Nothing seems to break.

----------
components: Library (Lib)
files: share.patch
keywords: patch
messages: 164616
nosy: sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Support for opening files with FILE_SHARE_DELETE on Windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26249/share.patch

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

From report at bugs.python.org  Tue Jul  3 22:11:26 2012
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Tue, 03 Jul 2012 20:11:26 +0000
Subject: [New-bugs-announce] [issue15245] ast.literal_eval on some literals
Message-ID: <1341346286.65.0.729285382693.issue15245@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

`ast.literal_eval` is very strict on names, so it seems to lack some "literals" that may be result of `repr` on built-in objects.

-> Obvious cases:

ast.literal_eval('...')
ast.literal_eval('Ellipsis')

both result on ValueError.



-> Not so obvious:

nan_name = repr(float('nan'))
ast.literal_eval(nan_name) # ValueError

inf_name = repr(float('inf'))
ast.literal_eval(inf_name)  # ValueError

ast.literal_eval("2e308") # == inf


`nan` and `inf` are not literals (at least "inf" should be, but that's another problem), but their representations are not possible to be evaluated unlike any other float numbers with maybe precision loss. 

I think `literal_eval` should include these 3 names the same way it accepts True, False and None.

Another case, that I personally don't care, but seems plausible would be `NotImplemented`.

----------
components: Library (Lib)
messages: 164621
nosy: JBernardo
priority: normal
severity: normal
status: open
title: ast.literal_eval on some literals
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul  4 04:02:06 2012
From: report at bugs.python.org (James King)
Date: Wed, 04 Jul 2012 02:02:06 +0000
Subject: [New-bugs-announce] [issue15246] Line coverage for
	collectionts.abc.Set
Message-ID: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za>


New submission from James King <james at agentultra.com>:

I'm working on increasing the line-coverage of the tests for the Set ABC in the collections.abc module.

I encountered something a little funky IMO that I'm not sure is an issue or bug... but the __and__ method passes a generator object to the constructor of the Set subclass' constructor where the code seems to check for Iterator. This makes my naive tests for the '&' operator to fail. So I haven't included them in this patch, statisfied with the equality tests and isdisjoint.

First patch, advice welcome.

----------
components: Tests
files: set_abc_coverage.patch
keywords: patch
messages: 164632
nosy: agentultra
priority: normal
severity: normal
status: open
title: Line coverage for collectionts.abc.Set
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26253/set_abc_coverage.patch

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

From report at bugs.python.org  Wed Jul  4 04:55:09 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Wed, 04 Jul 2012 02:55:09 +0000
Subject: [New-bugs-announce] [issue15247] io.open() is inconsistent re
	os.open()
Message-ID: <1341370509.01.0.335541688705.issue15247@psf.upfronthosting.co.za>


New submission from Juancarlo A?ez <apalala at gmail.com>:

>>> import io
>>> d = io.open('.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IsADirectoryError: [Errno 21] Is a directory: '.'
>>> 

>>> import os
>>> d = io.open(os.open('.',0))
>>> d
<_io.TextIOWrapper name=3 mode='r' encoding='UTF-8'>
>>>

----------
components: Library (Lib)
messages: 164633
nosy: apalala
priority: normal
severity: normal
status: open
title: io.open() is inconsistent re os.open()
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Jul  4 07:28:42 2012
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 04 Jul 2012 05:28:42 +0000
Subject: [New-bugs-announce] [issue15248] In "TypeError: 'tuple' object is
	not callable", suggest a comma.
Message-ID: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>


New submission from Ben Longbons <b.r.longbons at gmail.com>:

I frequently construct lists of tuples, such as:
[
  (1, 2, 3) # oops, missing comma!
  (4, 5, 6)
]

It would be nice if the error message gave a hint on what was *actually* wrong.

Although I always use homogeneous containers, the type that's not callable could be something other than 'tuple'.

You could possibly cut down on false positives (at the risk of false negatives) by checking that the not-callable object is newly constructed.

A better way to cut down on false positives would be to check that a list, tuple, or set is being constructed from a literal, but this might be more complex.

----------
messages: 164637
nosy: o11c
priority: normal
severity: normal
status: open
title: In "TypeError: 'tuple' object is not callable", suggest a comma.
type: enhancement

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

From report at bugs.python.org  Wed Jul  4 12:13:06 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 04 Jul 2012 10:13:06 +0000
Subject: [New-bugs-announce] [issue15249] email.generator.BytesGenerator
	doesn't mangle "From "	lines when non-ASCII bytes are present
Message-ID: <1341396786.66.0.201550976108.issue15249@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

The _handle_text function of BytesGenerator writes the payload straight through if there surrogateescape sequences are present, and skips the "From " mangling.

----------
components: email
messages: 164641
nosy: barry, petri.lehtinen, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul  4 16:36:07 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 04 Jul 2012 14:36:07 +0000
Subject: [New-bugs-announce] [issue15250] document that filecmp.dircmp
	comparisons are "shallow"
Message-ID: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation for the dircmp class doesn't say that the same_files and diff_files attributes are determined using the "shallow=True" rules described in the filecmp.cmp() and filecmp.cmpfiles().  It should say this.

For example, the documentation describes diff_files as, "Files which are in both a and b, whose contents differ."  But this isn't true since files whose contents differ aren't included if their os.stat() signatures are equal.

See also issue 12932 to allow dircmp to perform non-shallow comparisons.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164646
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: document that filecmp.dircmp comparisons are "shallow"
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul  4 19:29:13 2012
From: report at bugs.python.org (Jeffrey Harper)
Date: Wed, 04 Jul 2012 17:29:13 +0000
Subject: [New-bugs-announce] [issue15251] new.code and new.function crashes
	Python iterpretter
Message-ID: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>


New submission from Jeffrey Harper <jeff1.61803 at gmail.com>:

I've attached a script that crashes the Python interpreter.  

I can get the crash to occur under Windows Vista with this version of Python:

C:\tmp\remote>c:\Python27\python.exe
Python 2.7.1 Stackless 3.1b3 060516 (release27-maint, Jan  1 2011, 13:04:37) [MSC v.1500 32 bit (Intel)] on win32

Also, I got it to segfault under Ubuntu Linux:

jharper at ubuntu:~$ uname -a
Linux ubuntu 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 GNU/Linux
jharper at ubuntu:~$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2

Note, when I commented out the line, "pprint(code_args)", the script generated a SystemError exception instead of crashing.

----------
components: Library (Lib)
files: bug3.py
messages: 164652
nosy: jeffdharper
priority: normal
severity: normal
status: open
title: new.code and new.function crashes Python iterpretter
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file26257/bug3.py

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

From report at bugs.python.org  Thu Jul  5 10:27:14 2012
From: report at bugs.python.org (Vincent Pelletier)
Date: Thu, 05 Jul 2012 08:27:14 +0000
Subject: [New-bugs-announce] [issue15253] xmlrpclib.ServerProxy does not
	support 2-tuple value for	uri parameter
Message-ID: <1341476834.17.0.988428605754.issue15253@psf.upfronthosting.co.za>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

SafeTransport class supports a 2-tuple as uri, in order to pass x509 parameters to httplib.HTTPSConnection .
xmlrpclib.ServerProxy.__init__ fails when given such tuple, because it calls:
  urllib.splittype(uri)
without checking uri type first.

Minimal test case to reproduce is:

import xmlrpclib
xmlrpclib.ServerProxy(('https://example.com', {}))

----------
messages: 164676
nosy: vpelletier
priority: normal
severity: normal
status: open
title: xmlrpclib.ServerProxy does not support 2-tuple value for uri parameter
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul  5 16:21:54 2012
From: report at bugs.python.org (Chris Wright)
Date: Thu, 05 Jul 2012 14:21:54 +0000
Subject: [New-bugs-announce] [issue15254] 08 is invalid token in lists.
Message-ID: <1341498114.62.0.773022123174.issue15254@psf.upfronthosting.co.za>


New submission from Chris Wright <rikkitikkitavi at gmail.com>:

Python 2.6.6 tk 8.5
Idle 2.6.6

I was trying to generate a multidimensional list, and my test list kept giving errors highlighting 08 as an invalid token.

>>> cube = [[[01,02,03],[04,05,06],[07,08,09]],[[11,12,13],[14,15,16],[17,18,19]],[[21,22,3],[24,25,26],[27,28,29]]]
SyntaxError: invalid token
>>> cube = [[[01,02,03,04,05,06,07,08]]
SyntaxError: invalid token
>>> cube = [08]
SyntaxError: invalid token

----------
components: IDLE
messages: 164681
nosy: Chris.Wright
priority: normal
severity: normal
status: open
title: 08 is invalid token in lists.
versions: Python 2.6

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

From report at bugs.python.org  Thu Jul  5 19:55:05 2012
From: report at bugs.python.org (andisthermal)
Date: Thu, 05 Jul 2012 17:55:05 +0000
Subject: [New-bugs-announce] [issue15255] glose_Fb
Message-ID: <1341510905.93.0.746184432871.issue15255@psf.upfronthosting.co.za>


New submission from andisthermal <andisthermal.555 at gmail.com>:

<p>This automatic page generator is the easiest way to create beautiful pages for all of your projects. Author your page content here using GitHub Flavored Markdown, select a template crafted by a designer, and publish. After your page is generated, you can check out the new branch:</p>

<pre><code>$ cd your_repo_root/repo_name
$ git fetch origin
$ git checkout gh-pages
</code></pre>

<p>If you're using the GitHub for Mac, simply sync your repository and you'll see the new branch.</p>

<h3>Designer Templates</h3>

----------
components: XML
files: Fb.init.js
hgrepos: 138
messages: 164688
nosy: andisthermal555
priority: normal
severity: normal
status: open
title: glose_Fb
type: security
versions: 3rd party
Added file: http://bugs.python.org/file26261/Fb.init.js

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

From report at bugs.python.org  Thu Jul  5 20:57:49 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Thu, 05 Jul 2012 18:57:49 +0000
Subject: [New-bugs-announce] [issue15256] Typo in error message
Message-ID: <1341514669.16.0.587932473822.issue15256@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

>From a failing unit test with coverage.py, I noticed what seems to be a slight typo in the error message when a module cannot be imported:

diff -r 1186d68715cc Lib/imp.py
--- a/Lib/imp.py	Wed Jul 04 19:33:45 2012 -0700
+++ b/Lib/imp.py	Thu Jul 05 11:50:25 2012 -0700
@@ -230,7 +230,7 @@
                 continue
             break  # Break out of outer loop when breaking out of inner loop.
     else:
-        raise ImportError('No module name {!r}'.format(name), name=name)
+        raise ImportError('No module named {!r}'.format(name), name=name)
 
     encoding = None
     if mode == 'U':

Note the missing "d". This makes it match similar existing error messages:

Lib/importlib/_bootstrap.py
1238:_ERR_MSG = 'No module named {!r}'

Lib/modulefinder.py
185:        self.msgout(4, "raise ImportError: No module named", qname)
186:        raise ImportError("No module named " + qname)
198:                self.msgout(4, "raise ImportError: No module named", mname)
199:                raise ImportError("No module named " + mname)
215:                    raise ImportError("No module named " + subname)

Lib/runpy.py
106:        raise ImportError("No module named %s" % mod_name)

I wonder if this can be centralized to ensure that all code uses the exact same message?

----------
components: Library (Lib)
messages: 164693
nosy: Marc.Abramowitz, brett.cannon
priority: normal
severity: normal
status: open
title: Typo in error message
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 00:40:30 2012
From: report at bugs.python.org (rian)
Date: Thu, 05 Jul 2012 22:40:30 +0000
Subject: [New-bugs-announce] [issue15257] Misc/.gdbinit:pystack is too
	brittle
Message-ID: <1341528030.36.0.158267038298.issue15257@psf.upfronthosting.co.za>


New submission from rian <rian at dropbox.com>:

the `pystack`, `pystackv`, and `printframe` macros in the sample gdbinit file distributed with python are too fragile. this patch (which relies on gdb 7) is much more robust.

----------
components: None
files: mypatch.diff
keywords: patch
messages: 164701
nosy: rian
priority: normal
severity: normal
status: open
title: Misc/.gdbinit:pystack is too brittle
Added file: http://bugs.python.org/file26263/mypatch.diff

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

From report at bugs.python.org  Fri Jul  6 00:41:13 2012
From: report at bugs.python.org (Nefarious CodeMonkey, Jr.)
Date: Thu, 05 Jul 2012 22:41:13 +0000
Subject: [New-bugs-announce] [issue15258] argparse documentation: Improve
	optparse section	regarding allow_interspersed_args
Message-ID: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>


New submission from Nefarious CodeMonkey, Jr. <nejucomo at users.sourceforge.net>:

It was not obvious from the documentation on argparse how to emulate the optparse.OptionParser.allow_interspersed_args feature.

Please add something like the following to the section titled "Upgrading optparse code" (see: http://docs.python.org/library/argparse.html#upgrading-optparse-code )

"""
* If the optparse code sets allow_interspersed_args to False, then add an argparse positional argument with nargs=argparse.REMAINDER
"""

----------
assignee: docs at python
components: Documentation
messages: 164702
nosy: docs at python, nejucomo
priority: normal
severity: normal
status: open
title: argparse documentation: Improve optparse section regarding allow_interspersed_args
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/issue15258>
_______________________________________

From report at bugs.python.org  Fri Jul  6 01:01:46 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 05 Jul 2012 23:01:46 +0000
Subject: [New-bugs-announce] [issue15259] "Helping with Documentation"
	references missing	dailybuild.py
Message-ID: <1341529306.29.0.594209420115.issue15259@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The intro to the "Helping with Documentation" section of the Developer's Guide--

http://docs.python.org/devguide/docquality.html#helping-with-documentation

includes a reference to a Doc/tools/dailybuild.py script, but this script does not seem to exist in the source tree.

----------
components: Devguide
keywords: easy
messages: 164703
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: "Helping with Documentation" references missing dailybuild.py
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 01:12:25 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 05 Jul 2012 23:12:25 +0000
Subject: [New-bugs-announce] [issue15260] Mention how to order Misc/NEWS
	entries
Message-ID: <1341529945.6.0.935201074505.issue15260@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would help if the "Commit Messages and NEWS Entries" subsection of the Developer's Guide said something about where in the ordering new Misc/NEWS entries should be added (e.g. at the top or bottom or by importance):

http://docs.python.org/devguide/committing.html?highlight=news#commit-messages-and-news-entries

The only reference I could find was an indirect reference in the section about the Developer Log:

http://docs.python.org/devguide/developers.html

----------
components: Devguide
keywords: easy
messages: 164704
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: Mention how to order Misc/NEWS entries
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 02:03:26 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 06 Jul 2012 00:03:26 +0000
Subject: [New-bugs-announce] [issue15261] os.stat(fd) crashes on Windows if
	fd does not exist
Message-ID: <1341533006.37.0.469874920155.issue15261@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

In Python 3.3 (but not earlier) os.stat() is documented to work with file descriptors.  (os.path.exists() also works with fds since it is implemented in terms of os.stat(), although that is *not* documented.)

However, on Windows if fd is not open then os.stat(fd) triggers an assertion error or crash:

  File: f:\dd\vctools\crt_bld\self_x86\crt\src\osfinfo.c
  Line: 316
  Expression: (_osfile(fh) & FOPEN)

Note that os.fstat() fails on Windows with OSError(EBADF, ...).

----------
messages: 164705
nosy: sbt
priority: high
severity: normal
stage: needs patch
status: open
title: os.stat(fd) crashes on Windows if fd does not exist
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 10:28:13 2012
From: report at bugs.python.org (Mark)
Date: Fri, 06 Jul 2012 08:28:13 +0000
Subject: [New-bugs-announce] [issue15262] Idle does not show traceback in
	other threads
Message-ID: <1341563293.08.0.285980110052.issue15262@psf.upfronthosting.co.za>


New submission from Mark <myagna01 at students.poly.edu>:

Consider the following code:

from thread import start_new
def f(): typo #there is no variable called typo
start_new(f, ())

If run from the command line, this produces a traceback.  If run from IDLE, it does not.  I suspect this is not by design.  This caused me endless grief in debugging until one happy day I discovered the traceback module.  I now write:

from thread import start_new
from traceback import print_exc
def f():
 try: typo
 except: print_exc()
start_new(f, ())

this works, but I wish I didn't need it.

----------
components: IDLE
messages: 164718
nosy: Mark
priority: normal
severity: normal
status: open
title: Idle does not show traceback in other threads
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  6 16:16:36 2012
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 06 Jul 2012 14:16:36 +0000
Subject: [New-bugs-announce] [issue15263] Guard against invalid file handles
	in os functions
Message-ID: <1341584196.67.0.703107638593.issue15263@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

#15261 shows us that Windows can crash if you pass in an invalid file handle to Windows POSIX-y functions.  We should ensure that functions which accept path-as-an-int-fd guard against this where necessary.

I propose a macro, something like

#ifdef MS_WINDOWS
#define FD_GUARD(fd) (_PyVerify_fd(fd) ? (fd) : INVALID_HANDLE_VALUE)
#else
#define FD_GUARD(fd) (fd)
#endif

----------
assignee: larry
components: Library (Lib)
messages: 164722
nosy: amaury.forgeotdarc, larry, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: Guard against invalid file handles in os functions
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  6 18:40:40 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 16:40:40 +0000
Subject: [New-bugs-announce] [issue15264]
	PyErr_SetFromErrnoWithFilenameObject() undocumented
Message-ID: <1341592840.74.0.991788798601.issue15264@psf.upfronthosting.co.za>


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

Title says it all.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 164736
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PyErr_SetFromErrnoWithFilenameObject() undocumented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  6 19:50:45 2012
From: report at bugs.python.org (Roy Smith)
Date: Fri, 06 Jul 2012 17:50:45 +0000
Subject: [New-bugs-announce] [issue15265] random.sample() docs unclear on k
	< len(population)
Message-ID: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The docs don't say what happens if you call random.sample() with a population smaller than k.  Experimentally, it raises ValueError, but this should be documented.

I would have guessed it would return IndexError, by analogy to random.choice().

----------
assignee: docs at python
components: Documentation
messages: 164742
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: random.sample() docs unclear on k < len(population)
type: enhancement

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

From report at bugs.python.org  Sat Jul  7 00:41:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 22:41:29 +0000
Subject: [New-bugs-announce] [issue15266] Provide an easy way to check a
	reST long_description for	PyPI
Message-ID: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

There should be an easy way to check a reST long_description on one's local machine before uploading to PyPI.  The check should use the same rules that PyPI uses, so that passing the check locally ensures that PyPI will convert the description to HTML successfully.

Issue 15231 is related and focuses on the current documentation.  See that issue for some background and ideas.

Also see the corresponding issue filed on the PyPI tracker:

http://sourceforge.net/tracker/?func=detail&aid=3539253&group_id=66150&atid=513503

----------
assignee: eric.araujo
components: Distutils2
messages: 164759
nosy: alexis, cjerdonek, eric.araujo, loewis, tarek
priority: normal
severity: normal
status: open
title: Provide an easy way to check a reST long_description for PyPI

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

From report at bugs.python.org  Sat Jul  7 02:24:35 2012
From: report at bugs.python.org (Tim Smith)
Date: Sat, 07 Jul 2012 00:24:35 +0000
Subject: [New-bugs-announce] [issue15267] tempfile.TemporaryFile and httplib
	incompatibility
Message-ID: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za>


New submission from Tim Smith <tzs at tzs.net>:

In httplib.py, there is this code to try to get the body length:

    def _set_content_length(self, body):
        # Set the content-length based on the body.
        thelen = None
        try:
            thelen = str(len(body))
        except TypeError, te:
            # If this is a file-like object, try to
            # fstat its file descriptor
            try:
                thelen = str(os.fstat(body.fileno()).st_size)
            except (AttributeError, OSError):
                # Don't send a length if this failed
                if self.debuglevel > 0: print "Cannot stat!!"

However, if the body is a temporary file created by tempfile.TemporaryFile(), the len(body) in the first try throws an AttributeError, not a TypeError, on Windows and so it is not caught and unhappiness ensues. It is fine on Macintosh, and I would presume also on Linux.

Windows behaves different because on the other systems, TemporaryFile() returns an actual file object, and len() on a file throws TypeError. On Windows, TemporaryFile() returns an object that wraps the underlying file, and calling len() on that objects invokes this from tempfile.py (around line 371):

    def __getattr__(self, name):
        # Attribute lookups are delegated to the underlying file
        # and cached for non-numeric results
        # (i.e. methods are cached, closed and friends are not)
        file = self.__dict__['file']
        a = getattr(file, name)
        if not issubclass(type(a), type(0)):
            setattr(self, name, a)
        return a

Since the underlying file does not have a __len__ method, the getattr fails and throws AttributeError.

I'm sorry I'm not submitting a patch, but I do not know enough about the design of these two libraries to know whether the correct fix is for httplib to be more broad in the exceptions that cause it to check for a file when len() fails, or if the object returned by TemporaryFile() should be more closely mimicking a true file object and so should be made to throw TypeError when someone tries to use len() on it.

----------
components: Windows
messages: 164764
nosy: tzs
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile and httplib incompatibility
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul  7 03:04:34 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Jul 2012 01:04:34 +0000
Subject: [New-bugs-announce] [issue15268] curses configure checks fail if
	only	/usr/include/ncursesw/curses.h is installed
Message-ID: <1341623074.57.0.341676091224.issue15268@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

the curses configure checks fail if only /usr/include/ncursesw/curses.h is installed (on a Debian/Ubuntu system, uninstall the libncurses5-dev package, and install the libncursesw5-dev package).

The attached patch adds -I/usr/include/ncursesw to CPPFLAGS for the tests.

I assume that most buildbot systems still have an /usr/include/curses.h installed, so the tests do the intended thing, because the features tested are the same in ncurses and ncursesw, but basically the wrong headers are used for these tests if both /usr/include/curses.h and /usr/include/ncursesw/curses.h are installed.

----------
components: Build
files: curses.diff
keywords: patch
messages: 164765
nosy: doko
priority: normal
severity: normal
status: open
title: curses configure checks fail if only /usr/include/ncursesw/curses.h is installed
versions: Python 3.3
Added file: http://bugs.python.org/file26276/curses.diff

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

From report at bugs.python.org  Sat Jul  7 06:28:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 04:28:00 +0000
Subject: [New-bugs-announce] [issue15269] Document dircmp.left and
	dircmp.right
Message-ID: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation for the filecmp.dircmp class doesn't mention dircmp.left and dircmp.right.

Being aware of this up front would make certain simplifications easier to think of.  For example, knowing about these attributes opens up the possibility of passing dircmp instances around without having to pass the two paths separately (e.g. in certain recursive algorithms involving dircmp).  Knowing this also means you can recover the two paths if using the subdirs attribute (whose values are dircmp instances).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164781
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Document dircmp.left and dircmp.right
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 08:03:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 06:03:49 +0000
Subject: [New-bugs-announce] [issue15270] "Economy of Expression" section
	outdated
Message-ID: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The "Economy of Expression" section of the Dev Guide's "Documenting Python"--

http://docs.python.org/devguide/documenting.html#economy-of-expression

says, "The documentation for super() is an example of where a good deal of information was condensed into a few short paragraphs."

However, the documentation for super() is now nine short paragraphs.  Back in Python 2.2 (when super() was introduced), the description really was only two short paragraphs (along with a brief code snippet):

http://docs.python.org/release/2.2.3/lib/built-in-funcs.html

So this might no longer be the best example.

----------
components: Devguide
keywords: easy
messages: 164788
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: "Economy of Expression" section outdated
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 10:45:41 2012
From: report at bugs.python.org (=?utf-8?b?SW9udcibIEFyyJvEg3JpyJlp?=)
Date: Sat, 07 Jul 2012 08:45:41 +0000
Subject: [New-bugs-announce] [issue15271] argparse: repeatedly specifying
	the same argument	ignores the previous ones
Message-ID: <1341650741.0.0.256570615986.issue15271@psf.upfronthosting.co.za>


New submission from Ionu? Ar??ri?i <ionut at artarisi.eu>:

To reproduce:

>>> import argparse
[74536 refs]
>>> parser = argparse.ArgumentParser()
[74809 refs]
>>> parser.add_argument("foo")
>>> parser.add_argument("foo")
>>> parser.parse_args(["bar"])

usage: ipython [-h] foo foo
ipython: error: too few arguments
An exception has occurred, use %tb to see the full traceback.

SystemExit: 2

>>> parser.parse_args(["bar", "baz"])
>>> Namespace(foo='baz')

So it actually makes you provide two arguments, but it loses/ignores the first one and there's no way to get it back.

----------
messages: 164791
nosy: bethard, mapleoin
priority: normal
severity: normal
status: open
title: argparse: repeatedly specifying the same argument ignores the previous ones
type: behavior

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

From report at bugs.python.org  Sat Jul  7 12:19:47 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 10:19:47 +0000
Subject: [New-bugs-announce] [issue15272] pkgutil.find_loader accepts
	invalid module names
Message-ID: <1341656387.47.0.245292094882.issue15272@psf.upfronthosting.co.za>


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

The pkgutil import emulation is insane and permits modules identifiers to contain paths.

Identified in #15230 (reporting some very surprising behaviour from runpy.run_module).

----------
messages: 164806
nosy: brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: pkgutil.find_loader accepts invalid module names
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul  7 14:29:13 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 07 Jul 2012 12:29:13 +0000
Subject: [New-bugs-announce] [issue15273] Remove unnecessarily random
	behavior from test_unparse.py
Message-ID: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Tools/parser/test_unparse.py is the regression test suite for Tools/unparse.  To save time, if the "cpu" resource is not enabled it only test unparsing ten files.  However it picks these files at random.

It would be nice if the test was 100% repeatable.  It might be nice if it picked the most tortuous ten files.  What ten are the most tortuous is not immediately clear, but a nice first approximation might be to pick the largest ten, provided the stat calls don't themselves make the test slow again.

----------
assignee: mark.dickinson
messages: 164831
nosy: larry, mark.dickinson
priority: low
severity: normal
stage: needs patch
status: open
title: Remove unnecessarily random behavior from test_unparse.py
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 15:22:05 2012
From: report at bugs.python.org (Andrea Griffini)
Date: Sat, 07 Jul 2012 13:22:05 +0000
Subject: [New-bugs-announce] [issue15274] Patch for issue 5765: stack
	overflow evaluating	eval("()" * 30000)
Message-ID: <CALy7ODsifKfYpqVvCcnGh1_wkeHhZvc7ks2qPMt4U+PN6-W1ew@mail.gmail.com>


New submission from Andrea Griffini <agriff at tin.it>:

This is a fix for issue #5765: stack overflow evaluating eval("()" * 30000)

The solution was to add two fields (recursion_depth and
recursion_limit) to the symbol table object and just increment and
check the depth in symtable_visit_expr raising a RuntimeError in case
the limit is exceeded.

The test case added also covers other similar cases (a.b.b.b.b.b...
and a[0][0][0][0]....)

There is no depth check in when visiting statement because I cannot
think to a way to nesting statements too much without getting other
errors before. If there is a way to do it, it would be trivial to also
cover that part.

The patch uses the current depth and current recursion limit but
multiplies them for a factor because I suppose that the amount of C
stack used by the compiler per recursion is smaller than the amount
used by the interpreter; the constant in the patch is 4. Using a
constant of 1 (i.e. just using the normal recursion limit) doesn't
allow a previously existing test about big expressions to pass.

----------
files: compiler_recursion_limit_check.patch
keywords: patch
messages: 164839
nosy: ag6502
priority: normal
severity: normal
status: open
title: Patch for issue 5765: stack overflow evaluating eval("()" * 30000)
Added file: http://bugs.python.org/file26292/compiler_recursion_limit_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15274>
_______________________________________
-------------- next part --------------
diff -r d9c98730e2e8 Include/symtable.h
--- a/Include/symtable.h	Sat Jul 07 13:34:50 2012 +1000
+++ b/Include/symtable.h	Sat Jul 07 14:39:38 2012 +0200
@@ -30,6 +30,8 @@
     PyObject *st_private;           /* name of current class or NULL */
     PyFutureFeatures *st_future;    /* module's future features that affect
                                        the symbol table */
+    int recursion_depth;            /* current recursion depth */
+    int recursion_limit;            /* recursion limit */
 };
 
 typedef struct _symtable_entry {
diff -r d9c98730e2e8 Lib/test/test_compile.py
--- a/Lib/test/test_compile.py	Sat Jul 07 13:34:50 2012 +1000
+++ b/Lib/test/test_compile.py	Sat Jul 07 14:39:38 2012 +0200
@@ -474,6 +474,14 @@
         self.assertInvalidSingle('f()\nxy # blah\nblah()')
         self.assertInvalidSingle('x = 5 # comment\nx = 6\n')
 
+    def test_compiler_recursion_limit(self):
+        self.assertRaises(RuntimeError, self.compile_single, "()" * 100000)
+        self.assertRaises(RuntimeError, self.compile_single, "a" + ".b" * 100000)
+        self.assertRaises(RuntimeError, self.compile_single, "a" + "[0]" * 100000)
+        self.compile_single("()" * 2000)
+        self.compile_single("a" + ".b" * 2000)
+        self.compile_single("a" + "[0]" * 2000)
+
 def test_main():
     support.run_unittest(TestSpecifics)
 
diff -r d9c98730e2e8 Python/symtable.c
--- a/Python/symtable.c	Sat Jul 07 13:34:50 2012 +1000
+++ b/Python/symtable.c	Sat Jul 07 14:39:38 2012 +0200
@@ -218,17 +218,37 @@
     return NULL;
 }
 
+/* When compiling the use of C stack is probably going to be a lot
+   lighter than when executing Python code but still can overflow
+   and causing a Python crash if not checked (e.g. eval("()"*300000)).
+   Using the current recursion limit for the compiler too seems
+   overconstraining so a factor is used to allow deeper recursion
+   when compiling an expression.
+*/
+#define COMPILER_STACK_FRAME_SCALE 4
+
 struct symtable *
 PySymtable_Build(mod_ty mod, const char *filename, PyFutureFeatures *future)
 {
     struct symtable *st = symtable_new();
     asdl_seq *seq;
     int i;
+    PyThreadState *tstate;
 
     if (st == NULL)
         return st;
     st->st_filename = filename;
     st->st_future = future;
+
+    /* Setup recursion depth check counters */
+    tstate = PyThreadState_GET();
+    if (!tstate) {
+        PySymtable_Free(st);
+        return NULL;
+    }
+    st->recursion_depth = tstate->recursion_depth * COMPILER_STACK_FRAME_SCALE;
+    st->recursion_limit = Py_GetRecursionLimit() * COMPILER_STACK_FRAME_SCALE;
+
     /* Make the initial symbol information gathering pass */
     if (!GET_IDENTIFIER(top) ||
         !symtable_enter_block(st, top, ModuleBlock, (void *)mod, 0, 0)) {
@@ -1268,6 +1288,12 @@
 static int
 symtable_visit_expr(struct symtable *st, expr_ty e)
 {
+    if (++st->recursion_depth > st->recursion_limit) {
+        PyErr_SetString(PyExc_RuntimeError,
+                        "maximum recursion depth exceeded while compiling an expression");
+        --st->recursion_depth;
+        return 0;
+    }
     switch (e->kind) {
     case BoolOp_kind:
         VISIT_SEQ(st, expr, e->v.BoolOp.values);
@@ -1280,8 +1306,10 @@
         VISIT(st, expr, e->v.UnaryOp.operand);
         break;
     case Lambda_kind: {
-        if (!GET_IDENTIFIER(lambda))
+        if (!GET_IDENTIFIER(lambda)) {
+            --st->recursion_depth;
             return 0;
+        }
         if (e->v.Lambda.args->defaults)
             VISIT_SEQ(st, expr, e->v.Lambda.args->defaults);
         if (e->v.Lambda.args->kw_defaults)
@@ -1289,12 +1317,16 @@
                                  e->v.Lambda.args->kw_defaults);
         if (!symtable_enter_block(st, lambda,
                                   FunctionBlock, (void *)e, e->lineno,
-                                  e->col_offset))
+                                  e->col_offset)) {
+            --st->recursion_depth;
             return 0;
+        }
         VISIT(st, arguments, e->v.Lambda.args);
         VISIT(st, expr, e->v.Lambda.body);
-        if (!symtable_exit_block(st, (void *)e))
+        if (!symtable_exit_block(st, (void *)e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     }
     case IfExp_kind:
@@ -1310,20 +1342,28 @@
         VISIT_SEQ(st, expr, e->v.Set.elts);
         break;
     case GeneratorExp_kind:
-        if (!symtable_visit_genexp(st, e))
+        if (!symtable_visit_genexp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case ListComp_kind:
-        if (!symtable_visit_listcomp(st, e))
+        if (!symtable_visit_listcomp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case SetComp_kind:
-        if (!symtable_visit_setcomp(st, e))
+        if (!symtable_visit_setcomp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case DictComp_kind:
-        if (!symtable_visit_dictcomp(st, e))
+        if (!symtable_visit_dictcomp(st, e)) {
+            --st->recursion_depth;
             return 0;
+        }
         break;
     case Yield_kind:
     case YieldFrom_kind: {
@@ -1366,15 +1406,19 @@
         break;
     case Name_kind:
         if (!symtable_add_def(st, e->v.Name.id,
-                              e->v.Name.ctx == Load ? USE : DEF_LOCAL))
+                              e->v.Name.ctx == Load ? USE : DEF_LOCAL)) {
+            --st->recursion_depth;
             return 0;
+        }
         /* Special-case super: it counts as a use of __class__ */
         if (e->v.Name.ctx == Load &&
             st->st_cur->ste_type == FunctionBlock &&
             !PyUnicode_CompareWithASCIIString(e->v.Name.id, "super")) {
             if (!GET_IDENTIFIER(__class__) ||
-                !symtable_add_def(st, __class__, USE))
+                !symtable_add_def(st, __class__, USE)) {
+                --st->recursion_depth;
                 return 0;
+            }
         }
         break;
     /* child nodes of List and Tuple will have expr_context set */
@@ -1385,6 +1429,7 @@
         VISIT_SEQ(st, expr, e->v.Tuple.elts);
         break;
     }
+    --st->recursion_depth;
     return 1;
 }
 

From report at bugs.python.org  Sat Jul  7 15:38:18 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sat, 07 Jul 2012 13:38:18 +0000
Subject: [New-bugs-announce] [issue15275] isinstance is called a more times
	that needed in ntpath
Message-ID: <1341668298.8.0.671820953585.issue15275@psf.upfronthosting.co.za>


New submission from Manuel de la Pena <manuel at canonical.com>:

The problem is simple, the code that allows to use binary strings and unicode is making more calls that needed to isinstance(path, bytes) since the result of the code is not shared. For example, the following calls are present in the module:

def _get_empty(path):
    if isinstance(path, bytes):
        return b'' 
    else:
        return ''

def _get_sep(path):
    if isinstance(path, bytes):
        return b'\\'
    else:
        return '\\'

def _get_altsep(path):
    if isinstance(path, bytes):
        return b'/'
    else:
        return '/'

def _get_bothseps(path):
    if isinstance(path, bytes):
        return b'\\/'
    else:
        return '\\/'

def _get_dot(path):
    if isinstance(path, bytes):
        return b'.'
    else:
        return '.'

...

And then something similar to the following is found in the code:

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    sep = _get_sep(path)
    dotdot = _get_dot(path) * 2
    special_prefixes = _get_special(path)
    if path.startswith(special_prefixes):
        # in the case of paths with these prefixes:
        # \\.\ -> device names
        # \\?\ -> literal paths
        # do not do any normalization, but return the path unchanged
        return path
    path = path.replace(_get_altsep(path), sep)
    prefix, path = splitdrive(path)

As you can see the isinstance call is performed more than needed which certainly affects the performance of the path operations. 

The attached patch removes the number of calls to isinstance(obj, bytes) and also ensures that the function that returns the correct literal is as fast as possible by using a dict.

----------
components: Windows
files: less_isinstance.patch
hgrepos: 140
keywords: patch
messages: 164842
nosy: mandel
priority: normal
severity: normal
status: open
title: isinstance is called a more times that needed in ntpath
versions: Python 3.3
Added file: http://bugs.python.org/file26294/less_isinstance.patch

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

From report at bugs.python.org  Sat Jul  7 15:40:47 2012
From: report at bugs.python.org (Ariel Ben-Yehuda)
Date: Sat, 07 Jul 2012 13:40:47 +0000
Subject: [New-bugs-announce] [issue15276] unicode format does not really
	work in Python 2.x
Message-ID: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za>


New submission from Ariel Ben-Yehuda <arielb1 at mail.tau.ac.il>:

unicode formats (u'{:n}'.format) in python 2.x assume that the thousands seperator is in ascii, so this fails:

>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, 'fra') # or fr_FR on UNIX
>>> u'{:n}'.format(10000)
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    u'{:n}'.format(10000)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 2: ordinal not in range(128)

However, it works correctly in python 3, properly returning '10\xA00000' (the \xA0 is a nbsp)

----------
messages: 164844
nosy: Ariel.Ben-Yehuda
priority: normal
severity: normal
status: open
title: unicode format does not really work in Python 2.x
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul  7 16:16:02 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 14:16:02 +0000
Subject: [New-bugs-announce] [issue15277] Fix resource leak in
	support.py:_is_ipv6_enabled
Message-ID: <1341670562.42.0.543646268304.issue15277@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

I'm running Ubuntu Precise and have net.ipv6.conf.all.disable_ipv6 = 1 in my sysctl.conf. With this configuration at head there's a fd leak in 
_is_ipv6_enabled in support.py when the bind fails, which the attached patch should fix.

----------
components: Tests
files: ipv6-enabled-fd-leak-fix.patch
keywords: patch
messages: 164855
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource leak in support.py:_is_ipv6_enabled
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26299/ipv6-enabled-fd-leak-fix.patch

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

From report at bugs.python.org  Sat Jul  7 17:18:39 2012
From: report at bugs.python.org (lovelylain)
Date: Sat, 07 Jul 2012 15:18:39 +0000
Subject: [New-bugs-announce] [issue15278] UnicodeDecodeError when readline
	in codecs.py
Message-ID: <1341674319.29.0.269195397783.issue15278@psf.upfronthosting.co.za>


New submission from lovelylain <lovelylain at keju.tk>:

This is an example, `for line in fp` will raise UnicodeDecodeError:
#! -*- coding: utf-8 -*-
import codecs

text = u'\u6731' + u'\U0002a6a5' * 18
print repr(text)

with codecs.open('test.txt', 'wb', 'utf-16-le') as fp:
    fp.write(text)

with codecs.open('test.txt', 'rb', 'utf-16-le') as fp:
    print repr(fp.read())

with codecs.open('test.txt', 'rb', 'utf-16-le') as fp:
    for line in fp:
        print repr(line)

I read code in codecs.py:
    def read(self, size=-1, chars=-1, firstline=False):

        """ Decodes data from the stream self.stream and returns the
            resulting object.
...
            If firstline is true, and a UnicodeDecodeError happens
            after the first line terminator in the input only the first line
            will be returned, the rest of the input will be kept until the
            next call to read().

        """
...
            try:
                newchars, decodedbytes = self.decode(data, self.errors)
            except UnicodeDecodeError, exc:
                if firstline:
                    newchars, decodedbytes = self.decode(data[:exc.start], self.errors)
                    lines = newchars.splitlines(True)
                    if len(lines)<=1:
                        raise
                else:
                    raise
...

It seems that the firstline argument is not consistent with its doc description.
I don't konw why this argument was added and why lines count was checked.
If it was added for readline function to fix some decode errors, we may have no EOLs in data readed, so it caused UnicodeDecodeError too.
Maybe we should write code like below to support codecs readline.

    def read(self, size=-1, chars=-1, autotruncate=False):
...
            try:
                newchars, decodedbytes = self.decode(data, self.errors)
            except UnicodeDecodeError, exc:
                if autotruncate and exc.start:
                    newchars, decodedbytes = self.decode(data[:exc.start], self.errors)
                else:
                    raise
...

----------
components: Library (Lib)
messages: 164869
nosy: lovelylain
priority: normal
severity: normal
status: open
title: UnicodeDecodeError when readline in codecs.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jul  7 17:22:25 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 15:22:25 +0000
Subject: [New-bugs-announce] [issue15279] Spurious unittest warnings
Message-ID: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

On Mac OS X 10.7 64-bit unittest regression tests fail:


    ======================================================================
    FAIL: test_warnings (unittest.test.test_runner.Test_TextTestRunner)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/ambv/Documents/Projekty/Python/cpython/py33/Lib/unittest/test/test_runner.py", line 269, in test_warnings
        self.assertEqual(len(out), 12)
    AssertionError: 15 != 12

    ----------------------------------------------------------------------
    Ran 568 tests in 24.441s

    FAILED (failures=1, skipped=1)
    test test_unittest failed


It looks like warnings generated by unittest aren't properly limited to one for each distinct warning. Running _test_warnings.py directly shows that:

    $ ./python.exe Lib/unittest/test/_test_warnings.py
    .......
    ----------------------------------------------------------------------
    Ran 7 tests in 0.002s

    OK
    Please use assertEqual instead.
    Please use assertEqual instead.
    Please use assertEqual instead.
    dw
    dw
    dw
    Please use assertTrue instead.
    Please use assertTrue instead.
    rw
    iw
    iw
    iw
    uw
    uw
    uw
    [61188 refs]

The expected behaviour would be for each kind of the "Please use" warnings to only appear once.

----------
assignee: michael.foord
components: Library (Lib)
messages: 164872
nosy: lukasz.langa, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Spurious unittest warnings
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul  7 17:33:07 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 15:33:07 +0000
Subject: [New-bugs-announce] [issue15280] Don't use builtins as variable
	names in urllib.request
Message-ID: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

See attached patch, there's still self.type in places. I also converted one map to a list comprehension.

----------
components: Library (Lib)
files: urllib-request-cleanup-builtin-names.patch
keywords: patch
messages: 164874
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Don't use builtins as variable names in urllib.request
versions: Python 3.4
Added file: http://bugs.python.org/file26304/urllib-request-cleanup-builtin-names.patch

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

From report at bugs.python.org  Sat Jul  7 17:37:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:37:22 +0000
Subject: [New-bugs-announce] [issue15281] pyvenv --symlinks option is a
	no-op?
Message-ID: <1341675442.68.0.329348823606.issue15281@psf.upfronthosting.co.za>


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


----------
nosy: pitrou
priority: normal
severity: normal
status: open
title: pyvenv --symlinks option is a no-op?

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

From report at bugs.python.org  Sat Jul  7 17:52:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:52:26 +0000
Subject: [New-bugs-announce] [issue15282] pysetup still installed
Message-ID: <1341676346.69.0.778811662054.issue15282@psf.upfronthosting.co.za>


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

It seems to have eschewed the packaging removal.

$ rm /home/antoine/opt/bin/pysetup3.3 
$ make altinstall > /dev/null
$ pysetup3.3 
Traceback (most recent call last):
  File "/home/antoine/opt/bin/pysetup3.3", line 3, in <module>
    from packaging.run import main
  File "<frozen importlib._bootstrap>", line 1294, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1245, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1294, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1258, in _find_and_load_unlocked
ImportError: No module named 'packaging'

----------
components: Build, Library (Lib)
messages: 164887
nosy: eric.araujo, georg.brandl, pitrou
priority: release blocker
severity: normal
status: open
title: pysetup still installed
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 17:55:17 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 15:55:17 +0000
Subject: [New-bugs-announce] [issue15283] pyvenv says nothing on success
Message-ID: <1341676517.75.0.848646137047.issue15283@psf.upfronthosting.co.za>


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

$ pyvenv-3.3 env
$

It could tell me that I need to go into the directory and type "source bin/activate" (this is probably platform-dependent :-)).

----------
components: Demos and Tools, Library (Lib)
messages: 164891
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: pyvenv says nothing on success
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 18:01:44 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 16:01:44 +0000
Subject: [New-bugs-announce] [issue15284] Handle ipv6 not being enabled in
	test_socket
Message-ID: <1341676904.33.0.668096531532.issue15284@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

If ipv6 is compiled in but disabled in the kernel then test_socket attempts to bind to ports and gets lots of stack traces. The attached patch skips the relevant tests.

----------
components: Tests
files: ipv6-disabled-test-socket.patch
keywords: patch
messages: 164893
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Handle ipv6 not being enabled in test_socket
versions: Python 3.4
Added file: http://bugs.python.org/file26305/ipv6-disabled-test-socket.patch

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

From report at bugs.python.org  Sat Jul  7 18:27:03 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 16:27:03 +0000
Subject: [New-bugs-announce] [issue15285] test_timeout failure on OSX
Message-ID: <1341678423.78.0.865179228191.issue15285@psf.upfronthosting.co.za>


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

I have this repeatable failure on OSX.


$ time ./python.exe -m test.regrtest -uall -W test_timeout
[1/1] test_timeout
testBlockingThenTimeout (test.test_timeout.CreationTestCase) ... ok
testFloatReturnValue (test.test_timeout.CreationTestCase) ... ok
testObjectCreation (test.test_timeout.CreationTestCase) ... ok
testRangeCheck (test.test_timeout.CreationTestCase) ... ok
testReturnType (test.test_timeout.CreationTestCase) ... ok
testTimeoutThenBlocking (test.test_timeout.CreationTestCase) ... ok
testTypeCheck (test.test_timeout.CreationTestCase) ... ok
testAcceptTimeout (test.test_timeout.TCPTimeoutTestCase) ... ok
testConnectTimeout (test.test_timeout.TCPTimeoutTestCase) ... ERROR
testRecvTimeout (test.test_timeout.TCPTimeoutTestCase) ... ok
testSend (test.test_timeout.TCPTimeoutTestCase) ... ok
testSendall (test.test_timeout.TCPTimeoutTestCase) ... ok
testSendto (test.test_timeout.TCPTimeoutTestCase) ... ok
testRecvfromTimeout (test.test_timeout.UDPTimeoutTestCase) ... ok

======================================================================
ERROR: testConnectTimeout (test.test_timeout.TCPTimeoutTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_timeout.py", line 148, in testConnectTimeout
    self._sock_operation(1, 0.001, 'connect', addr)
  File "./Lib/test/test_timeout.py", line 119, in _sock_operation
    method(*args)
PermissionError: [Errno 13] Permission denied

----------------------------------------------------------------------
Ran 14 tests in 9.406s

FAILED (errors=1)
test test_timeout failed
1 test failed:
    test_timeout
[105213 refs]

real	0m9.907s
user	0m0.432s
sys	0m0.038s

----------
components: Library (Lib)
messages: 164906
nosy: flox
priority: normal
severity: normal
status: open
title: test_timeout failure on OSX
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 18:47:22 2012
From: report at bugs.python.org (Manuel de la Pena)
Date: Sat, 07 Jul 2012 16:47:22 +0000
Subject: [New-bugs-announce] [issue15286] normpath does not work with local
	literal paths
Message-ID: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>


New submission from Manuel de la Pena <manuel at canonical.com>:

Local literal paths are those paths that do use the \\?\ that allows to have paths longer that the MAX_PATH set by Windows (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#short_vs._long_names).

While UNC (http://en.wikipedia.org/wiki/Path_%28computing%29) paths should not be normalized, local paths that do use the \\?\ prefix should so that developers that use such a trink to allow longer paths on windows do not have to wrapp the call in the following way:

LONG_PATH_PREFIX = '\\?\'
path = path.replace(LONG_PATH_PREFIX, '')
result = LONG_PATH_PREFIX + os.path.normpath(path)

The possible solution would be for the normalization to work and return the path normalized with the prefix added.

----------
components: Windows
files: literal-normpath.patch
hgrepos: 141
keywords: patch
messages: 164909
nosy: mandel
priority: normal
severity: normal
status: open
title: normpath does not work with local literal paths
versions: Python 3.3
Added file: http://bugs.python.org/file26307/literal-normpath.patch

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

From report at bugs.python.org  Sat Jul  7 19:05:37 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 17:05:37 +0000
Subject: [New-bugs-announce] [issue15287] support.TESTFN was modified by
	test_builtin
Message-ID: <1341680737.17.0.537689488226.issue15287@psf.upfronthosting.co.za>


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

There's a warning running test_builtin


$ ./python.exe -m test.regrtest -u all -v test_builtin
== CPython 3.3.0b1 (default:5b71f5891c54, Jul 7 2012, 17:47:30) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-10.8.0-i386-64bit little-endian
==   ./build/test_python_77737
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_builtin
...

----------------------------------------------------------------------
Ran 59 tests in 0.114s

OK
Warning -- support.TESTFN was modified by test_builtin
1 test altered the execution environment:
    test_builtin
[115658 refs]

----------
assignee: ronaldoussoren
components: Macintosh, Tests
messages: 164912
nosy: flox, ronaldoussoren
priority: normal
severity: normal
status: open
title: support.TESTFN was modified by test_builtin
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 20:15:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 18:15:57 +0000
Subject: [New-bugs-announce] [issue15288] Clarify the
	pkgutil.walk_packages() note
Message-ID: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The note at the end of the pkgutil.walk_packages() (and iter_modules()) documentation can be improved somewhat:

http://docs.python.org/dev/library/pkgutil.html#pkgutil.walk_packages

For example, "importers" aren't referenced earlier in the documentation of the function, so it's not immediately clear what they are referring to.  I also think that enough information should be given so that one can run the examples given and have them work.  They currently don't.

I can put together proposed wording.  See the issue 14982 discussion for background.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164916
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Clarify the pkgutil.walk_packages() note
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 21:47:57 2012
From: report at bugs.python.org (samwyse)
Date: Sat, 07 Jul 2012 19:47:57 +0000
Subject: [New-bugs-announce] [issue15289] Adding __getitem__ as a class
	method doesn't work as	expected
Message-ID: <1341690477.89.0.147882600288.issue15289@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

I'm using a class as a decorator, and saving information in a class variable.  I wanted to access the information via a __getitem__ class method, but using conventional syntax doesn't work on a class.  The following exception is thrown when the attached script is run.

Traceback (most recent call last):
  File "/Users/sam/Documents/forth.py", line 34, in <module>
    print Alias["f'"]
TypeError: 'type' object has no attribute '__getitem__'

----------
components: None
files: 20120607.py
messages: 164926
nosy: samwyse
priority: normal
severity: normal
status: open
title: Adding __getitem__ as a class method doesn't work as expected
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26309/20120607.py

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

From report at bugs.python.org  Sun Jul  8 01:32:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 23:32:44 +0000
Subject: [New-bugs-announce] [issue15290] setAttribute() can fail
Message-ID: <1341703964.25.0.272780923096.issue15290@psf.upfronthosting.co.za>


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

This is a regression from 3.2:

Traceback (most recent call last):
  File "/home/antoine/3sted/twisted/lore/test/test_lore.py", line 542, in test_setTitle
    secondTitle.setAttribute('class', 'title')
  File "/home/antoine/opt/lib/python3.3/xml/dom/minidom.py", line 743, in setAttribute
    attr.ownerDocument = self.ownerDocument
builtins.AttributeError: ownerDocument

----------
components: Library (Lib)
messages: 164954
nosy: loewis, pitrou
priority: high
severity: normal
status: open
title: setAttribute() can fail
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  8 12:18:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:18:05 +0000
Subject: [New-bugs-announce] [issue15291] test_ast leaks memory a lot
Message-ID: <1341742685.49.0.71637329292.issue15291@psf.upfronthosting.co.za>


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

On the default branch, if you run test_ast in a loop:

./python -E -m test -F test_ast

you will see that the process memory use grows very quickly. This doesn't happen on 3.2.
I'm not a Valgrind expert so perhaps someone else can take a look. Otherwise I'll try to bisect.

----------
components: Interpreter Core
messages: 164992
nosy: neologix, pitrou, skrah
priority: critical
severity: normal
status: open
title: test_ast leaks memory a lot
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  8 12:38:20 2012
From: report at bugs.python.org (Anders Hammarquist)
Date: Sun, 08 Jul 2012 10:38:20 +0000
Subject: [New-bugs-announce] [issue15292] import hook behavior documentation
	improvement
Message-ID: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>


New submission from Anders Hammarquist <iko at iko.pp.se>:

When testing Eutaxia on PyPy (1.9) I discovered a discrepancy in the path_hooks import hook implementation. In CPython (2.7), if the find_module() method raises ImportError (as imp.find_module() does when it does not find a module in the given path), will cause the search to continue, whereas PyPy would propagate the ImportError.

PyPy has now been changed to behave like CPython.

The documentation is not entirely clear, but it does not explicitly document the import hook mechanism as eating an ImportError in find_module(). It should probably be made explicit, which ever way it should be. It is not obvious what is the correct behaviour, given the implicit relative imports, where the ImportError simply means that the import hook cannot find the module.

Quick testing on CPython 3.3 indicates that it behaves like PyPy did, but as it doesn't do implicit relative imports my test case didn't work as it was. For 3.3, without implicit relative imports, propagating the ImportError feels like the correct behaviour.

The attached demonstration needs a file /tmp/test/foo.py that does a top-level import, e.g. "import errno" to demonstrate the discrepancy.

----------
assignee: docs at python
components: Documentation
files: testimport.py
messages: 164998
nosy: docs at python, iko
priority: normal
severity: normal
status: open
title: import hook behavior documentation improvement
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26315/testimport.py

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

From report at bugs.python.org  Sun Jul  8 12:47:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:47:34 +0000
Subject: [New-bugs-announce] [issue15293] AST nodes do not support garbage
	collection
Message-ID: <1341744454.01.0.740763019773.issue15293@psf.upfronthosting.co.za>


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

Add the following to test_ast:

diff --git a/Lib/test/test_ast.py b/Lib/test/test_ast.py
--- a/Lib/test/test_ast.py
+++ b/Lib/test/test_ast.py
@@ -199,6 +199,7 @@ class AST_Tests(unittest.TestCase):
         x.foobar = 42
         self.assertEqual(x.foobar, 42)
         self.assertEqual(x.__dict__["foobar"], 42)
+        x.x = x
 
         with self.assertRaises(AttributeError):
             x.vararg


and you'll get a reference leak.

----------
assignee: benjamin.peterson
components: Interpreter Core
messages: 165001
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: AST nodes do not support garbage collection
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  8 15:16:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 13:16:05 +0000
Subject: [New-bugs-announce] [issue15294] regression with nested namespace
	packages
Message-ID: <1341753365.82.0.907088897601.issue15294@psf.upfronthosting.co.za>


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

Legacy namespace packages (handled with pkgutil) do not work anymore when they are nested. The attached test file passes under 3.2 but fails under 3.3.

----------
components: Interpreter Core
files: test_nested_nspackage.py
messages: 165014
nosy: brett.cannon, eric.snow, ncoghlan, pitrou
priority: high
severity: normal
status: open
title: regression with nested namespace packages
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26318/test_nested_nspackage.py

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

From report at bugs.python.org  Sun Jul  8 15:44:43 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 13:44:43 +0000
Subject: [New-bugs-announce] [issue15295] Document PEP 420 namespace packages
Message-ID: <1341755083.83.0.00364845964194.issue15295@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

I believe Barry said he was going to handle the documentation for PEP 420.

----------
assignee: barry
components: Documentation
messages: 165017
nosy: barry, brett.cannon
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document PEP 420 namespace packages
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  8 17:31:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Jul 2012 15:31:04 +0000
Subject: [New-bugs-announce] [issue15296] Minidom can't create ASCII
	representation
Message-ID: <1341761464.17.0.485570736364.issue15296@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Minidom can parse ASCII-encoded XML data, but can't create it.

>>> from xml.dom.minidom import parseString
>>> doc = parseString(b'<?xml version="1.0" encoding="us-ascii"?><foo>&#x20ac;</foo>')
>>> doc.toxml('us-ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 47, in toxml
    return self.toprettyxml("", "", encoding)
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 56, in toprettyxml
    self.writexml(writer, "", indent, newl, encoding)
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 1798, in writexml
    node.writexml(writer, indent, addindent, newl)
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 868, in writexml
    self.childNodes[0].writexml(writer, '', '', '')
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 1090, in writexml
    _write_data(writer, "%s%s%s" % (indent, self.data, newl))
  File "/home/serhiy/py/cpython/Lib/xml/dom/minidom.py", line 304, in _write_data
    writer.write(data)
  File "/home/serhiy/py/cpython/Lib/codecs.py", line 355, in write
    data, consumed = self.encode(object, self.errors)
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 0: ordinal not in range(128)

Same for other non-unicode encodings.

Suggested simple patch solves this issue.

----------
components: Library (Lib), Unicode, XML
files: minidom_toxml_encoding.patch
keywords: patch
messages: 165020
nosy: ezio.melotti, storchaka
priority: normal
severity: normal
status: open
title: Minidom can't create ASCII representation
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26319/minidom_toxml_encoding.patch

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

From report at bugs.python.org  Sun Jul  8 23:13:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 21:13:00 +0000
Subject: [New-bugs-announce] [issue15297] pkgutil.iter_importers() includes
	an ImpImporter
Message-ID: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I'm not sure if this should be fixed in the code or in the documentation, but the pkgutil.iter_importers() documentation says that pkgutil.iter_importers(name) should yield the "importers for sys.meta_path, sys.path, and Python?s ?classic? import machinery, in that order" when name does not include a ".":

http://docs.python.org/dev/library/pkgutil.html#pkgutil.iter_importers

However, the function appends a "non-classic" pkgutil.ImpImporter at the end of all that:

Python 3.3.0b1 (default:5d43154d68a8, Jul  8 2012, 13:54:45) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> from pkgutil import iter_importers
>>> list(iter_importers())[-1]
<pkgutil.ImpImporter object at 0x1035fa840>

----------
components: Library (Lib)
messages: 165035
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: pkgutil.iter_importers() includes an ImpImporter
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  8 23:26:16 2012
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 08 Jul 2012 21:26:16 +0000
Subject: [New-bugs-announce] [issue15298] _sysconfigdata is generated in
	srcdir, not builddir
Message-ID: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

_sysconfigdata is generated in srcdir, not builddir, so if you do two consecutive differently builds in different builddirs and using the same srcdir, then the _sysconfigdata of the second build wins. _sysconfigdata.py has to be built in the builddir, not the srcdir.

----------
components: Build
messages: 165036
nosy: doko
priority: release blocker
severity: normal
status: open
title: _sysconfigdata is generated in srcdir, not builddir
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  8 23:48:07 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 21:48:07 +0000
Subject: [New-bugs-announce] [issue15299] ImpImporter(None).iter_modules()
	does not search sys.path
Message-ID: <1341784087.15.0.754005593473.issue15299@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The pkgutil.ImpImporter documentation says that if dirname is None, ImpImporter(dirname) should create a PEP 302 importer that searches the current sys.path, plus any modules that are frozen or built-in:

http://docs.python.org/dev/library/pkgutil.html#pkgutil.ImpImporter

However, the iter_modules() method of an ImpImporter instance doesn't search sys.path if dirname is None.  It returns a generator that always yields nothing.  For example--

Python 3.3.0b1 (default:5d43154d68a8, Jul  8 2012, 13:54:45) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> from pkgutil import ImpImporter
>>> importer = ImpImporter()
>>> list(importer.iter_modules())
[]

Strictly speaking, one could say the documentation only applies to the find_module() method since that's the only method covered by the PEP 302 API  However, iter_modules() is a public method.  So I think that either iter_modules() should be fixed, made private, or else the documentation clarified by saying that searching sys.path does not apply to iter_modules().

I'm pretty sure though that iter_modules() should be fixed.  This is because there are other functions in pkgutil that seem not to work because ImpImporter.iter_modules() behaves the way it does (specifically calling pkgutil.iter_modules() with path=None).

----------
components: Library (Lib)
messages: 165038
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: ImpImporter(None).iter_modules() does not search sys.path
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul  9 03:09:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 01:09:26 +0000
Subject: [New-bugs-announce] [issue15300] test directory doubly-nested
	running tests with	-j/--multiprocess
Message-ID: <1341796166.56.0.21692098812.issue15300@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Running tests using the -j/--multiprocess option doubly-nests the test working directory:

$ ./python.exe -m test -j3 
-->cpython/build/test_python_63955/build/test_python_63956 
$ ./python.exe -m test
-->cpython/build/test_python_63957

It seems like the test directories for different processes should be siblings when running in multiprocessing mode as opposed to doubly-nesting under a new build directory.

----------
components: Tests
messages: 165052
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: test directory doubly-nested running tests with -j/--multiprocess
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul  9 04:15:39 2012
From: report at bugs.python.org (do1)
Date: Mon, 09 Jul 2012 02:15:39 +0000
Subject: [New-bugs-announce] [issue15301] os.chown: OverflowError: Python
	int too large to convert	to C long
Message-ID: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>


New submission from do1 <do1 at yandex.ru>:

os.chown() can not change uid/gid to valid but high number.

# chown 4294967294.4294967294 a
# ls -l a
-rw-r--r-- 1 4294967294 4294967294 0 Jul  9 05:22 a

# python
Python 2.7.3 (default, Jun 24 2012, 06:19:44)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.chown("a", 4294967294, 4294967294)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

----------
components: None
messages: 165053
nosy: do1
priority: normal
severity: normal
status: open
title: os.chown: OverflowError: Python int too large to convert to C long
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  9 07:26:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 05:26:23 +0000
Subject: [New-bugs-announce] [issue15302] Use argparse instead of getopt in
	test.regrtest
Message-ID: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would be an improvement to switch from using getopt to argparse in test.regrtest.  The code would be easier to maintain, it would give us more powerful options going forward, and it would improve the usability of the test command (e.g. nicer command-line help).

----------
components: Tests
keywords: easy
messages: 165064
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Use argparse instead of getopt in test.regrtest
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul  9 10:25:50 2012
From: report at bugs.python.org (Drew French)
Date: Mon, 09 Jul 2012 08:25:50 +0000
Subject: [New-bugs-announce] [issue15303] Minor revision to the
	<BaseWidget._setup> method in	Tkinter
Message-ID: <1341822350.55.0.995662615633.issue15303@psf.upfronthosting.co.za>


New submission from Drew French <rectangletangle at gmail.com>:

In the <BaseWidget._setup> method, <master> is evaluated as a Boolean (when Tkinter attempts to find a parent for the widget). I think it should really be evaluated against <None>, seeing as that is the default <master> keyword argument value for most widgets. I ran into problems with this when making a container widget class that inherited from the <Canvas>, then implementing the <__len__> magic method. When the length was zero the widget would evaluate as false, which would prevented me from packing widgets inside my container widget.

I attached a revised version of the method.

----------
components: Tkinter
files: tkbugfix.py
messages: 165070
nosy: Drew.French
priority: normal
severity: normal
status: open
title: Minor revision to the <BaseWidget._setup> method in Tkinter
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26326/tkbugfix.py

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

From report at bugs.python.org  Mon Jul  9 13:27:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 11:27:19 +0000
Subject: [New-bugs-announce] [issue15304] Wrong path in
	test.support.temp_cwd() error message
Message-ID: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

test.support.temp_cwd() has a typo (s/name/path/):

try:
    os.chdir(path)
except OSError:
    if not quiet:
        raise
    warnings.warn('tests may fail, unable to change the CWD to ' + name,
                  RuntimeWarning, stacklevel=3)

----------
components: Tests
keywords: easy
messages: 165075
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Wrong path in test.support.temp_cwd() error message
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul  9 13:45:51 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 11:45:51 +0000
Subject: [New-bugs-announce] [issue15305] Test harness unnecessarily
	disambiguating twice
Message-ID: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

It seems like our test harness is disambiguating more than it needs to for parallel testing.

In Lib/test/regrtest.py, we do this--

# Define a writable temp dir that will be used as cwd while running
# the tests. The name of the dir includes the pid to allow parallel
# testing (see the -j option).
TESTCWD = 'test_python_{}'.format(os.getpid())
...
with support.temp_cwd(TESTCWD, quiet=True):
    main()

And then in Lib/test/support.py, we are doing this--

# Disambiguate TESTFN for parallel testing, while letting it remain a valid
# module name.
TESTFN = "{}_{}_tmp".format(TESTFN, os.getpid())

with uses like--

with open(TESTFN, "wb") as f:
    # Do stuff with f.

It seems like only one of these measures should be necessary (a single working directory for all parallel tests using a disambiguated TESTFN, or one working directory for each process with a non-disambiguated TESTFN).

----------
components: Tests
keywords: easy
messages: 165077
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Test harness unnecessarily disambiguating twice
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul  9 16:35:49 2012
From: report at bugs.python.org (Ztatik Light)
Date: Mon, 09 Jul 2012 14:35:49 +0000
Subject: [New-bugs-announce] [issue15306] Python3 segfault? (works in
	Python2)
Message-ID: <1341844549.14.0.695574663066.issue15306@psf.upfronthosting.co.za>


New submission from Ztatik Light <ztatik.light at gmail.com>:

I think I've found a bug ...

The issue is that it works fine on Python2 but segfaults on Python3.. (The second to last line causes the crash)

Tested on v2.6.6 and 3.1.3:

(Must have libfreetype6 and the TTF specified on 5th to last line [if on Windows, simple download libfreetype6 here: http://tinyurl.com/7dvgffw and replace the '.ttf' string with any existing .ttf file])

[File attached as 'test.py']

----------
components: IO, Interpreter Core, Library (Lib), None, ctypes
files: test.py
messages: 165084
nosy: Ztatik.Light
priority: normal
severity: normal
status: open
title: Python3 segfault? (works in Python2)
type: crash
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file26330/test.py

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

From report at bugs.python.org  Mon Jul  9 17:13:41 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 09 Jul 2012 15:13:41 +0000
Subject: [New-bugs-announce] [issue15307] Patch for --symlink support in
	pyvenv with framework	python
Message-ID: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>


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

The attached patch ensures that "python3.3 -mvenv --symlinks myenv" works with framework builds.

There are two functional changes:
1) don't call 'realpath' in pythonw.c because realpath resolves
   symlinks and that breaks the '--symlinks' options because the
   python command is a symlink with that option (and resolving that
   gives the path to the python executable in the framework)

2) Look for the __PYVENV_LAUNCHER__ environment variable in
   Modules/getpath.c and use that in preference on the already
   calculated value of argv0_path. That code is only active for
   framework builds

I'm not happy with the following line in this patch:

+            wcsncpy(argv0_path, (wchar_t*)pyvenv_launcher, MAXPATHLEN);

That mirrors a similar cast of the result of NSLibraryNameForModule earlier in Modules/getpath.c, but in both cases the input stream is a narrow character string ("char", not "wchar_t") and wcsncpy expects a "wchar_t". The the cast seems to paper over a real problem here.

Shouldn't both lines use "_Py_char2wchar" to convert the char* buffer to a wchar_t* one?

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: venv-symlinks.txt
keywords: needs review, patch
messages: 165087
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Patch for --symlink support in pyvenv with framework python
versions: Python 3.3
Added file: http://bugs.python.org/file26332/venv-symlinks.txt

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

From report at bugs.python.org  Mon Jul  9 22:24:51 2012
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Jul 2012 20:24:51 +0000
Subject: [New-bugs-announce] [issue15308] IDLE - add an "Interrupt
	Execution" to shell menu
Message-ID: <1341865491.11.0.0892141451607.issue15308@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Add an "Interrupt Execution" to the Shell menu, per issue13504, annoyance #3 - "PROBLEM: There?s no obvious way to stop a running program. (Don?t expect them to know Ctrl-C)"

----------
components: IDLE
keywords: easy
messages: 165122
nosy: serwy, terry.reedy
priority: low
severity: normal
status: open
title: IDLE - add an "Interrupt Execution" to shell menu
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Jul  9 23:21:54 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Mon, 09 Jul 2012 21:21:54 +0000
Subject: [New-bugs-announce] [issue15309] buffer/memoryview slice assignment
	uses only memcpy
Message-ID: <1341868914.24.0.978840322443.issue15309@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

thats broken for assigning overlaping regions, the memcpy docs explicitly state that memmove should be used in overlap cases

----------
messages: 165127
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: buffer/memoryview slice assignment uses only memcpy
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/issue15309>
_______________________________________

From report at bugs.python.org  Tue Jul 10 00:40:49 2012
From: report at bugs.python.org (Thomas Parslow)
Date: Mon, 09 Jul 2012 22:40:49 +0000
Subject: [New-bugs-announce] [issue15310] urllib: Support for multiple
	WWW-Authenticate headers	and/or multiple challenges per header
Message-ID: <1341873649.53.0.673715238265.issue15310@psf.upfronthosting.co.za>


New submission from Thomas Parslow <tom at almostobsolete.net>:

The HTTP spec specifies that the 401 (Unauthorized) response can be accompanied by multiple challenges, either as separate WWW-Authenticate headers or in a single WWW-Authenticate header separated by commas. The client should always pick the strongest supported which in the case of urllib is "digest". Unknown challenge types (for urllib that's anything but "basic" and "digest") should be ignored as long as there is a known one as well.

This is my first patch submission to cpython so please do point out anything I've done wrong! I'd like do more work on cpython so best to nip any bad habits in the bud!

In this patch I've re-written the parsing code to support this. I've tried to re-use existing code as much as possible, so I've based the new parser on the existing parse_http_list which I had to extend so that it can be used to parse single quoted strings. These single quoted strings are not valid for the HTTP spec but apparently they do appear in the wild and the existing implementation allowed them so I've continued to allow them. I've also kept the existing behaviour with regards to unquoted realm values, a warning is raised but otherwise they are allowed. The requirement of raising the warning added a slightly awkward bit to the code, but I assumed there was a good reason for that warning being there so I kept it in.

----------
components: Library (Lib)
files: urllib-multi-authenticate-challenges.patch
keywords: patch
messages: 165132
nosy: almost
priority: normal
severity: normal
status: open
title: urllib: Support for multiple WWW-Authenticate headers and/or multiple challenges per header
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26337/urllib-multi-authenticate-challenges.patch

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

From report at bugs.python.org  Tue Jul 10 02:40:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 00:40:20 +0000
Subject: [New-bugs-announce] [issue15311] Developer Guide doesn't get
	updated once a day
Message-ID: <1341880820.83.0.419912780964.issue15311@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The Dev Guide says that it is "managed using the same process as is used for the main Python documentation":

http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide

However, it looks the Dev Guide might not be on the same schedule of getting updated once a day as it says for the main Python documentation:

http://docs.python.org/devguide/docquality.html#helping-with-documentation

It would help to say something about the mechanism by which the Dev Guide gets updated if that mechanism is different from the main Python documentation.

----------
components: Devguide
keywords: easy
messages: 165138
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: Developer Guide doesn't get updated once a day
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 10 04:09:51 2012
From: report at bugs.python.org (Julius)
Date: Tue, 10 Jul 2012 02:09:51 +0000
Subject: [New-bugs-announce] [issue15312] Serial library not found
Message-ID: <1341886191.07.0.139059548156.issue15312@psf.upfronthosting.co.za>


New submission from Julius <julius.miller at bravo-zulu.us>:

I'm running ver 2.7 and added the serial library from source forge. here is the error I get:

Traceback (most recent call last):
  File "C:\Python27\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 326, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Documents and Settings\Administrator\My Documents\WTF.py", line 3, in <module>
    import serial
ImportError: No module named serial

here is my code:
# Echo client program
import socket
import serial

HOST = '216.240.155.229'    # The remote host
PORT = 9090              # The same port as used by the server
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
ser = serial.Serial('USB0', timeout=3)
x = 0
#while x < 5:
while True:
    msg = ser.readline()
    s.send(msg)
    x += 1
s.close()

----------
components: Extension Modules, IDLE, Windows
messages: 165141
nosy: JuliusMiller
priority: normal
severity: normal
status: open
title: Serial library not found
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 10 04:27:04 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 02:27:04 +0000
Subject: [New-bugs-announce] [issue15313] IDLE - remove all bare excepts
Message-ID: <1341887224.3.0.873205918404.issue15313@psf.upfronthosting.co.za>


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


----------
components: IDLE
nosy: serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - remove all bare excepts
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Jul 10 05:50:37 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Jul 2012 03:50:37 +0000
Subject: [New-bugs-announce] [issue15314] Use importlib instead of pkgutil
	in runpy
Message-ID: <1341892237.06.0.600347748801.issue15314@psf.upfronthosting.co.za>


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

There's some lingering weirdness in runpy due to its reliance on pkgutil's import emulation (see #15272).

For 3.3, I'd like to explicitly switch runpy over to using importlib. This was supposed to happen automatically, but the relevant API is "importlib.find_loader" rather than the "imp.get_loader" that runpy is currently looking for.

----------
assignee: ncoghlan
messages: 165153
nosy: georg.brandl, ncoghlan
priority: high
severity: normal
stage: needs patch
status: open
title: Use importlib instead of pkgutil in runpy
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 10 06:52:03 2012
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 10 Jul 2012 04:52:03 +0000
Subject: [New-bugs-announce] [issue15315] Can't build Python extension with
	mingw32 on Windows
Message-ID: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I'm trying this with my 'cobs' Python package:

    c:\Python33\python.exe setup.py build --compiler=mingw32 bdist_msi

With Python 3.3 beta, it fails with an exception:

    ValueError: Unknown MS Compiler version 1600

It works with Python 3.2.

----------
components: Extension Modules
messages: 165159
nosy: cmcqueen1975
priority: normal
severity: normal
status: open
title: Can't build Python extension with mingw32 on Windows
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 10 07:39:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 05:39:18 +0000
Subject: [New-bugs-announce] [issue15316] runpy swallows ImportError
	information with relative	imports
Message-ID: <1341898758.4.0.623810416258.issue15316@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

With the following package directory structure--

foo/
    __init__.py
    __main__.py
        from foo import bar
    bar.py
        print('***')
        raise ImportError('test...')

Running--

$ ./python.exe -m foo

Yields--

***
Traceback (most recent call last):
  File ".../python/cpython/cpython/Lib/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File ".../python/cpython/cpython/Lib/runpy.py", line 75, in _run_code
    exec(code, run_globals)
  File "./foo/__main__.py", line 1, in <module>
    from foo import bar
ImportError: cannot import name bar
$

The exception text gets swallowed.

Changing the relative import "from foo import bar" to "import foo.bar" does show the exception text.

----------
components: Library (Lib)
messages: 165166
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: runpy swallows ImportError information with relative imports
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 10 09:21:17 2012
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Tue, 10 Jul 2012 07:21:17 +0000
Subject: [New-bugs-announce] [issue15317] Source installation sets incorrect
	permissions for	Grammar3.2.3.final.0.pickle
Message-ID: <1341904877.85.0.287783743443.issue15317@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen <tomi.pievilainen+launchpad at iki.fi>:

/usr/local/lib/python3.2/lib2to3/Grammar3.2.3.final.0.pickle is readable only by root after installing with make install from the source package. This makes at least installing distribute fail, and thus makes virtualenv, tox etc. unusable.

----------
components: Installation
messages: 165171
nosy: tpievila
priority: normal
severity: normal
status: open
title: Source installation sets incorrect permissions for Grammar3.2.3.final.0.pickle
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 10 16:13:24 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 14:13:24 +0000
Subject: [New-bugs-announce] [issue15318] IDLE - sys.stdin is writeable
Message-ID: <1341929604.75.0.527564575398.issue15318@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

This is a follow-up to issue13532 which fixed problems with IDLE's sys.stdout and sys.stderr implementation.

Presently, sys.stdin has a write method, but does not raise "io.UnsupportedOperation: not writable" when passed a string. Instead, it writes to the IDLE shell.

----------
components: IDLE
messages: 165190
nosy: serwy, storchaka, terry.reedy
priority: low
severity: normal
status: open
title: IDLE - sys.stdin is writeable
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Jul 10 21:28:48 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 10 Jul 2012 19:28:48 +0000
Subject: [New-bugs-announce] [issue15319] IDLE - input() is broken.
Message-ID: <1341948528.44.0.0917109558085.issue15319@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Per Martin's request in msg165197, this issue has been separated from Issue13532.

The newly introduced _RPCFile object in run.py (422242dbce30) inherits from io.TextIOBase which has "readline" as one of its methods. As a result, IDLE's internal call readline are not handled properly.

The stdin_fix.patch provides a fix for readline and isatty.

----------
components: IDLE
files: stdin_fix.patch
keywords: patch
messages: 165198
nosy: loewis, ned.deily, serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - input() is broken.
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file26344/stdin_fix.patch

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

From report at bugs.python.org  Tue Jul 10 22:50:37 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 10 Jul 2012 20:50:37 +0000
Subject: [New-bugs-announce] [issue15320] thread-safety issue in
	regrtest.main()
Message-ID: <1341953437.79.0.355330793609.issue15320@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

My understanding is that generators are not thread-safe.  For example, see

http://stackoverflow.com/a/1131458/262819

However, regrtest.main() seems to access a generator from multiple threads when run in multiprocess mode:

def work():
    # A worker thread.
    try:
        while True:
            try:
                test, args_tuple = next(pending)
            except StopIteration:
                output.put((None, None, None, None))
                return

http://hg.python.org/cpython/file/2ecdda96f970/Lib/test/regrtest.py#l632

----------
components: Tests
keywords: easy
messages: 165203
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: thread-safety issue in regrtest.main()
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 11 02:08:29 2012
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 11 Jul 2012 00:08:29 +0000
Subject: [New-bugs-announce] [issue15321] bdist_wininst installers may
	terminate with "close	failed in file object
	destructor:\nsys.excepthook is	missing\nlost sys.stderr"
Message-ID: <1341965309.27.0.878027505194.issue15321@psf.upfronthosting.co.za>


New submission from Mark Hammond <skippy.hammond at gmail.com>:

Note the error message in the title is only for Python 2.x - Python 3.x shows an empty string instead, but otherwise seems identical.

This was first brought to my attention via http://sourceforge.net/tracker/?func=detail&aid=3528888&group_id=78018&atid=551954.  I can reproduce it (see below) with the pywin32 installer but believe the problem will exist with any such installer.  All tests done on a Win7x64 VM.  Symptoms are:

* Run the installer with UAC enabled - reliably works.  All "print" statements from the post-install script are shown in the final dialog.

* Disable UAC.  The installation reliably ends with the "close failed..." message shown in the final dialog.  No print output is shown.  The installation did actually complete (but is likely to fail if the output fills stdout buffering).  The UAC is probably relevant as when UAC is enabled, the installer re-spawns itself with elevation.

* The problem with UAC disabled can be reproduced running in the VS debugger.  The problem is that Python sees stdout and stderr with a FILE object that has a fileno of -2 (ie, of _NO_CONSOLE_FILENO).  Then, when Python is finalizing it tries to close these handles and fails due to the invalid fileno.  The other messages are a consequence of the fact stderr itself is what is being closed (ie, Python is trying to report a problem closing stderr to stderr.)  Python 3 seems to handle this case better courtesy of issue 1415, but the fact the output is lost remains in both versions.

* Looking over the installer code, I notice that Python is initialized and terminated twice to compile .pyc/.pyo, then initialized a third time in preparation to run the install script - the handles are redirected prior to initializing the 3rd time.  On a hunch, I hacked the code to perform the redirection *before* Python is initialized for the first time.  This solved the problem when run under the debugger but still failed when run stand-alone (*sigh*).  I fiddled with some params to CreateFile in the redirection code but could not get things working.  Note that avoiding the multiple init/finalize calls may be problematic as Py_OptimizeFlag is set differently between runs.

* I looked over the CRT init code to try and determine why _NO_CONSOLE_FILENO was being used.  It appears the CRT attempts to use the process STARTUPINFO and only falls back to GetStdHandle if that STARTUPINFO doesn't provide valid handles.  So I tried both using GetStartupInfo and putting the redirect handles in the result, and explicitly closing the old std handles, but neither of them worked.

Next step is probably to arrange to step through the CRT init code to see what is going on there.  I doubt I will get back to this any time soon, so this is my attempt at detailing what I've discovered to date incase someone else has a look...

----------
assignee: eric.araujo
components: Distutils
messages: 165213
nosy: eric.araujo, mhammond, tarek
priority: normal
severity: normal
status: open
title: bdist_wininst installers may terminate with "close failed in file object destructor:\nsys.excepthook is missing\nlost sys.stderr"
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/issue15321>
_______________________________________

From report at bugs.python.org  Wed Jul 11 04:08:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 02:08:28 +0000
Subject: [New-bugs-announce] [issue15322] sysconfig.get_config_var('srcdir')
	returns unexpected	value
Message-ID: <1341972508.31.0.0905523614322.issue15322@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

sysconfig.get_config_var('srcdir') seems to return the current working directory rather than a directory related to the source directory.

For example (starting from the repository root)--

$ mkdir foo
$ cd foo
$ ../python.exe 
Python 3.3.0b1 (default:5d43154d68a8, Jul  8 2012, 18:23:20) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> import sysconfig
>>> sysconfig.get_config_vars('srcdir')
['/.../cpython/foo']
>>> import sys
>>> sys.executable
'/.../cpython/foo/../python.exe'

This may be the cause or related to issue 15300: "test directory doubly-nested running tests with -j/--multiprocess".

----------
messages: 165219
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: sysconfig.get_config_var('srcdir') returns unexpected value
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 11 05:19:21 2012
From: report at bugs.python.org (Brian Jones)
Date: Wed, 11 Jul 2012 03:19:21 +0000
Subject: [New-bugs-announce] [issue15323] Provide target name in output
	message when	Mock.assert_called_once_with fails
Message-ID: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

In Python 3.3.0b1, if the number of calls to a mock is, say, zero, and you call assert_called_once_with() on that mock, it will throw an exception which says "Expected to be called once. Called 0 times."

This is nice, but it would be nicer if the output message actually told the end user *what* it expected to be called once. I've supplied a patch and documentation update that makes this change by adding _mock_name to the output message using the variable interpolation method already being used in that message to output the call count. 

The result looks like this (for the case in the documentation): 

Python 3.3.0b1 (default:2ecdda96f970+, Jul 10 2012, 22:45:18) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from unittest.mock import Mock
[103576 refs]
>>> mock = Mock(return_value=None)
[103641 refs]
>>> mock('foo', bar='baz')
[103679 refs]
>>> mock.assert_called_once_with('foo', bar='baz')
[103680 refs]
>>> mock('foo', bar='baz')
[103703 refs]
>>> mock.assert_called_once_with('foo', bar='baz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/brianj/Dropbox/Source/Python/cpython/Lib/unittest/mock.py", line 736, in assert_called_once_with
    raise AssertionError(msg)
AssertionError: Expected 'mock' to be called once. Called 2 times.
[103758 refs]

In the above case, the mock was never given a name, and wasn't instantiated with any particular target. Here's an example using a patch on 'time.time' to show the effect: 

Python 3.3.0b1 (default:2ecdda96f970+, Jul 10 2012, 22:45:18) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from unittest.mock import patch
[106009 refs]
>>> with patch('time.time') as foo:
...     foo.assert_called_once_with()
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/Users/brianj/Dropbox/Source/Python/cpython/Lib/unittest/mock.py", line 736, in assert_called_once_with
    raise AssertionError(msg)
AssertionError: Expected 'time' to be called once. Called 0 times.
[106621 refs]

----------
components: Library (Lib)
files: mock_assert_called_once_with_output_update.patch
keywords: patch
messages: 165223
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: Provide target name in output message when Mock.assert_called_once_with fails
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26348/mock_assert_called_once_with_output_update.patch

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

From report at bugs.python.org  Wed Jul 11 10:42:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 08:42:47 +0000
Subject: [New-bugs-announce] [issue15324] --match does not work for regrtest
Message-ID: <1341996167.29.0.670319499131.issue15324@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The long form of the -m/--match option does not work with regrtest because it does not accept an argument.  For example (observe the lack of an error in the second invocation)--

$ ./python.exe -m test -m 
option -m requires argument
Use --help for usage
$ ./python.exe -m test --match
== CPython 3.3.0b1 (default:5d43154d68a8, Jul 8 2012, 13:54:45) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)]
...

----------
keywords: easy
messages: 165235
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: --match does not work for regrtest
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 11 12:05:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 10:05:32 +0000
Subject: [New-bugs-announce] [issue15325] --fromfile does not work for
	regrtest
Message-ID: <1342001132.43.0.639678860969.issue15325@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The long form of the -f/--fromfile option does not work.  It does not read its required argument.  For example (observe that the second invocation raises no error)--

$ ./python.exe -m test -f
option -f requires argument
Use --help for usage
$ ./python.exe -m test --fromfile
== CPython 3.3.0b1 (default:5d43154d68a8, Jul 8 2012, 13:54:45) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)]

Note that issue 15302 will fix this.

----------
keywords: easy
messages: 165243
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: --fromfile does not work for regrtest
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 11 12:15:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 10:15:11 +0000
Subject: [New-bugs-announce] [issue15326] --random does not work for regrtest
Message-ID: <1342001711.01.0.48203802237.issue15326@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The long form of the -r/--random option does not work:

$ ./python.exe -m test --random
No handler for option --random.  Please report this as a bug at http://bugs.python.org.

Note that issue 15302 will fix this.

----------
components: Tests
keywords: easy
messages: 165246
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: --random does not work for regrtest
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 11 13:05:30 2012
From: report at bugs.python.org (Ingo Fischer)
Date: Wed, 11 Jul 2012 11:05:30 +0000
Subject: [New-bugs-announce] [issue15327] Argparse: main arguments and
	subparser arguments	indistinguishable
Message-ID: <1342004730.08.0.363281774737.issue15327@psf.upfronthosting.co.za>


New submission from Ingo Fischer <fredistdurstig at googlemail.com>:

I have an argument called '--verbose' in the main parser. 
Then I add a subparser called 'command', to which I add an argument with the same name '--verbose' (See attached script).

When I process these args, I cannot decide afterwards if the user called 'myscript --verbose command' or 'myscript command --verbose'. I always get the same Namespace object returned from parse_args.

IMHO the Namespace object should also provide informations about the source parser, to make main parser args and subparser args distinguishable. Also if I call 'myscript --verbose command --verbose', I should get both args in the resulting Namespace object.

----------
components: Library (Lib)
files: argparsetest.py
messages: 165248
nosy: Ingo.Fischer
priority: normal
severity: normal
status: open
title: Argparse: main arguments and subparser arguments indistinguishable
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file26356/argparsetest.py

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

From report at bugs.python.org  Wed Jul 11 16:00:21 2012
From: report at bugs.python.org (Lars Nordin)
Date: Wed, 11 Jul 2012 14:00:21 +0000
Subject: [New-bugs-announce] [issue15328] datetime.strptime slow
Message-ID: <1342015221.25.0.0683472526459.issue15328@psf.upfronthosting.co.za>


New submission from Lars Nordin <lars.nordin at gmail.com>:

The datetime.strptime works well enough for me it is just slow.

I recently added a comparison to a log parsing script to skip log lines earlier than a set date. After doing so my script ran much slower.
I am processing 4,784,212 log lines in 1,746 files.

Using Linux "time", the measured run time is:
real    5m12.884s
user    4m54.330s
sys     0m2.344s

Altering the script to cache the datetime object if the date string is the same, reduces the run time to: 
real    1m3.816s
user    0m49.635s
sys     0m1.696s

# --- code snippet ---
# start_dt calculated at script start
...
day_dt = datetime.datetime.strptime(day_str, "%Y-%m-%d")
if day_dt < start_dt:
...


$ python
import platform
print 'Version      :', platform.python_version()
print 'Version tuple:', platform.python_version_tuple()
print 'Compiler     :', platform.python_compiler()
print 'Build        :', platform.python_build()

Version      : 2.7.2+
Version tuple: ('2', '7', '2+')
Compiler     : GCC 4.6.1
Build        : ('default', 'Oct  4 2011 20:03:08')

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 11.10
Release:        11.10
Codename:       oneiric

----------
components: None
messages: 165256
nosy: Lars.Nordin
priority: normal
severity: normal
status: open
title: datetime.strptime slow
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 12 00:10:44 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 22:10:44 +0000
Subject: [New-bugs-announce] [issue15329] clarify which deque methods are
	thread-safe
Message-ID: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would help to clarify which collections.deque methods are thread-safe:

http://docs.python.org/dev/library/collections.html?highlight=deque#collections.deque

Currently, the documentation says that "Deques support thread-safe, memory efficient appends and pops from either side...," but it isn't obvious if this is meant to apply to all methods, or just the methods named append*() and pop*().

For example, is rotate() thread-safe?  The illustration given of d.appendleft(d.pop()) seems like it could be interleaved.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 165275
nosy: cjerdonek, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: clarify which deque methods are thread-safe
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jul 12 00:20:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 22:20:38 +0000
Subject: [New-bugs-announce] [issue15330] allow deque to act as a
	thread-safe circular buffer
Message-ID: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

It seems like it would be useful if collections.deque had a thread-safe method that could rotate(1) and return the rotated value.

This would let deque to act as a thread-safe circular buffer (e.g. if serving jobs to multiple threads in a loop, like `python -m test --forever`).

----------
components: Library (Lib)
messages: 165276
nosy: cjerdonek, rhettinger
priority: normal
severity: normal
status: open
title: allow deque to act as a thread-safe circular buffer
type: enhancement

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

From report at bugs.python.org  Thu Jul 12 13:04:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 Jul 2012 11:04:34 +0000
Subject: [New-bugs-announce] [issue15331] Missing codec aliases for
	bytes-bytes codecs
Message-ID: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>


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

In writing a post looking at a potentially different way of handling codec pipelines that is source compatible across both Python 2 and 3, I noticed that the bytes-bytes codec aliases are all missing but are still listed in the documentation as being supported:

base64_codec 	base64, base-64
bz2_codec 	bz2
hex_codec 	hex

quopri_codec 	quopri, quoted-printable, quotedprintable
uu_codec 	uu
zlib_codec 	zip, zlib

The canonical names (i.e. *_codec) all work as expected, though.

----------
messages: 165295
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Missing codec aliases for bytes-bytes codecs
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul 12 16:44:43 2012
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 12 Jul 2012 14:44:43 +0000
Subject: [New-bugs-announce] [issue15332] 2to3 should fix bad indentation
	(or warn about it)
Message-ID: <1342104283.46.0.0298718422519.issue15332@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

Python 3 is more rigid about mixing tabs and spaces within a single file. 2to3 should either fix indentation that would become a syntax error in Python 3.X, or maybe issue a warning about it (or both).

Example:

$ python badtabs.py && echo okay
okay

$ 2to3 badtabs.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.

$ python3 badtabs.py && echo okay
  File "badtabs.py", line 3
    'b'
      ^
TabError: inconsistent use of tabs and spaces in indentation

----------
components: 2to3 (2.x to 3.x conversion tool)
files: badtabs.py
messages: 165303
nosy: jwilk
priority: normal
severity: normal
status: open
title: 2to3 should fix bad indentation (or warn about it)
Added file: http://bugs.python.org/file26365/badtabs.py

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

From report at bugs.python.org  Thu Jul 12 17:32:21 2012
From: report at bugs.python.org (Andrew MacKeith)
Date: Thu, 12 Jul 2012 15:32:21 +0000
Subject: [New-bugs-announce] [issue15333] import on Windows will recompile a
	pyc file created on	Unix
Message-ID: <1342107141.38.0.530565804719.issue15333@psf.upfronthosting.co.za>


New submission from Andrew MacKeith <andrew at mackeith.net>:

In certain cases, a compiled Python file (.pyc) created on Unix will be recompiled when imported on Windows, despite the original code file (.py) being the same.
The cause is the use of the c fstat function in import.c.

This behavior is contrary to the stated Python behavior that a precompiled Python file is portable between platforms.

The fix to this bug would be to use the posixmodule stat implementation in place of fstat in import.c.

An example is the following, in Python 2.6.2:

This was tested on July 11th, 2012, USA EDT 
(i.e. DST is in effect, and local time is GMT - 6 hours). 
Lib/re.py has a mtime of 01/01/2009  11:46 AM according to Windows DIR.

Windows fstat st_mtime returns 1230828370 (0x495cf352) 16:46 GMT
Linux   fstat st_mtime returns 1230824770 (0x495ce542) 15:46 GMT

The effect of this is that when import opens the .pyc file and reads the mtime (the 2nd 4-byte field of the .pyc file) it sees it as "bad" and therefore recompiles the file.

The Python os.stat function works correctly on both Windows and Unix. There is a note in posixmodule.c that warns of a problem with Windows fstat:
"""
#ifdef MS_WINDOWS
/* The CRT of Windows has a number of flaws wrt. its stat() implementation:
   - time stamps are restricted to second resolution
   - file modification times suffer from forth-and-back conversions between
     UTC and local time
   Therefore, we implement our own stat, based on the Win32 API directly.
*/
"""

A Python file can also be precompiled using py_compile.compile; this uses os.stat to get the mtime of the .py file, and writes that to the .pyc file. 
This has the Unix behavior, and is "correct".

Output from time functions on Linux:
(The results are the same on Windows)

>>> print time.gmtime(0x495ce542)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=15, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>> print time.localtime(0x495ce542)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=10, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>> print time.gmtime(0x495cf352)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=16, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>> print time.localtime(0x495cf352)
time.struct_time(tm_year=2009, tm_mon=1, tm_mday=1, tm_hour=11, tm_min=46, tm_sec=10, tm_wday=3, tm_yday=1, tm_isdst=0)

>>>

There has been no change in the relevant import.c code between Python-2.6 and Python-3.3.

X:\work\testimportmtime>c:\python26\python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> print platform.platform()
Windows-post2008Server-6.1.7601-SP1
>>> print platform.architecture()
('64bit', 'WindowsPE')
>>> print platform.python_compiler()
MSC v.1500 64 bit (AMD64)

----------
components: Interpreter Core
files: testImportRe.py
messages: 165309
nosy: mackeith
priority: normal
severity: normal
status: open
title: import on Windows will recompile a pyc file created on Unix
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26367/testImportRe.py

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

From report at bugs.python.org  Thu Jul 12 18:24:12 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 12 Jul 2012 16:24:12 +0000
Subject: [New-bugs-announce] [issue15334] access denied for
	HKEY_PERFORMANCE_DATA
Message-ID: <1342110252.89.0.365330670645.issue15334@psf.upfronthosting.co.za>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

The registry key HKEY_PERFORMANCE_DATA is not accessible for non-interactive users (e.g., buildbot as a service).

The following patches skip the offending test when the tests unless the they are run from an interactive session.

----------
components: Tests, Windows
files: winreg-2.x.diff
keywords: patch
messages: 165320
nosy: jkloth
priority: normal
severity: normal
status: open
title: access denied for HKEY_PERFORMANCE_DATA
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26368/winreg-2.x.diff

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

From report at bugs.python.org  Thu Jul 12 18:42:54 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 12 Jul 2012 16:42:54 +0000
Subject: [New-bugs-announce] [issue15335] IDLE - debugger steps through
	run.py internals
Message-ID: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

The IDLE debugger steps through the internals of _RPCFile.

To reproduce this bug, create a new .py file with a few print statements, enable the debugger, and then run the file. Stepping through the print statement enters into _RPCFile.

----------
components: IDLE
messages: 165321
nosy: loewis, serwy, storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - debugger steps through run.py internals
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 12 21:43:34 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 19:43:34 +0000
Subject: [New-bugs-announce] [issue15336] Argparse required arguments
	incorrectly displayed as	optional arguments
Message-ID: <1342122214.84.0.306915245284.issue15336@psf.upfronthosting.co.za>


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

In this script, '-x' is required argument:
------------------------------------------
import argparse
p = argparse.ArgumentParser()
p.add_argument('-x', required=True)
p.print_help()

However, the automatically generated help shows it as optional:
---------------------------------------------------------------
usage: ap_demo.py [-h] -x X

optional arguments:
  -h, --help  show this help message and exit
  -x X

----------
components: Library (Lib)
messages: 165331
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Argparse required arguments incorrectly displayed as optional arguments
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul 12 21:48:11 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 19:48:11 +0000
Subject: [New-bugs-announce] [issue15337] The cmd module incorrectly lists
	"help" as an undocument	command
Message-ID: <1342122491.31.0.595399950091.issue15337@psf.upfronthosting.co.za>


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

The following minimal script:
-----------------------------
import cmd
class C(cmd.Cmd): pass
C().cmdloop()

Creates the following help display:
-----------------------------------
(Cmd) help

Undocumented commands:
======================
help

For people who are consistently documenting their other commands, it is annoying to have anything at all listed in the "undocumented section".  So, help should have it's own default help message.

----------
components: Library (Lib)
keywords: easy
messages: 165332
nosy: rhettinger
priority: normal
severity: normal
status: open
title: The cmd module incorrectly lists "help" as an undocument command
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul 12 22:42:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 20:42:41 +0000
Subject: [New-bugs-announce] [issue15338] test_UNC_path failure in
	test_import
Message-ID: <1342125761.76.0.749174282002.issue15338@psf.upfronthosting.co.za>


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

On the Win64 buildbot, trying to access an UNC path raises PermissionError, which makes a test fail:

======================================================================
ERROR: test_UNC_path (test.test_import.PathsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_import.py", line 469, in test_UNC_path
    os.listdir(unc)
PermissionError: [Error 5] Access is denied: '\\\\hades\\D$\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_3612\\@test_3612_tmp\\*.*'


If this is expected or normal, maybe we should simply skip the test when the listdir() call above fails.

----------
components: Library (Lib), Tests, Windows
messages: 165333
nosy: brian.curtin, jeremy.kloth, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: test_UNC_path failure in test_import
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 13 00:00:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 22:00:35 +0000
Subject: [New-bugs-announce] [issue15339] document the threading "facts of
	life" in Python
Message-ID: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would be helpful if the Python documentation included certain high-level information about multi-threading in Python.

At minimum, I think it would help for the documentation to provide a definition that can be linked to of what it means when some part of the Python documentation says something is "thread-safe".  In particular, such a definition could clarify that this is different from being atomic.  This might best be addressed by an entry in the glossary for the term "thread-safe".
  
Other documentation possibilities include stating what guarantees one should or should not expect regarding thread-safety, both within and across implementations, and providing centralized guidance on how to approach multi-threaded programming in Python.  A HOWTO is one possibility for addressing these other possibilities.

This issue stems from the discussion in issue 15329, which is more specific.

----------
assignee: docs at python
components: Documentation
messages: 165336
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: document the threading "facts of life" in Python

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

From report at bugs.python.org  Fri Jul 13 00:30:29 2012
From: report at bugs.python.org (Ian Wienand)
Date: Thu, 12 Jul 2012 22:30:29 +0000
Subject: [New-bugs-announce] [issue15340] OSError with "import random" when
	/dev/urandom doesn't	exist (regression from 2.6)
Message-ID: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za>


New submission from Ian Wienand <ian at wienand.org>:

Hi,

Lib/random.py has a fallback if os.urandom() returns NotImplementedError

---
from os import urandom as _urandom
...
   def seed(self, a=None):
        if a is None:
            try:
                a = long(_hexlify(_urandom(16)), 16)
            except NotImplementedError:
                import time
                a = long(time.time() * 256) # use fractional seconds
---

In 2.6, this is indeed what happens in Lib/os.py where "import urandom from os" gets [2]:

---
if not _exists("urandom"):
    def urandom(n):
...
      try:
            _urandomfd = open("/dev/urandom", O_RDONLY)
        except (OSError, IOError):
            raise NotImplementedError("/dev/urandom (or equivalent) not found")
---

however, in 2.7, things have shuffled around as a result of issue Issue #13703 and now _PyOS_URandom will return an OSError if it can't find /dev/urandom [3].

This means if you "import random" without "/dev/urandom" available it crashes trying to seed

I'm not sure if this is intentional?  One easy solution would be to catch OSError in random.py and fall back then too

[1] http://hg.python.org/cpython/file/70274d53c1dd/Python/random.c#l227
[2] http://hg.python.org/cpython/file/9f8771e09052/Lib/os.py#l746
[3] http://hg.python.org/cpython/file/70274d53c1dd/Lib/random.py#l111

----------
components: Library (Lib)
messages: 165340
nosy: iwienand
priority: normal
severity: normal
status: open
title: OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 13 01:08:20 2012
From: report at bugs.python.org (moras moorshed)
Date: Thu, 12 Jul 2012 23:08:20 +0000
Subject: [New-bugs-announce] [issue15341] Cplex and python
Message-ID: <1342134500.28.0.386653890414.issue15341@psf.upfronthosting.co.za>


New submission from moras moorshed <moorshed_k at yahoo.com>:

Im beginner with python, and I want to connect python to Cplex, IBM optimizer, I installed the python on this path:
'C:\Program Files\IBM\ILOG\CPLEX_Studio123\cplex\python\x86_win32\cplex'>
but when i want to create new file using cplex.Cplex() it gives me this error:
AttributeError: 'module' object has no attribute 'cplex'

so what is wrong?
please help me.

----------
components: Library (Lib)
messages: 165342
nosy: moorshed
priority: normal
severity: normal
status: open
title: Cplex and python
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 13 03:45:30 2012
From: report at bugs.python.org (Pan Yongzhi)
Date: Fri, 13 Jul 2012 01:45:30 +0000
Subject: [New-bugs-announce] [issue15342] os.path.join behavior
Message-ID: <1342143930.94.0.174584687761.issue15342@psf.upfronthosting.co.za>


New submission from Pan Yongzhi <fossilet at users.sourceforge.net>:

I am constructing a source directory argument to rsync. It has to end with slash due to rsync behavior. I use:

os.path.join('/src/dir', os.path.sep)

And run it and realized the source directory becomes '/'. Luckily it is not the destination.

Why should join discard all previous path components if any component is an absoulute path? This is such a surprise and renders this function useless.

----------
messages: 165348
nosy: fossilet
priority: normal
severity: normal
status: open
title: os.path.join behavior
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 13 06:31:44 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Fri, 13 Jul 2012 04:31:44 +0000
Subject: [New-bugs-announce] [issue15343] "pydoc -w <package>" write out
	page with empty "package	contents" section
Message-ID: <1342153904.47.0.184982192019.issue15343@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent <ultimate.mac.fanatic at gmail.com>:

Let there be a folder "testpkg" contained in $SOME_DIR with three empty files: "__init__.py", "bob.py", and "sally.py

If I run "pydoc3.2 -w testpkg" inside $SOME_DIR, it will output the file $SOME_DIR/testpkg.html

In testpkg.html there will be a section called "Package Contents" with two links named "bob" and "sally".

If I instead run "pydoc3.3 -w testpkg" inside $SOME_DIR, it will still output the file $SOME_DIR/testpkg.html

Only this time, in testpkg.html the section called "Package Contents" will be empty when there should be links named "bob" and "sally"

----------
messages: 165352
nosy: christopherthemagnificent
priority: normal
severity: normal
status: open
title: "pydoc -w <package>" write out page with empty "package contents" section
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 13 06:49:05 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Jul 2012 04:49:05 +0000
Subject: [New-bugs-announce] [issue15344] devinabox: failure when running
	make_a_box multiple times
Message-ID: <1342154945.64.0.517159061832.issue15344@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

When running make_a_box.py:

Fetching Mercurial ...
make_a_box.py:197: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=6>
  file_url = self._download_url()
Traceback (most recent call last):
  File "make_a_box.py", line 323, in <module>
    ins.create()
  File "make_a_box.py", line 219, in create
    self._create_mercurial()
  File "make_a_box.py", line 200, in _create_mercurial
    with open(os.path.join(self.directory, file_name), 'wb') as file:
IsADirectoryError: [Errno 21] Is a directory: 'Mercurial/'

Apparently running it more than once requires that you delete some things first.

----------
messages: 165354
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: devinabox: failure when running make_a_box multiple times
type: behavior

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

From report at bugs.python.org  Fri Jul 13 15:18:27 2012
From: report at bugs.python.org (Simon Hayward)
Date: Fri, 13 Jul 2012 13:18:27 +0000
Subject: [New-bugs-announce] [issue15345] HOWTOs Argparse tutorial - code
	example raises	SyntaxError
Message-ID: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>


New submission from Simon Hayward <simonhayward at gmail.com>:

HOWTOs - Argparse Tutorial, the code example will raise a syntax error when run. A trailing python3 reference (if called as a function): 'end=""', to suppresses a newline remains.

print "{}^{} == ".format(args.x, args.y), end=""

Should read:

print "{}^{} ==".format(args.x, args.y),

----------
assignee: docs at python
components: Documentation
files: argparse-howto.patch
keywords: patch
messages: 165381
nosy: docs at python, simon.hayward
priority: normal
severity: normal
status: open
title: HOWTOs Argparse tutorial - code example raises SyntaxError
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26374/argparse-howto.patch

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

From report at bugs.python.org  Fri Jul 13 18:47:27 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Fri, 13 Jul 2012 16:47:27 +0000
Subject: [New-bugs-announce] [issue15346] Tkinter dnd has no documentation
Message-ID: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za>


New submission from Daniel Swanson <popcorn.tomato.dude at gmail.com>:

The title should be self explanatory.
I needed Drag-and-drop for a project I was working on, (maybe I shouldn't be refering to it in the past tense as I haven't started yet) so I checked the documentation for tkinter and found:
3.3.0 b1
tkinter.dnd 
Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND.

3.2.2 (and .2.3)
tkinter.dnd 
Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND. 

2.7.3
Tkdnd 
Drag-and-drop support for Tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND.

I think that tkinter.dnd needs some documentation, whether or not it is replaced with Tk DND.

----------
assignee: docs at python
components: Documentation
messages: 165392
nosy: docs at python, weirdink13
priority: normal
severity: normal
status: open
title: Tkinter dnd has no documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 13 21:32:43 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 13 Jul 2012 19:32:43 +0000
Subject: [New-bugs-announce] [issue15347] IDLE - does not close if the
	debugger was active
Message-ID: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

IDLE fails to close if the debugger was active.

Steps to reproduce:

1) Start IDLE with only a shell.
2) Enable debugger.
3) Press enter in the shell. (Causes debugger to activate)
4) Close the shell window. (File->Exit or click X)
5) Click "OK" in the dialog box.

IDLE keeps running despite all windows being closed.

----------
components: IDLE
messages: 165410
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE - does not close if the debugger was active
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 13 21:38:10 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 13 Jul 2012 19:38:10 +0000
Subject: [New-bugs-announce] [issue15348] IDLE - shell becomes unresponsive
	if debugger windows is	closed while active.
Message-ID: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

The IDLE shell does not respond to commands if the debugger window is closed by clicking "X". This is due to PyShell's "executing" flag not being reset.

Steps to reproduce:

1) Start IDLE with a shell.
2) Enable debugger.
3) Press enter in the shell. (activates the debugger)
4) Close the debugger by clicking "X".

The shell is no longer responsive to new commands. Selecting "Restart Shell" does not fix the problem either.

----------
components: IDLE
messages: 165411
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE - shell becomes unresponsive if debugger windows is closed while active.
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 14 11:41:04 2012
From: report at bugs.python.org (Ztatik Light)
Date: Sat, 14 Jul 2012 09:41:04 +0000
Subject: [New-bugs-announce] [issue15349] SyntaxError b0rked grammar
Message-ID: <1342258864.48.0.924428948709.issue15349@psf.upfronthosting.co.za>


New submission from Ztatik Light <ztatik.light at gmail.com>:

SyntaxError: import * is not allowed in function '__init__' because it is contains a nested function with free variables


^ .... /s/"because it is contains"/"because it contains"

----------
components: Interpreter Core
messages: 165437
nosy: Ztatik.Light
priority: normal
severity: normal
status: open
title: SyntaxError b0rked grammar
versions: Python 2.6

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

From report at bugs.python.org  Sat Jul 14 13:05:34 2012
From: report at bugs.python.org (samwyse)
Date: Sat, 14 Jul 2012 11:05:34 +0000
Subject: [New-bugs-announce] [issue15350] {urllib,
	urllib.parse}.urlencode.__doc__ is unclear
Message-ID: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

The doc string for url encode states:

    The query arg may be either a string or a bytes type. When query arg is a
    string, the safe, encoding and error parameters are sent to the quote_via
    function for encoding

IMHO, this implies that the argument can be a string.  Note that the preceding paragraphs starts out with "If the query arg is a sequence of two-element tuples". I think that it should read:

    The components of the query arg may be either a string or a bytes
    type. When query arg is a string, the safe, encoding and error
    parameters are sent to the quote_via function for encoding.

----------
components: Library (Lib)
messages: 165440
nosy: samwyse
priority: normal
severity: normal
status: open
title: {urllib,urllib.parse}.urlencode.__doc__ is unclear
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/issue15350>
_______________________________________

From report at bugs.python.org  Sat Jul 14 17:33:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 14 Jul 2012 15:33:52 +0000
Subject: [New-bugs-announce] [issue15351] Add to unittest.TestCase support
	for using context	managers
Message-ID: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The setUp() and tearDown() methods of unittest.TestCase are of course extremely useful.  But sometimes one has set up and tear down functionality that one would like to apply in the form of an existing context manager (and that may be from an outside source).

There is currently no clear or clean way to do this.  It would be nice if unittest exposed a way to do this.

The closest I have been able to come is overriding TestCase.run() as follows:

class MyTest(unittest.TestCase):

    def run(self, result=None):
        with my_context_manager() as foo:
            # Do stuff.
            super(MyTest, self).run(result)

But this is not ideal because the context manager is surrounding more than it should (various test initialization code internal to unittest, etc).  Also, ideally the API would let one apply a context manager either before or after setUp() and tearDown(), or both.

Here is one idea for an API.  unittest.TestCase could expose a setUpContext() context manager that wraps the user-defined setUp() and tearDown(), and also a runTestMethod() method that runs the test method code by itself (i.e. currently the following line of unittest/case.py: `self._executeTestPart(testMethod, outcome, isTest=True)`).

To use the API, the user could override a simple method called something like runTest():

    def runTest(self):
        with setUpContext():
            self.runTestMethod()

The user would, in the override, be free to insert additional context managers before or after setUpContext(), or both.

----------
components: Library (Lib)
messages: 165454
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Add to unittest.TestCase support for using context managers
type: enhancement

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

From report at bugs.python.org  Sat Jul 14 21:41:05 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 14 Jul 2012 19:41:05 +0000
Subject: [New-bugs-announce] [issue15352] importlib.h should be regenerated
	when the marshaling	code changes
Message-ID: <1342294865.71.0.8673703337.issue15352@psf.upfronthosting.co.za>


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

Today I was hacking on a patch that changes the marshaling format for Code objects.  When building the patch I was met with:

   ValueError: bad marshal data (unknown type code)
   make: *** [Lib/_sysconfigdata.py] Abort trap: 6

This is because the frozen importlib was not rebuilt with the new marshaling format.

----------
components: Build
messages: 165464
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: importlib.h should be regenerated when the marshaling code changes
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 14 22:30:31 2012
From: report at bugs.python.org (Jerry Jacobs)
Date: Sat, 14 Jul 2012 20:30:31 +0000
Subject: [New-bugs-announce] [issue15353] ld: library not found for
	-lpython3.3m because of wrong	LDFLAGS_PYTHON
Message-ID: <1342297831.17.0.252581659185.issue15353@psf.upfronthosting.co.za>


New submission from Jerry Jacobs <jerry at xor-gate.org>:

Dear all,

I'm using python in a application (sigrok.org) and want to ship it as a framework with a .app folder. 

I'm building python-3.3b1 from source to a .framework. It is correctly compiled and installed in the given directory. Only the python-3.3.pc is incorrect because it has not the name python-3.3m.pc and includes the following library entries: Libs: -L${libdir} -lpython3.3m

So this results in:
ld: library not found for -lpython3.3m
because of the deployment of the wrong .pc Libs directive:
build/decoders/nunchuk/Makefile
127:CPPFLAGS_PYTHON = -I/Users/jerry/Sigrok/Python.framework/Versions/3.3/include/python3.3m -I/Users/jerry/Sigrok/Python.framework/Versions/3.3/include/python3.3m
159:LDFLAGS_PYTHON = -L/Users/jerry/Sigrok/Python.framework/Versions/3.3/lib/python3.3/config-3.3m -ldl -framework CoreFoundation -lpython3.3m -framework CoreFoundation Python.framework/Versions/3.3/Python
187:PYTHON3_CONFIG = python3.3m-config

Kind regards,
Jerry

----------
assignee: ronaldoussoren
components: Macintosh
messages: 165469
nosy: Jerry.Jacobs, ronaldoussoren
priority: normal
severity: normal
status: open
title: ld: library not found for -lpython3.3m because of wrong LDFLAGS_PYTHON
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 15 02:14:40 2012
From: report at bugs.python.org (Philip Jenvey)
Date: Sun, 15 Jul 2012 00:14:40 +0000
Subject: [New-bugs-announce] [issue15354] _PyObject_LengthHint only accepts
	longs
Message-ID: <1342311280.51.0.844161517469.issue15354@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at underboss.org>:

The __length_hint__ optimization was broken a while ago for many iterators due to a bug introduced in 44c090c74202. It only accepts longs as valid hints, not ints

This affects 2.6 too (but that's in security-only fix mode), but not 3.x

----------
assignee: pjenvey
messages: 165474
nosy: pjenvey
priority: normal
severity: normal
status: open
title: _PyObject_LengthHint only accepts longs
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 15 02:31:01 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 00:31:01 +0000
Subject: [New-bugs-announce] [issue15355] generator.__next__() docs should
	mention exception if	already executing
Message-ID: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think the generator.__next__() documentation should say that it raises an exception if the generator is already executing:

http://docs.python.org/dev/reference/expressions.html#generator.__next__

I don't think this is currently mentioned anywhere in the section on yield expressions.

I think this is worth mentioning because this is different from the general situation for iterators, for example.  One consequence of this is that, unlike for iterators, using a bare generator in a multithreaded situation will always result in a critical section (since an iterator can be made to take care of its own locking, etc).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 165476
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: generator.__next__() docs should mention exception if already executing
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 15 03:50:27 2012
From: report at bugs.python.org (zoupl)
Date: Sun, 15 Jul 2012 01:50:27 +0000
Subject: [New-bugs-announce] [issue15356] '\xa0' isspace returns true while
	compiling python on	solaris 10 by users using gcc 3.4.6
Message-ID: <1342317027.18.0.929395647565.issue15356@psf.upfronthosting.co.za>


New submission from zoupl <zoupengli at gmail.com>:

Compile python (from 2.4.6 to version 2.6.8) on solaris 5.10 sparc using gcc 3.4.6. When using UTf-8, the \xa0 is a space. Howeve this is wrong. Version 2.7 is OK.

>>> s = '\xa0'
>>> assert s.strip() == s
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> assert s.strip() == s

----------
components: Unicode
messages: 165486
nosy: ezio.melotti, zoupl
priority: normal
severity: normal
status: open
title: '\xa0' isspace returns true while compiling python on solaris 10 by users using gcc 3.4.6
versions: Python 2.6

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

From report at bugs.python.org  Sun Jul 15 04:27:16 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 02:27:16 +0000
Subject: [New-bugs-announce] [issue15357] Deprecate redundant pieces of
	pkgutil
Message-ID: <1342319236.08.0.487526794106.issue15357@psf.upfronthosting.co.za>


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

To set the stage for fixing the regression reported in #15343, I'm going through and clearly marking the parts of pkgutil which should no longer be used now that the default import system is PEP 302 compliant.

----------
assignee: ncoghlan
components: Library (Lib)
messages: 165488
nosy: georg.brandl, ncoghlan
priority: release blocker
severity: normal
status: open
title: Deprecate redundant pieces of pkgutil
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 15 11:54:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jul 2012 09:54:31 +0000
Subject: [New-bugs-announce] [issue15358] Test pkgutil.walk_packages in
	test_pkgutil instead of	test_runpy
Message-ID: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za>


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

Created to record the egregious hack of relying on the test_runpy infrastructure in order to test pkgutil.walk_packages.

It gets the job done, but is a really messy way of going about it. Worth cleaning up by factoring the support code out to a helper module when there isn't a release deadline looming.

----------
components: Tests
messages: 165516
nosy: ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 15 15:10:55 2012
From: report at bugs.python.org (Brian Thorne)
Date: Sun, 15 Jul 2012 13:10:55 +0000
Subject: [New-bugs-announce] [issue15359] Sockets support for CAN_BCM
Message-ID: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za>


New submission from Brian Thorne <hardbyte at gmail.com>:

In addition to CAN_RAW introduced in Python 3.3, it would be really useful to expose the CAN_BCM protocol. Effectively it hands off as much  to the kernel as possible which gives Python programs the ability to send and receive many periodic messages with little additional jitter or overhead.

I've attached an early stab at a patch to see if there is interest.

I'll be putting more examples of using BCM sockets at https://bitbucket.org/hardbyte/python-socket-examples

----------
components: Library (Lib)
files: python_bcm.patch
keywords: patch
messages: 165527
nosy: Thorney, pitrou
priority: normal
severity: normal
status: open
title: Sockets support for CAN_BCM
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26386/python_bcm.patch

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

From report at bugs.python.org  Sun Jul 15 19:25:06 2012
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 15 Jul 2012 17:25:06 +0000
Subject: [New-bugs-announce] [issue15360] Behavior of assigning to __dict__
	is not documented
Message-ID: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

The documentation (at least the obvious places, see Doc/reference/datamodel.rst) says classes and class instances have the '__dict__' attribute, but nothing is said about what happens when assigning to it (like obj.__dict__ = something).

As far as I understand that's undefined behavior and other implementations may not work the same as CPython (and CPython itself behaves differently between versions).

I'd submit a documentation patch if I knew how to specify this matter. Maybe just say the behavior is not defined?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 165538
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: Behavior of assigning to __dict__ is not documented
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jul 15 21:02:40 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 15 Jul 2012 19:02:40 +0000
Subject: [New-bugs-announce] [issue15361] venv's Activate.ps1 causes broken
	prompt with powershell
Message-ID: <1342378960.04.0.994385989883.issue15361@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

If I create a venv on Windows called "py3" then py3/Scripts/Activate.ps1 defines the prompt to be

    function prompt {
        Write-Host -NoNewline -ForegroundColor Green [(py3) ]
        _OLD_VIRTUAL_PROMPT
    }

However this prompt function does not work properly, and running

    Write-Host -NoNewline -ForegroundColor Green [(py3) ]

on its own produces an error because of the lack of quotes around (py3).  Adding quotes as shown in the patch seems to fix the problem.

----------
components: Library (Lib)
files: prompt.patch
keywords: patch
messages: 165545
nosy: sbt, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: venv's Activate.ps1 causes broken prompt with powershell
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26387/prompt.patch

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

From report at bugs.python.org  Sun Jul 15 23:19:22 2012
From: report at bugs.python.org (John Schneider)
Date: Sun, 15 Jul 2012 21:19:22 +0000
Subject: [New-bugs-announce] [issue15362] pyport.h includes antiquated UTF
	handling for FreeBSD
Message-ID: <1342387162.35.0.975176855172.issue15362@psf.upfronthosting.co.za>


New submission from John Schneider <js at jschneider.com>:

Revision 36793 introduced a libc wrapper for FreeBSD 5.x which addressed some UTF issues. Unfortunately, this causes C compilation errors for certain ports.

Also reference issues 10910, 1455641

This change is no longer applicable for FreeBSD 9.  I'm not sure what version of FreeBSD made it not longer applicable, but there were reports of it still being necessary for FreebSD 7. FreeBSD 6 - 8 should be tested with this test script:
------------------------
#!/usr/bin/env python

from ctypes import *

cdll.LoadLibrary("libc.so.7")
libc = CDLL("libc.so.7")

assert libc.isspace(0xa0) == 0
------------------------

I've also attached a patch for python 2.7.3.

----------
components: Unicode, ctypes
files: patch-pyport.h
messages: 165550
nosy: JohnSchneider, ezio.melotti
priority: normal
severity: normal
status: open
title: pyport.h includes antiquated UTF handling for FreeBSD
versions: Python 2.7
Added file: http://bugs.python.org/file26388/patch-pyport.h

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

From report at bugs.python.org  Mon Jul 16 01:17:23 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Jul 2012 23:17:23 +0000
Subject: [New-bugs-announce] [issue15363] Idle/tkinter ~x.py 'save as'
	fails. closes idle
Message-ID: <1342394243.7.0.336788716257.issue15363@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

I have (had ;-) a project file ~template.py with common boilerplate.
To start a new project file, I want to open the above and save as xyz.py. I can edit and 'save' the template to update it just fine. But trying to do a 'save as' to a new name, in Idle editor, on all three current versions, I get (when starting Idle from command window)

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Programs\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Programs\Python33\lib\idlelib\IOBinding.py", line 347, in save_as
    filename = self.asksavefile()
  File "C:\Programs\Python33\lib\idlelib\IOBinding.py", line 514, in asksavefile

    filename = self.savedialog.show(initialdir=dir, initialfile=base)
  File "C:\Programs\Python33\lib\tkinter\commondialog.py", line 48, in show
    s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: user "template.py" doesn't exist

When starting Idle normally, this causes it to silently close. When run from the cp interpreter, the edit window blinks but continues while the trackback is printed in the cp window.

Just saving does not bring up a dialog; hence no problem. And I understand that '~' has special meaning on *nix, but I am running on Windows.

I changed '~' to '@' and the file still sorts at the top (though above __init__.py rather than below) and save as now works as it should. I know that save as worked for this file last October, but while I think it had the same ~name then, I cannot be sure. Maybe I added '~' after the last time I successfully used the file.

As near as I can tell, asksavefile() passes initialfile = base = '~template.py' to savedialog.show which passes it unchanged and unexamined to tk.call. So the special casing of ~ seems to happen in tcl/tk out of our control. I am not sure if doing this on Windows is a tcl/tk bug or not.

For Windows, just removing '~' or even blanking the name before the .show() might be sensible, but maybe not for *nix.

Instead, we could catch the error instead of letting it crash Idle and put up a message box to the effect that one cannot 'save as' when editing a file named '~xxxx'. More specifically, in IOBinding.py, line 514 or so, replace

filename = self.savedialog.show(initialdir=dir, initialfile=base)

with

try:
    filename = self.savedialog.show(initialdir=dir, initialfile=base)
except TclError as e:
    if e.args[0].startswith('user'):
        xxx display message, click ok
    filename = None

I am assuming the None is the return from canceled dialogs. Certainly, None caused the file save code back up in saveas() (346) to skip the save.

The message could be something like "tcl/tk gives special treatment to file names starting with '~' and returned this error message {}".format(e.args[0])

We could also add "else: message('unanticipated tclerror prevented save as dialog <message>)"

----------
components: IDLE
messages: 165553
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle/tkinter ~x.py 'save as' fails. closes idle
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul 16 12:01:39 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 10:01:39 +0000
Subject: [New-bugs-announce] [issue15364] sysconfig confused by relative
	paths
Message-ID: <1342432899.52.0.53646689099.issue15364@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

With unix, and a source build, sysconfig.get_config_var('srcdir') and sysconfig.get_path('include') misbehave:

  user at mint-vm ~/Repos/cpython $ cd /
  user at mint-vm / $ ~/Repos/cpython/python 
  Python 3.3.0b1 (default:671894ae19a2, Jul 16 2012, 10:43:27) 
  [GCC 4.5.2] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import sysconfig
  >>> sysconfig.get_config_var('srcdir')
  '/'
  >>> sysconfig.get_path('include')
  '//Include'

The problem seems to be the else clause of

        if 'srcdir' not in _CONFIG_VARS:
            _CONFIG_VARS['srcdir'] = _PROJECT_BASE
        else:
            _CONFIG_VARS['srcdir'] = _safe_realpath(_CONFIG_VARS['srcdir'])

The else clause (in slightly modified form) was introduced in 356d0ea8ea34, and it turns a relative path into an absolute path, using the current working directory as a base.

For me, simply removing the line allows the absolute path to be calculated correctly a few lines later on.

I don't know what problem 356d0ea8ea34 was intended to fix.

----------
messages: 165581
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: sysconfig confused by relative paths
type: behavior

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

From report at bugs.python.org  Mon Jul 16 12:28:15 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 16 Jul 2012 10:28:15 +0000
Subject: [New-bugs-announce] [issue15365] Traceback reporting can fail if IO
	cannot be imported
Message-ID: <1342434495.02.0.347473954517.issue15365@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Reporting an error early in the python startup, before importing is properly initialized, can be tricky.
For example, here:

if (PyImport_ImportFrozenModule("_frozen_importlib") <= 0) {
  Py_FatalError("Py_Initialize: can't import _frozen_importlib");

The problem is, that _Py_DisplaySourceLine will set an exception because it cannot import the io module.  And this will terminate the traceback output.

The attached patch aims to rectify it by ignoring errors from this api in traceback.c

----------
components: Interpreter Core
files: traceback.patch
keywords: patch
messages: 165585
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Traceback reporting can fail if IO cannot be imported
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26393/traceback.patch

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

From report at bugs.python.org  Mon Jul 16 13:30:11 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 11:30:11 +0000
Subject: [New-bugs-announce] [issue15366] venv assumes header files in
	sys._home + '/Include'
Message-ID: <1342438211.61.0.183367325622.issue15366@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

For Unix I follow the practice suggested in README of running configure from a subdir of the main python directory, eg

    mkdir release
    cd release
    ../configure
    make

But if I create a venv then I cannot use it to compile C extensions because the include dirs are wrong, eg

    running build
    running build_ext
    building 'demo' extension
    gcc -pthread -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/user/Repos/cpython/release/Include -I/home/user/Repos/cpython/release -c demo.c -o build/temp.linux-i686-3.3/demo.o
    demo.c:1:20: fatal error: Python.h: No such file or directory
    compilation terminated.
    error: command 'gcc' failed with exit status 1

The problem seems to be that distutils.sysconfig.get_python_inc() assumes that if sys._home is set (as it is in a virtual env) then the standard header files can be found in sys._home + '/Include'.

But for my venv this is wrong, since sys._home is "/home/user/Repos/cpython/release" and "/home/user/Repos/cpython/release/Include" is empty.  Instead get_python_inc() should return "/home/user/Repos/cpython/Include".

BTW, a seperate issue seems to be that ${venv}/include is not added to the list of include dirs used when compiling.

----------
components: Library (Lib)
messages: 165589
nosy: sbt, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: venv assumes header files in sys._home + '/Include'
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 16 13:46:41 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 16 Jul 2012 11:46:41 +0000
Subject: [New-bugs-announce] [issue15367] build_ext in a venv on Windows
	assumes pyconfig.h in	sys.exec_prefix + '\PC'
Message-ID: <1342439201.04.0.23455949432.issue15367@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

On Windows I can't use a source build of Python to create a venv which will compile C extensions because pyconfig.h cannot be found.  For example

    running build
    running build_ext
    building 'demo' extension
    creating build
    creating build\temp.win32-3.3
    creating build\temp.win32-3.3\Release
    c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -IC:\Repos\cpython\include -IC:\Users\oudkerk\myenv\PC /Tcdemo.c /Fobuild\temp.win32-3.3\Release\demo.obj
demo.c
    C:\Repos\cpython\include\Python.h(8) : fatal error C1083: Cannot open include file: 'pyconfig.h': No such file or directory
    error: command '"c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.exe"' failed with exit status 2

The problem seems to be with the following line in distutils/command/build_ext.py:

            self.include_dirs.append(os.path.join(sys.exec_prefix, 'PC'))

Inside a venv, sys.exec_prefix is the venv directory.

----------
messages: 165590
nosy: sbt, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: build_ext in a venv on Windows assumes pyconfig.h in sys.exec_prefix + '\PC'
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 16 14:52:36 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 16 Jul 2012 12:52:36 +0000
Subject: [New-bugs-announce] [issue15368] bytecode generation is not
	deterministic
Message-ID: <1342443156.65.0.45067374653.issue15368@psf.upfronthosting.co.za>


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

Consider this small example (you might have to run sample program multiple 
times to see a difference):

$ cat dis-closure.py
import dis

def adder(a, b):
    def add():
        return a + b
    return add

print(dis.dis(adder(1, 2).__code__))

$  ./python.exe dis-closure.py
  5           0 LOAD_DEREF               0 (a) 
              3 LOAD_DEREF               1 (b) 
              6 BINARY_ADD           
              7 RETURN_VALUE         
None
$  ./python.exe dis-closure.py
  5           0 LOAD_DEREF               1 (a) 
              3 LOAD_DEREF               0 (b) 
              6 BINARY_ADD           
              7 RETURN_VALUE         
None

The order of 'co_cellvars' and 'co_freevars' can be different from compile to 
compile, thus the bytecode can be different from compile to compile.

This is due to the fact that these variable sets are managed with hashes and
the ordering may come out different when the names in the hashes are given
indexes (via 'dictbytype' in 'compile.c').

I am not sure if these are the only areas that causes bytecode generation
to be non-deterministic.  I found this behavior surprising.

----------
components: Interpreter Core
messages: 165596
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: bytecode generation is not deterministic
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 16 15:41:45 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 16 Jul 2012 13:41:45 +0000
Subject: [New-bugs-announce] [issue15369] pybench and test.pystone poorly
	documented
Message-ID: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>


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

The benchmarking tools "pystones" and "pybench" which are shipped with the Python standard distribution are not documented.

The only information is in the what's-new for Python 2.5:
http://docs.python.org/dev/whatsnew/2.5.html?highlight=pybench#new-improved-and-removed-modules

IMHO, they should be mentioned somewhere in the HOWTOs, the FAQ or the standard library documentation ("Development Tools" or "Debugging and Profiling")

----------
assignee: docs at python
components: Benchmarks, Documentation
messages: 165603
nosy: docs at python, flox
priority: normal
severity: normal
status: open
title: pybench and test.pystone poorly documented
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 16 16:26:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:26:11 +0000
Subject: [New-bugs-announce] [issue15370] test_runpy should include
	namespace package tests
Message-ID: <1342448771.76.0.81603722524.issue15370@psf.upfronthosting.co.za>


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

test_runpy doesn't currently check that code can be correctly executed from namespace packages

----------
components: Tests
messages: 165613
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_runpy should include namespace package tests
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 16 16:27:57 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:27:57 +0000
Subject: [New-bugs-announce] [issue15371] test_cmd_line_script should
	include namespace package	tests
Message-ID: <1342448877.31.0.875625357245.issue15371@psf.upfronthosting.co.za>


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

test_cmd_line_script doesn't currently check that namespace packages and submodules of namespace packages can be executed via the -m switch

----------
components: Library (Lib)
messages: 165614
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_cmd_line_script should include namespace package tests
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 16 18:04:22 2012
From: report at bugs.python.org (Luca Fabbri)
Date: Mon, 16 Jul 2012 16:04:22 +0000
Subject: [New-bugs-announce] [issue15372] Python is missing alternative for
	common quoting	character
Message-ID: <1342454662.71.0.490144532965.issue15372@psf.upfronthosting.co.za>


New submission from Luca Fabbri <lucafbb at gmail.com>:

Using the unicodedata.decomposition function on characters like \u201c and \u201d I didn't get back the classic quote character (").

This is a very common error when text is taken from Microsoft Word (where in italian language a couple of quoting character in a sentence like "foo" is automatically changed to ?foo?).

----------
components: Unicode
messages: 165630
nosy: ezio.melotti, keul
priority: normal
severity: normal
status: open
title: Python is missing alternative for common quoting character
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 16 18:08:57 2012
From: report at bugs.python.org (Hartmut Goebel)
Date: Mon, 16 Jul 2012 16:08:57 +0000
Subject: [New-bugs-announce] [issue15373] copy.copy() does not properly copy
	os.environment
Message-ID: <1342454937.95.0.386630033182.issue15373@psf.upfronthosting.co.za>


New submission from Hartmut Goebel <h.goebel at crazy-compilers.com>:

Wehn copying os.environ usinf copy.copy(), any manipulation on the copied object will change os.environment, too.

$ python
Python 2.7.3 (default, Apr 22 2012, 07:46:58) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import copy, os
>>> os.environ['TITI']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/UserDict.py", line 23, in __getitem__
    raise KeyError(key)
KeyError: 'TITI'
>>> env = copy.copy(os.environ)
>>> env['TITI'] = 'in den Ferien'
>>> os.environ['TITI']
'in den Ferien'
>>> 

Strictly speaking, this is correct, as the os.environment class is meant to manipulate the environment in the background. But user's expectation is different: he thinks, manipulating the copied object is save and does not effect the environment.

----------
messages: 165631
nosy: htgoebel
priority: normal
severity: normal
status: open
title: copy.copy() does not properly copy os.environment
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 16 20:01:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Jul 2012 18:01:22 +0000
Subject: [New-bugs-announce] [issue15374] venv environment variable should
	follow the conventions
Message-ID: <1342461682.61.0.267332995554.issue15374@psf.upfronthosting.co.za>


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

pyvenv's environment variable is currently named VIRTUAL_ENV (it seems).
It would be better if it followed the trend of other Python environment variables such as PYTHONHOME, PYTHONSTARTUP, etc.
(so, PYTHONVENV ?)

Setting as deferred blocker, since it would be better for existing venvs not to be made useless.

----------
components: Library (Lib)
messages: 165645
nosy: georg.brandl, pitrou, vinay.sajip
priority: deferred blocker
severity: normal
status: open
title: venv environment variable should follow the conventions
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 17 04:05:11 2012
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 17 Jul 2012 02:05:11 +0000
Subject: [New-bugs-announce] [issue15375] Trivial for fix in the subprocess
	documentation
Message-ID: <1342490711.26.0.923529626372.issue15375@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

The word "child" is needlessly repeated in the subprocess documentation. This trivial patch fixes this.

----------
assignee: docs at python
components: Documentation
files: subprocess.diff
keywords: patch
messages: 165670
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Trivial for fix in the subprocess documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file26408/subprocess.diff

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

From report at bugs.python.org  Tue Jul 17 09:10:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 17 Jul 2012 07:10:49 +0000
Subject: [New-bugs-announce] [issue15376] Refactor the create-package code
	in test_runpy into a	helper module
Message-ID: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to refactor the create-package code in test_runpy into a helper module, as suggested in issue 15358.

This is a prerequisite to moving the pkgutil.walk_package() tests from test_runpy into test_pkgutil.

----------
components: Tests
keywords: easy
messages: 165683
nosy: cjerdonek, ncoghlan
priority: normal
severity: normal
status: open
title: Refactor the create-package code in test_runpy into a helper module
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 17 10:11:58 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 17 Jul 2012 08:11:58 +0000
Subject: [New-bugs-announce] [issue15377] os.path.join() error misleading
	with path1=None
Message-ID: <1342512718.53.0.395843871145.issue15377@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The error message for os.path.join() is misleading when the first argument is None.  The message should probably say something about mixing "None" and strings.

Python 3.3.0b1 (default:f954ee489896, Jul 16 2012, 22:42:29) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
>>> import os
>>> os.path.join(None, 'a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../cpython/Lib/posixpath.py", line 89, in join
    "components.") from None
TypeError: Can't mix strings and bytes in path components.

----------
components: Library (Lib)
messages: 165685
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: os.path.join() error misleading with path1=None
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 17 10:15:13 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 08:15:13 +0000
Subject: [New-bugs-announce] [issue15378] Underported
	Tools/unicode/comparecodecs.py
Message-ID: <1342512913.96.0.0337741529294.issue15378@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Tools/unicode/gencodec.py was not properly ported from Python 2 to Python 3. The suggested patch fixes this porting issue.

----------
components: Demos and Tools
files: decode_charmap_maxchar.patch
keywords: patch
messages: 165687
nosy: storchaka
priority: normal
severity: normal
status: open
title: Underported Tools/unicode/comparecodecs.py
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26411/decode_charmap_maxchar.patch

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

From report at bugs.python.org  Tue Jul 17 10:15:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jul 2012 08:15:58 +0000
Subject: [New-bugs-announce] [issue15379] Charmap decoding of no-BMP
	characters
Message-ID: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Yet one inconsistency in charmap codec.

>>> import codecs
>>> codecs.charmap_decode(b'\x00', 'strict', '\U0002000B')
('?', 1)
>>> codecs.charmap_decode(b'\x00', 'strict', {0: '\U0002000B'})
('?', 1)
>>> codecs.charmap_decode(b'\x00', 'strict', {0: 0x2000B})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: character mapping must be in range(65536)

The suggested patch removes this unnecessary limitation in charmap decoder.

----------
components: Interpreter Core
files: decode_charmap_maxchar.patch
keywords: patch
messages: 165688
nosy: storchaka
priority: normal
severity: normal
status: open
title: Charmap decoding of no-BMP characters
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26412/decode_charmap_maxchar.patch

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

From report at bugs.python.org  Tue Jul 17 11:07:04 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 17 Jul 2012 09:07:04 +0000
Subject: [New-bugs-announce] [issue15380] bytes/str mismatch in distribute
Message-ID: <1342516024.25.0.62947980787.issue15380@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

I tried installing CherryPy into my local Python 3.2 build. I don't know if this is a problem with CherryPy's setup.py or with distribute but suspect the latter since I've had similar problems before.

$ /home/mark/opt/python32/bin/python3 setup.py install
running install
running bdist_egg
running egg_info
writing CherryPy.egg-info/PKG-INFO
writing top-level names to CherryPy.egg-info/top_level.txt
writing dependency_links to CherryPy.egg-info/dependency_links.txt
reading manifest file 'CherryPy.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'CherryPy.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build
creating build/lib
creating build/lib/cherrypy
copying cherrypy/_cperror.py -> build/lib/cherrypy
...
byte-compiling build/bdist.linux-x86_64/egg/cherrypy/_cperror.py to _cperror.pyc
...
installing package data to build/bdist.linux-x86_64/egg
running install_data
copying cherrypy/cherryd -> build/bdist.linux-x86_64/egg/cherrypy
...
creating build/bdist.linux-x86_64/egg/EGG-INFO
installing scripts to build/bdist.linux-x86_64/egg/EGG-INFO/scripts
running install_scripts
running build_scripts
creating build/scripts-3.2
copying and adjusting cherrypy/cherryd -> build/scripts-3.2
changing mode of build/scripts-3.2/cherryd from 644 to 755
creating build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-3.2/cherryd -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/cherryd to 755
copying CherryPy.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying CherryPy.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying CherryPy.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying CherryPy.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
cherrypy._cpmodpy: module references __file__
...
creating dist
creating 'dist/CherryPy-3.2.2-py3.2.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing CherryPy-3.2.2-py3.2.egg
creating /home/mark/opt/python32/lib/python3.2/site-packages/CherryPy-3.2.2-py3.2.egg
Extracting CherryPy-3.2.2-py3.2.egg to /home/mark/opt/python32/lib/python3.2/site-packages
Adding CherryPy 3.2.2 to easy-install.pth file
Traceback (most recent call last):
  File "setup.py", line 144, in <module>
    main()
  File "setup.py", line 139, in main
    cmdclass=cmd_class,
  File "/home/mark/opt/python32/lib/python3.2/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/mark/opt/python32/lib/python3.2/distutils/dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "/home/mark/opt/python32/lib/python3.2/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/install.py", line 73, in run
    self.do_egg_install()
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/install.py", line 101, in do_egg_install
    cmd.run()
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 236, in run
    self.easy_install(spec, not self.no_deps)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 452, in easy_install
    return self.install_item(None, spec, tmpdir, deps, True)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 503, in install_item
    self.process_distribution(spec, dist, deps)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 522, in process_distribution
    self.install_egg_scripts(dist)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 401, in install_egg_scripts
    dist.get_metadata('scripts/'+script_name)
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 615, in install_script
    script_text = get_script_header(script_text) + (
  File "/home/mark/opt/python32/lib/python3.2/site-packages/distribute-0.6.10-py3.2.egg/setuptools/command/easy_install.py", line 1449, in get_script_header
    match = first_line_re.match(first)
TypeError: can't use a bytes pattern on a string-like object

----------
assignee: eric.araujo
components: Distutils
messages: 165693
nosy: eric.araujo, mark, tarek
priority: normal
severity: normal
status: open
title: bytes/str mismatch in distribute
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 17 14:12:46 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 12:12:46 +0000
Subject: [New-bugs-announce] [issue15381] Optimize BytesIO to so less
	reallocations when written, similarly to StringIO
Message-ID: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

>From this pydev thread: http://mail.python.org/pipermail/python-dev/2012-July/120981.html

"BytesIO is actually missing an optimisation that is already used in
StringIO: the StringIO C implementation uses a fragment accumulator
internally, and collapses that into a single string object when
getvalue() is called. BytesIO is still using the old
"resize-the-buffer-as-you-go" strategy, and thus ends up repeatedly
reallocating the buffer as the data sequence grows incrementally.

It should be optimised to work the same way StringIO does (which is
effectively the same way that the monkeypatched version works)"

----------
components: Library (Lib)
messages: 165715
nosy: eli.bendersky, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Optimize BytesIO to so less reallocations when written, similarly to StringIO
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Tue Jul 17 23:02:38 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 17 Jul 2012 21:02:38 +0000
Subject: [New-bugs-announce] [issue15382] os.utime() mishandles some
	arguments
Message-ID: <1342558958.87.0.656849983066.issue15382@psf.upfronthosting.co.za>


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

Contrarily to documentation:

1. os.utime() accepts a tuple with floats passed by ns argument:
>>> os.utime(file, ns=(0.5, 0.5))
>>>

2. os.utime() does not accept explicit ns=None:
>>> os.utime(file, times=None)
>>> os.utime(file, ns=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: utime: 'ns' must be a tuple of two ints
>>>

3. os.utime() does not accept both times and ns when only times is a tuple:
>>> os.utime(file, times=None, ns=(0, 0))
>>> os.utime(file, times=(0, 0), ns=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: utime: you may specify either 'times' or 'ns' but not both
>>>

----------
messages: 165730
nosy: Arfrever, haypo, larry
priority: normal
severity: normal
status: open
title: os.utime() mishandles some arguments
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 18 07:08:42 2012
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 18 Jul 2012 05:08:42 +0000
Subject: [New-bugs-announce] [issue15383] Autocompletion crashes Python if
	the __builtins__ module	cannot be found.
Message-ID: <1342588122.88.0.602543010606.issue15383@psf.upfronthosting.co.za>


New submission from Tyler Crompton <gtr053 at gmail.com>:

Doing one of the following crashes Python.

    del __builtins__
    a{Tab}

or

    builtins = __builtins__
    del __builtins__
    a{Tab}

If you do a print screen, immediately, you will see the following error:

    *** Internal Error: rpc.py:SocketIO.localcall()

     Object: exec
     Method: <bound method Executive.get_the_completion_list of <idlelib.run.Executive object at 0x0000000002DC2710>>
     Args: ('', 1)

    Traceback (most recent call last):
      File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
        ret = method(*args, **kwargs)
      File "C:\Python32\lib\idlelib\run.py", line 327, in get_the_completion_list
        return self.autocomplete.fetch_completions(what, mode)
      File "C:\Python32\lib\idlelib\AutoComplete.py", line 189, in fetch_completions
        namespace.update(__main__.__builtins__.__dict__)
AttributeError: 'module' object has no attribute '__builtins__'

Additionally, when __builtins__ is deleted (in IDLE), __builtins__ becomes a dictionary. If one were to then do __builtins__.clear(), the interpreter stops all interpreting. IDLE moreorless becomes a text editor with syntax highlighting. If you try to use autocomplete, Python hangs before crashing.

I realize that doing such is pointless, but it behaves differently than interactive console interpreters. Interactive console interpreters don't convert __builtins__ to a dictionary upon its deletion. I feel that this error can be handled to prevent crashing.

----------
components: IDLE
messages: 165741
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: Autocompletion crashes Python if the __builtins__ module cannot be found.
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 18 12:46:03 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 10:46:03 +0000
Subject: [New-bugs-announce] [issue15384] FileFinder.path_hook()("") returns
	None on Windows
Message-ID: <1342608363.39.0.672383016327.issue15384@psf.upfronthosting.co.za>


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

As noted in #15314, one of the pkgutil tests was failing on Windows because pkgutil.get_importer("") was returning None. On my Fedora system it returns FileFinder(".").

I've now tweaked that particular test to use a bogus path string so that None is the expected result on all platforms.

However, the cross-platform discrepancy is a little disturbing - I would have expected the operation to either fail or succeed regardless of platform.

Since pkgutil.get_importer is now just a wrapper that takes care of checking path_importer_cache and then walking sys.path_hooks, I believe the actual culprit is FileFinder.path_hook()("") returning None (I'm currently downloading and installing 3.3b1 on my gaming machine to confirm that)

----------
components: Library (Lib)
messages: 165752
nosy: brett.cannon, georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: FileFinder.path_hook()("") returns None on Windows
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 18 13:12:06 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:12:06 +0000
Subject: [New-bugs-announce] [issue15385] Behaviour change in runpy for
	__file__ attributes	between 3.2 and 3.3
Message-ID: <1342609926.32.0.323615194944.issue15385@psf.upfronthosting.co.za>


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

Directory setup: linkdir is a symlink to realdir

$ python3 -c "import sys; sys.path.insert(0, 'linkdir'); import runpy; print(runpy.run_module('foo')['__file__'])"
/home/ncoghlan/devel/play/realdir/foo.py
$ ../py3k/python -c "import sys; sys.path.insert(0, 'linkdir'); import runpy; print(runpy.run_module('foo')['__file__'])"
/home/ncoghlan/devel/play/linkdir/foo.py

The culprit is pkgutil - the import emulation includes a realpath() call. Looking at the log, this dates from PJE's consolidation of the various import emulations back in 2006, with no specific rationale given.

Since this was only in the emulation, and nothing else broke when we took it out (indeed, it was the cause of test failures in 3.2, when it altered the __file__ values in ways the test wasn't expecting), I'm just creating and closing this issue to note that yes, I'm aware this has changed, but no, I don't consider it a problem, as it just brings pkgutil into line with the behaviour of normal imports.

----------
messages: 165754
nosy: brett.cannon, georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: Behaviour change in runpy for __file__ attributes between 3.2 and 3.3
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 18 13:31:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:31:34 +0000
Subject: [New-bugs-announce] [issue15386] Still getting two copies of
	importlib._boostrap
Message-ID: <1342611094.8.0.638334167677.issue15386@psf.upfronthosting.co.za>


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

I haven't worked out how yet, but importlib.machinery is managing to bypass the replacement of importlib._bootstrap with _frozen_importlib:

Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib._bootstrap
[74500 refs]
>>> import importlib.machinery
[74500 refs]
>>> importlib.machinery.FileFinder
<class 'importlib._bootstrap.FileFinder'>
[74505 refs]
>>> importlib._bootstrap.FileFinder
<class '_frozen_importlib.FileFinder'>
[74505 refs]
>>> importlib.machinery.FileFinder.path_hook()("")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/importlib/_bootstrap.py", line 1350, in path_hook_for_FileFinder
    if not _path_isdir(path):
  File "/home/ncoghlan/devel/py3k/Lib/importlib/_bootstrap.py", line 117, in _path_isdir
    path = _os.getcwd()
NameError: global name '_os' is not defined
[74566 refs]
>>> importlib._bootstrap.FileFinder.path_hook()("")
FileFinder('.')

----------
messages: 165757
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Still getting two copies of importlib._boostrap

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

From report at bugs.python.org  Wed Jul 18 13:56:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Jul 2012 11:56:13 +0000
Subject: [New-bugs-announce] [issue15387] pkgutil.walk_packages is using a
	deprecated API
Message-ID: <1342612573.81.0.647626142545.issue15387@psf.upfronthosting.co.za>


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

$ ./python -Wdefault
Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkgutil
>>> list(pkgutil.walk_packages("."))
/home/ncoghlan/devel/py3k/Lib/inspect.py:453: DeprecationWarning: inspect.getmoduleinfo() is deprecated
  info = getmoduleinfo(path)
/home/ncoghlan/devel/py3k/Lib/inspect.py:445: DeprecationWarning: imp.get_suffixes() is deprecated; use the constants defined on importlib.machinery instead
  for suffix, mode, mtype in imp.get_suffixes()]
[(FileFinder('.'), 'foo', False), (FileFinder('.'), 'python-gdb', False), (FileFinder('.'), 'setup', False)]

The problem is the calls to inspect.getmodulename().

Do these APIs really need to be deprecated? Can't they just be redirected to importlib instead?

----------
components: Library (Lib)
messages: 165759
nosy: brett.cannon, georg.brandl, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: pkgutil.walk_packages is using a deprecated API
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 18 16:17:30 2012
From: report at bugs.python.org (Matt Hillsdon)
Date: Wed, 18 Jul 2012 14:17:30 +0000
Subject: [New-bugs-announce] [issue15388] SAX parse (ExpatParser) leaks file
	handle when given	filename input
Message-ID: <1342621050.08.0.170764357594.issue15388@psf.upfronthosting.co.za>


New submission from Matt Hillsdon <mth at corefiling.com>:

The following example uses make_parser / parse to read a trivial XML document by filename and then attempts to delete the file.  On Win32 I can't unlink the file because the parse does not seem to close the file handle.


import os
import tempfile
from xml.sax import make_parser, ContentHandler

(handle, path) = tempfile.mkstemp()
os.write(handle, b"<foo/>")
os.close(handle)

parser = make_parser()
parser.parse(path)

# This unlink fails on win32.  It succeeds if I comment out the call to parse.
os.unlink(path)


As I provide a filename rather than a file object, I would expect the parse call to both open and close it.  I can't see a way to do the clean-up myself.

This issue exists in Python 2.7.3 but I could not reproduce it in 3.2.3.


Windows cmd transcript:

c:\Users\mth>Python2.7.3\python.exe fileleak.py
Traceback (most recent call last):
  File "fileleak.py", line 14, in <module>
    os.unlink(path)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\d\\tmpvyqg2c'

c:\Users\mth>Python3.2.3\python.exe fileleak.py

c:\Users\mth>

----------
components: XML
messages: 165779
nosy: mth
priority: normal
severity: normal
status: open
title: SAX parse (ExpatParser) leaks file handle when given filename input
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 18 23:30:07 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 18 Jul 2012 21:30:07 +0000
Subject: [New-bugs-announce] [issue15389] PEP 3121,
	384 refactoring applied to curses module
Message-ID: <1342647007.31.0.0527373490627.issue15389@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

Changes proposed in PEP3121 and PEP384 applied to the curses module. As these Changes do not alter behaviour of the specific modules, I would encourage to see this enhancement as a "bugfix" and consequently include this into the coming Python 3.3 release.

----------
components: Extension Modules
files: _cursesmodule_pep3121-384_v0.patch
keywords: patch
messages: 165804
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to curses module
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file26430/_cursesmodule_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Jul 18 23:33:52 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 18 Jul 2012 21:33:52 +0000
Subject: [New-bugs-announce] [issue15390] PEP 3121,
	384 refactoring applied to datetime module
Message-ID: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

Changes proposed in PEP3121 and PEP384 have now been applied to the datetime module!

----------
components: Extension Modules
files: _datetimemodule_pep3121-384_v0.patch
keywords: patch
messages: 165805
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to datetime module
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file26431/_datetimemodule_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Jul 19 01:32:23 2012
From: report at bugs.python.org (anon)
Date: Wed, 18 Jul 2012 23:32:23 +0000
Subject: [New-bugs-announce] [issue15391] Add bitlength function to the math
	module
Message-ID: <1342654343.1.0.00342933769834.issue15391@psf.upfronthosting.co.za>


New submission from anon <UnluckyKitten at mailinator.com>:

Many numeric algorithms require knowing the number of bits an integer has (for instance integer squareroots). For example this simple algorithm using shifts is O(n^2):

def bitl(x):
  x = abs(x)
  n = 0
  while x > 0:
    n = n+1
    x = x>>1
  return n

A simple O(n) algorithm exists:

def bitl(x):
  if x==0: return 0
  return len(bin(abs(x)))-2

It should be possible find the bit-length of an integer in O(1) however. O(n) algorithms with high constants simply don't cut it for many applications.

That's why I would propose adding an inbuilt function bitlength(n) to the math module. bitlength(n) would be the integer satisfying

  bitlength(n) = ceil(log2(abs(n)+1))

Python more than ever with PyPy progressing is becoming a great platform for mathematical computation. This is an important building block for a huge number of algorithms but currently has no elegant or efficient solution in plain Python.

----------
components: Library (Lib)
messages: 165818
nosy: anon
priority: normal
severity: normal
status: open
title: Add bitlength function to the math module
type: enhancement

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

From report at bugs.python.org  Thu Jul 19 06:44:40 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Jul 2012 04:44:40 +0000
Subject: [New-bugs-announce] [issue15392] Create a unittest framework for
	IDLE
Message-ID: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Idle needs a unittest framework for module test modules. This means a test directory with at least one test module, a runtest module that successfully runs that test module, any new support functions needed for that test module, and inclusion of test_idle in Lib/test.

I am thinking of something like Lib/tkinter/test, but without subdirectories. I presume there should be something like tkinter/test/runtests, but I do not know if it reflects current best practice, nor whether it should be in idlelib or in idlelib/test.

One feature of runtests and the tkinter framework is separation of tests that do and do not require a gui. This requires cooperation of writers of each test module. Buildbots can only run tests that do not require a gui and nearly everyone else wants the same. On the other hand, we need automated gui tests too. A complete test of idlelib/runtest requires a test module with both kinds of tests.

List/test has test_tk. It runs tests with enable_gui=false unless run directly (and intentionally) as the main module. (Testing test_idle would also require tests in both modes.) It checks that tkinter is available. Should test_idle also check that idle is available? (On Windows, one can install both or neither. I don't know the situation on other systems.)

This issue was inspired by #12510 and is interdependent with it. As part of that issue, I would like to convert the expanded test set to run under unittest. #12510 needs a place to put a test_calltips module. On the other hand, this issue needs a test_x module to test runtests and test_idle.

tkinter/test/support has functions that can be used in idle tests, in particular, simulate_mouse_click(). I believe a needed addition is simulate_text_entry. That is needed to really finish the calltips tests. Currently, complete testing of tooltips requires non-automated hand tests.

Would simulate_mouse_click include selecting menu items, or would that be a separate function?

With such a test framework established, we could start adding tests as part of other issues, as is normal practice.

(Note: tkinter/test is pretty skeletal, and probably could use expansion, but except for support functions immediately needed for test_calltips, that is another issue.)

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 165825
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Create a unittest framework for IDLE
type: enhancement
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul 19 12:09:56 2012
From: report at bugs.python.org (Antti Laine)
Date: Thu, 19 Jul 2012 10:09:56 +0000
Subject: [New-bugs-announce] [issue15393] JSONDecoder.raw_decode breaks on
	leading whitespace
Message-ID: <1342692596.02.0.962530841473.issue15393@psf.upfronthosting.co.za>


New submission from Antti Laine <antti.a.laine at iki.fi>:

raw_decode on json.JSONDecoder does not handle leading whitespace. According to RFC 4627, section 2, whitespace can precede an object. With json.loads leading whitespace is handled just fine.

d = json.JSONDecoder()
d.raw_decode(' {}')
ValueError: No JSON object could be decoded

Tested with versions 2.6.7, 2.7.3, 3.1.3 and 3.2.3

----------
components: Library (Lib)
messages: 165829
nosy: Antti Alien
priority: normal
severity: normal
status: open
title: JSONDecoder.raw_decode breaks on leading whitespace
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jul 19 15:24:56 2012
From: report at bugs.python.org (Julia Lawall)
Date: Thu, 19 Jul 2012 13:24:56 +0000
Subject: [New-bugs-announce] [issue15394] memory leak in PyModule_Create2
Message-ID: <1342704296.69.0.163968791178.issue15394@psf.upfronthosting.co.za>


New submission from Julia Lawall <julia.lawall at lip6.fr>:

In objects/moduleobject.c, in the function PyModule_Create2, it appears that m should be decrefed on all of the failure paths between its allocation and the return from the function.

----------
files: moduleobject.patch
keywords: patch
messages: 165838
nosy: jll
priority: normal
severity: normal
status: open
title: memory leak in PyModule_Create2
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file26435/moduleobject.patch

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

From report at bugs.python.org  Thu Jul 19 16:08:35 2012
From: report at bugs.python.org (Julia Lawall)
Date: Thu, 19 Jul 2012 14:08:35 +0000
Subject: [New-bugs-announce] [issue15395] memory leaks in selectmodule.c
Message-ID: <1342706915.13.0.364498242377.issue15395@psf.upfronthosting.co.za>


New submission from Julia Lawall <julia.lawall at lip6.fr>:

In Modules/selectmodule.c, in the function seq2set, fast_seq should be decrefd on failure of the initialization of o.  This will make a useless call to DECREF on o, but XDECREF is already used, so it is safe in the NULL case.

In the same file, in the function poll_modify, key should be decrefed on all execution paths that lead out of the function.

----------
files: selectmodule.patch
keywords: patch
messages: 165840
nosy: jll
priority: normal
severity: normal
status: open
title: memory leaks in selectmodule.c
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file26436/selectmodule.patch

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

From report at bugs.python.org  Thu Jul 19 16:35:26 2012
From: report at bugs.python.org (Julia Lawall)
Date: Thu, 19 Jul 2012 14:35:26 +0000
Subject: [New-bugs-announce] [issue15396] memory leak in tkinter
Message-ID: <1342708526.81.0.949567135127.issue15396@psf.upfronthosting.co.za>


New submission from Julia Lawall <julia.lawall at lip6.fr>:

In the file Modules/_tkinter.c, in the function PyInit__tkinter, m should be decrefed on the PyType_Ready error path.

----------
files: tkinter.patch
keywords: patch
messages: 165842
nosy: jll
priority: normal
severity: normal
status: open
title: memory leak in tkinter
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file26437/tkinter.patch

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

From report at bugs.python.org  Thu Jul 19 19:29:06 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Thu, 19 Jul 2012 17:29:06 +0000
Subject: [New-bugs-announce] [issue15397] Unbinding of methods
Message-ID: <1342718946.15.0.133705372041.issue15397@psf.upfronthosting.co.za>


New submission from Stefan Mihaila <mstefanro at gmail.com>:

In order to implement pickling of instance methods, a means of separating
the object and the unbound method is necessary.

This is easily done for Python methods (f.__self__ and f.__func__),
but not all of builtins support __func__. Moreover, there currently
appears to be no good way to distinguish functions from bound methods.

As a first step in solving this issue, I have attached a patch which:
1) adds __func__ for all function types
2) adds a few new definitions in the types module (AllFunctionTypes etc.)
3) adds isanyfunction(), isanyboundfunction(), isanyunboundfunction() in
  inspect (admittedly these are bad names)
4) functools.unbind

In case applying this patch is being considered, serious review is necessary,
as I'm not knowledgeable of cpython internals.

----------
components: Library (Lib)
files: func.patch
keywords: patch
messages: 165845
nosy: mstefanro
priority: normal
severity: normal
status: open
title: Unbinding of methods
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26438/func.patch

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

From report at bugs.python.org  Thu Jul 19 20:33:57 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Thu, 19 Jul 2012 18:33:57 +0000
Subject: [New-bugs-announce] [issue15398] intermittence on
	UnicodeFileTests.test_rename at	test_pep277 on MacOS X
Message-ID: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>


New submission from Fl?vio Ribeiro <email at flavioribeiro.com>:

Found a intermittent test on UnicodeFileTests.test_rename method.

Python Version: Python 3.3.0b1
Hg commit hash: 3fbfa61634de
MacOS X version 10.6.8 

How can be reproduced:

bumblebee:~/dev/cpython[] $ for i in {1..10}; do ./python.exe  -m test test_pep277; done
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/flavio.barbosa/dev/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_51143_tmp/8_???'

1 test failed:
    test_pep277
[103879 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/flavio.barbosa/dev/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_51145_tmp/3_Gr??-Gott'

1 test failed:
    test_pep277
[103879 refs]
[1/1] test_pep277
1 test OK.
[103867 refs]
[1/1] test_pep277
test test_pep277 failed -- Traceback (most recent call last):
  File "/Users/flavio.barbosa/dev/cpython/Lib/test/test_pep277.py", line 172, in test_rename
    os.rename("tmp", name)
FileNotFoundError: [Errno 2] No such file or directory: '@test_51147_tmp/6_???'

1 test failed:
    test_pep277
[103879 refs]

----------
assignee: ronaldoussoren
components: Macintosh
messages: 165849
nosy: flavio.ribeiro, ronaldoussoren
priority: normal
severity: normal
status: open
title: intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 19 20:40:51 2012
From: report at bugs.python.org (Gunnlaugur Thor Briem)
Date: Thu, 19 Jul 2012 18:40:51 +0000
Subject: [New-bugs-announce] [issue15399] processName key is
	un-/mis-documented in 2.6 and up
Message-ID: <1342723251.3.0.517934021782.issue15399@psf.upfronthosting.co.za>


New submission from Gunnlaugur Thor Briem <gunnlaugur at gmail.com>:

The ``processName`` format mapping key in logging formats works in versions 2.6.*, 2.7.* and 3.1.* onwards; in 2.5 and down and in 3.0.1, ``format`` fails when this key is present in the format.

But in 2.6.8 docs, this mapping key is not documented:

http://docs.python.org/release/2.6.8/library/logging.html
http://docs.python.org/release/3.0.1/library/logging.html

and in 2.7.3 and 3.1.5 and 3.2.3 docs, it is documented but there is no note that it is new in any particular version (unlike ``funcName``, for which there is ?Changed in version 2.5: funcName was added?):

http://docs.python.org/release/2.7.3/library/logging.html
http://docs.python.org/release/3.1.5/library/logging.html
http://docs.python.org/release/3.2.3/library/logging.html

Consistent with (what I think are the) version note conventions, these seem like the actions to take:

- In 2.6 docs, add processName, and insert the note ?Changed in version 2.6: processName was added?

- In 2.7 docs, insert that same note

- In docs for 3.1 and up, insert the note ?Changed in version 3.1: processName was added?

----------
assignee: docs at python
components: Documentation
messages: 165852
nosy: docs at python, gthb
priority: normal
severity: normal
status: open
title: processName key is un-/mis-documented in 2.6 and up
type: enhancement
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/issue15399>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:21:43 2012
From: report at bugs.python.org (Michael Smith)
Date: Thu, 19 Jul 2012 19:21:43 +0000
Subject: [New-bugs-announce] [issue15400] int('12345L', 10) raises ValueError
Message-ID: <1342725703.62.0.185151812614.issue15400@psf.upfronthosting.co.za>


New submission from Michael Smith <kojiromike at gmail.com>:

The trailing 'L' in representations of long integers causes the int function to raise a ValueError. This is unexpected because it's reasonable to expect that `int` should be able to parse a number from any string when that string represented as a bare word would be a valid python number. The following all raise ValueError:

int(hex(12345L), 16)
int(oct(12345L), 8)

but not

int('12345', 10)
int(hex(12345), 16)
int(oct(12345), 8)
(and not bin() because of http://bugs.python.org/issue3186)

----------
components: Interpreter Core
messages: 165862
nosy: Michael.Smith
priority: normal
severity: normal
status: open
title: int('12345L', 10) raises ValueError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 20 03:12:30 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Jul 2012 01:12:30 +0000
Subject: [New-bugs-announce] [issue15401] Typo in inspect.getclosurevars
	docstring
Message-ID: <1342746750.35.0.68261172869.issue15401@psf.upfronthosting.co.za>


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

s/dics/dicts/

http://hg.python.org/cpython/file/default/Lib/inspect.py#l1049

----------
assignee: ncoghlan
messages: 165893
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Typo in inspect.getclosurevars docstring

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

From report at bugs.python.org  Fri Jul 20 08:49:26 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jul 2012 06:49:26 +0000
Subject: [New-bugs-announce] [issue15402] Correct __sizeof__ support for
	struct
Message-ID: <1342766966.6.0.629613647598.issue15402@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements __sizeof__ for struct.Struct.

See also issue14596.

----------
components: Library (Lib)
files: struct_sizeof-2.patch
keywords: patch
messages: 165902
nosy: mark.dickinson, meador.inge, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for struct
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26444/struct_sizeof-2.patch

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

From report at bugs.python.org  Fri Jul 20 13:13:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 20 Jul 2012 11:13:13 +0000
Subject: [New-bugs-announce] [issue15403] Refactor package creation support
	code into a common	location
Message-ID: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue addresses the "file creation" portion of issue 15376, which is to refactor the walk_package support code in test_runpy into a common location.

----------
components: Tests
keywords: easy
messages: 165910
nosy: cjerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: Refactor package creation support code into a common location
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 20 13:42:53 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Jul 2012 11:42:53 +0000
Subject: [New-bugs-announce] [issue15404] Refleak in PyMethodObject repr
Message-ID: <1342784573.74.0.322752572282.issue15404@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Python leaks in method.__repr__ if class has no __name__.
Very rare situation.

----------
assignee: asvetlov
components: Interpreter Core
files: leak.diff
keywords: patch
messages: 165913
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Refleak in PyMethodObject repr
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26448/leak.diff

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

From report at bugs.python.org  Fri Jul 20 15:09:48 2012
From: report at bugs.python.org (reynaldo)
Date: Fri, 20 Jul 2012 13:09:48 +0000
Subject: [New-bugs-announce] [issue15405] Invitation to connect on LinkedIn
Message-ID: <521105205.7590960.1342789784588.JavaMail.app@ela4-app0133.prod>


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

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- reynaldo

reynaldo bendijo
owner at www.omickiey.com
Greater Los Angeles Area

Confirm that you know reynaldo bendijo:
https://www.linkedin.com/e/-3qcne3-h4vad8ug-3t/isd/4079929199/bZ2HS2mr/?hs=false&tok=3ElCzFvFARvlk1

----------
messages: 165920
nosy: renben
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Fri Jul 20 16:44:07 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 14:44:07 +0000
Subject: [New-bugs-announce] [issue15406] Deprecation Warnings fixes on test
	suite
Message-ID: <1342795447.04.0.0636539536415.issue15406@psf.upfronthosting.co.za>


New submission from Fl?vio Ribeiro <email at flavioribeiro.com>:

Looking for bugs to be solved on a cPython Sprint, Hynek reported at core-mentorship list some Deprecation Warnings running the test suite in regression mode. 

This issue aims to solve this warnings.

----------
components: Tests
messages: 165933
nosy: flavio.ribeiro
priority: normal
severity: normal
status: open
title: Deprecation Warnings fixes on test suite
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 20 17:43:01 2012
From: report at bugs.python.org (Cal Leeming)
Date: Fri, 20 Jul 2012 15:43:01 +0000
Subject: [New-bugs-announce] [issue15407] CSV parser fails to iterate
	properly on 2.6.6
Message-ID: <1342798982.0.0.719317357124.issue15407@psf.upfronthosting.co.za>


New submission from Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:

Getting some extremely strange behavior when attempting to parse a fairly standard CSV in Python 2.6.6.

I've tried a whole different mixture of dialects, quoting options, line terminators etc, and none seem to get a happy ending.

Spent about 2 hours banging my head against a brick wall on this, and struggling to see how the CSV libs could be so fundamentally broken, given that I couldn't find any other related bugs.

I have attempted to parse the following CSV data:

"First","Middle","Last","Nickname","Email","Category"
"Moe","","Howard","Moe","moe at 3stooges.com","actor"
"Jerome","Lester","Howard","Curly","curly at 3stooges.com","actor"
"Larry","","Fine","Larry","larry at 3stooges.com","musician"
"Jerome","","Besser","Joe","joe at 3stooges.com","actor"
"Joe","","DeRita","CurlyJoe","curlyjoe at 3stooges.com","actor"
"Shemp","","Howard","Shemp","shemp at 3stooges.com","actor"

The code used to parse was this:

datx = open("data.txt", "rb").read()
rows = csv.reader( datx , dialect="wat")
for row in rows:
    print x

The output given is this:

['First']
['', '']
['Middle']
['', '']
['Last']
['', '']
['Nickname']
['', '']
['Email']
['', '']
['Category']
[]
['Moe']
['', '']
['']
['', '']
['Howard']
['', '']
['Moe']
['', '']
['moe at 3stooges.com']
['', '']
['actor']
[]
['Jerome']
['', '']
['Lester']
['', '']
['Howard']
['', '']
['Curly']
['', '']
['curly at 3stooges.com']
['', '']
['actor']
[]
['Larry']
['', '']
['']
['', '']
['Fine']
['', '']
['Larry']
['', '']
['larry at 3stooges.com']
['', '']
['musician']
[]
['Jerome']
['', '']
['']
['', '']
['Besser']
['', '']
['Joe']
['', '']
['joe at 3stooges.com']
['', '']
['actor']
[]
['Joe']
['', '']
['']
['', '']
['DeRita']
['', '']
['CurlyJoe']
['', '']
['curlyjoe at 3stooges.com']
['', '']
['actor']
[]
['Shemp']
['', '']
['']
['', '']
['Howard']
['', '']
['Shemp']
['', '']
['shemp at 3stooges.com']
['', '']
['actor']
[]

----------
components: None
messages: 165938
nosy: sleepycal
priority: normal
severity: normal
status: open
title: CSV parser fails to iterate properly on 2.6.6
versions: Python 2.6

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

From report at bugs.python.org  Fri Jul 20 17:56:00 2012
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 20 Jul 2012 15:56:00 +0000
Subject: [New-bugs-announce] [issue15408] os.fork/os.popen behaviour change
	between 2.7 and 3.2
Message-ID: <1342799760.81.0.0479132559422.issue15408@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

The attached script behaves differently on Python 2.7.2 and Python 3.2.3.

With Python 2.7 the script runs for ca. 30 seconds and then I get back my prompt.

With Python 3.2 the script runs in the background, I get back my prompt immediately and can type shell commands.

Commenting out the call to uname() changes the behaviour of the script on Python 3.2 so that it behaves like on Python 2.7.

(This happens on both Max OS X 10.7 and Linux.)

----------
files: gurk.py
messages: 165942
nosy: doerwalter
priority: normal
severity: normal
status: open
title: os.fork/os.popen behaviour change between 2.7 and 3.2
versions: Python 3.2
Added file: http://bugs.python.org/file26456/gurk.py

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

From report at bugs.python.org  Fri Jul 20 19:50:18 2012
From: report at bugs.python.org (=?utf-8?q?Fl=C3=A1vio_Ribeiro?=)
Date: Fri, 20 Jul 2012 17:50:18 +0000
Subject: [New-bugs-announce] [issue15409] Deprecation Warning fix on
	cookiejar module
Message-ID: <1342806618.21.0.425408251196.issue15409@psf.upfronthosting.co.za>


New submission from Fl?vio Ribeiro <email at flavioribeiro.com>:

Cookiejar calls some urllib.Request's deprecated methods. This patch fixes this deprecated calls.

----------
components: Extension Modules
files: cookiejar_fix_deprecated_method_calls.patch
keywords: patch
messages: 165956
nosy: flavio.ribeiro
priority: normal
severity: normal
status: open
title: Deprecation Warning fix on cookiejar module
versions: Python 3.3
Added file: http://bugs.python.org/file26457/cookiejar_fix_deprecated_method_calls.patch

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

From report at bugs.python.org  Sat Jul 21 02:35:10 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 21 Jul 2012 00:35:10 +0000
Subject: [New-bugs-announce] [issue15410]
	urllib.request.Request.is_unverifiable
	deprecation	documentation is incorrect
Message-ID: <1342830910.16.0.163498424458.issue15410@psf.upfronthosting.co.za>


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

While reviewing the change for issue15409 I noticed that the 'urlib.request' documentation has an error in the deprecation note for 'urllib.request.Request.is_unverifiable' [1]:

"""
Deprecated in 3.3, use Request.is_unverifiable.
"""

The deprecation text of 'is_unverifiable' shouldn't be recommending 'is_unverifiable' as a replacement :-)  The text should actually read:

"""
Deprecated in 3.3, use Request.unverifiable.
"""

I will patch this shortly.

[1] http://docs.python.org/dev/library/urllib.request.html#urllib.request.Request.is_unverifiable

----------
assignee: meador.inge
components: Documentation
messages: 165990
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request.Request.is_unverifiable deprecation documentation is incorrect
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 21 10:31:24 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 21 Jul 2012 08:31:24 +0000
Subject: [New-bugs-announce] [issue15411] os.chmod() does not follow
	symlinks on Windows
Message-ID: <1342859484.11.0.980886642738.issue15411@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

os.chmod() should check symlinks if followsymlinks option is True on Windows. 

This is a cause of failure of test case 

   test.test_shutil.TestShutil.test_copymode_follow_symlinks

(#13837)

----------
components: Library (Lib), Windows
files: chmod_symlink_win32.patch
keywords: patch
messages: 165996
nosy: ishimoto
priority: normal
severity: normal
status: open
title: os.chmod() does not follow symlinks on Windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26462/chmod_symlink_win32.patch

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

From report at bugs.python.org  Sat Jul 21 11:41:58 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 21 Jul 2012 09:41:58 +0000
Subject: [New-bugs-announce] [issue15412] Note in documentation for weakrefs
Message-ID: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

In the documentation on weakrefs there is the following quote

    Note: Weak references to an object are cleared before the object?s
    __del__() is called, to ensure that the weak reference callback 
    (if any) finds the object still alive.

But I think the weakref is always dead by the time the callback is invoked.  The first paragraph from the documentation for weakref.ref(object[, callback]) contains the following:

    If callback is provided and not None, and the returned weakref 
    object is still alive, the callback will be called when the object 
    is about to be finalized; the weak reference object will be passed 
    as the only parameter to the callback; **the referent will no longer 
    be available**.

Which does prompt a question: what use is there for the weakref argument to the callback if it already dead?

(Compare http://bugs.python.org/issue14933)

----------
assignee: docs at python
components: Documentation
messages: 166002
nosy: docs at python, pitrou, sbt
priority: normal
severity: normal
status: open
title: Note in documentation for weakrefs

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

From report at bugs.python.org  Sat Jul 21 18:27:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 16:27:26 +0000
Subject: [New-bugs-announce] [issue15413] os.times() disappeared under
	Windows
Message-ID: <1342888046.96.0.718260213751.issue15413@psf.upfronthosting.co.za>


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

This is from issue #15118.

Python 3.3.0b1 (v3.3.0b1:e15c554cd43e+, Jun 26 2012, 20:41:17) [MSC v.1600 64 bi
t (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.times()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'times'

----------
assignee: larry
components: Library (Lib)
messages: 166045
nosy: georg.brandl, larry, pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: os.times() disappeared under Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 21 22:41:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 20:41:08 +0000
Subject: [New-bugs-announce] [issue15414] os.path.join behavior on Windows
	(ntpath.join) is	unexpected and not well documented
Message-ID: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In looking at another os.path.join documentation issue I tried the Windows join to see if it matched the docs, and found that it was very unclear.   I searched the tracker and found Issue 1669539, which contains much relevant discussion but also much discussion of possible enhancements.  So I'm opening a new issue *just* about what I see as the current bugs in the os.path.join docs and ntpath.join implementation.

I'm not qualified to fix this, not being a Windows user, but it is clear to me that the documentation of os.path.join for Windows is unclear (it does not indicate what is considered an absolute path on Windows) and wrong (\foo will *not* restart the path if it is the second element and follows a drive specification, but it does any other time), and that the current behavior may have a bug if, as seems to be implied by the issue 1669539 discussion, something that looks like a drive specification in the middle of a path is invalid on Windows.  If this last is not a bug, it should be mentioned in the documentation, since the actual behavior is counter-intuitive.

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 166065
nosy: brian.curtin, christian.heimes, docs at python, eckhardt, ezio.melotti, jorend, mhammond, r.david.murray, terry.reedy, tim.golden
priority: normal
severity: normal
status: open
title: os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 21 23:13:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 21 Jul 2012 21:13:18 +0000
Subject: [New-bugs-announce] [issue15415] Add temp_dir() and change_cwd() to
	test.support
Message-ID: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is partly in service to issue 15376, which is to refactor test_runpy's walk_package support code into a common location.

Currently, the temp_cwd() context manager in test.support does two things: it creates a temp directory, and it changes the current working directory.

It would be useful and clearer if test.support exposed these two things as separate context managers.  This will both let us simplify the implementation of temp_cwd() and give us an opportunity to increase code reuse between test.support and test.script_helper.  (Currently, test.script_helper has its own version of temp_dir(), whose functionality overlaps with temp_cwd().)

I will upload a patch shortly with tests.

----------
components: Tests
keywords: easy
messages: 166071
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Add temp_dir() and change_cwd() to test.support
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 21 23:54:35 2012
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 21 Jul 2012 21:54:35 +0000
Subject: [New-bugs-announce] [issue15416] 3 * [] gives a list of 3
	cross-referenced lists, a[1]='blash
Message-ID: <1342907675.08.0.583810202929.issue15416@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

Hi,
  I thought that I can easily create a list of, say 3, nested lists:

$ python
Python 2.7.3 (default, May 17 2012, 21:10:41) 
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3 * [[]]
[[], [], []]
>>> a=3 * [[]]
>>> a[0]
[]
>>> a[1].append('sdds')
>>> a
[['sdds'], ['sdds'], ['sdds']]
>>> a[0].append('xxx')
>>> a
[['sdds', 'xxx'], ['sdds', 'xxx'], ['sdds', 'xxx']]


The below works as expected.

>>> a=[[], [], []]
>>> a
[[], [], []]
>>> a[0]
[]
>>> a[1]
[]
>>> a[1].append('sdds')
>>> a[0].append('xxx')
>>> a
[['xxx'], ['sdds'], []]
>>>


Of course, I want to do like:

a = len(b) * [] # to get a list of individual hashes
c = len(b) * [0] # to get a list of indvidual counters

----------
components: None
messages: 166081
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: 3 * [] gives a list of 3 cross-referenced lists, a[1]='blash
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 22 02:04:38 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 00:04:38 +0000
Subject: [New-bugs-announce] [issue15417] Add support for csh and fish in
	venv activation scripts
Message-ID: <1342915478.17.0.0181949280241.issue15417@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: Library (Lib)
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Add support for csh and fish in venv activation scripts
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 22 10:14:27 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:14:27 +0000
Subject: [New-bugs-announce] [issue15418] 2to3 docs should mention setup.py
	fixes required to	install compatible packages in Python 3
Message-ID: <1342944867.41.0.426616116312.issue15418@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/library/2to3.html

   should mention the practice of running 2to3 in setup.py for codebase compatible with both Python 2 and Python 3.

----------
assignee: docs at python
components: Documentation
messages: 166108
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: 2to3 docs should mention setup.py fixes required to install compatible packages in Python 3
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 22 10:32:56 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:32:56 +0000
Subject: [New-bugs-announce] [issue15419] distutils: build_py_2to3 should
	use a separate build	directory
Message-ID: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za>


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

This scenario fails:
  python setup.py install
  python3 setup.py install

Because it seems like code once built for Python 2 is not rebuild when installing for Python 3.

----------
assignee: eric.araujo
components: Distutils, Distutils2
messages: 166109
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: distutils: build_py_2to3 should use a separate build directory
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 22 10:48:47 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:48:47 +0000
Subject: [New-bugs-announce] [issue15420] issue6964 reminder
Message-ID: <1342946927.66.0.390165959934.issue15420@psf.upfronthosting.co.za>


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

issue6964 is closed, so this is a reminder that discussion over the actual issue is not finished yet.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 166111
nosy: techtonik
priority: normal
severity: normal
status: open
title: issue6964 reminder
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 22 16:25:44 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 22 Jul 2012 14:25:44 +0000
Subject: [New-bugs-announce] [issue15421] Calendar.itermonthdates
	OverflowError
Message-ID: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za>


New submission from C?dric Krier <cedric.krier at b2ck.com>:

itermonthdates fails when working on the last month of 9999
Here is a patch that catch the OverflowError.

----------
components: Library (Lib)
files: calendar.patch
keywords: patch
messages: 166137
nosy: ced
priority: normal
severity: normal
status: open
title: Calendar.itermonthdates OverflowError
type: enhancement
Added file: http://bugs.python.org/file26478/calendar.patch

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

From report at bugs.python.org  Sun Jul 22 16:33:03 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 14:33:03 +0000
Subject: [New-bugs-announce] [issue15422] Get rid of PyCFunction_New macro
Message-ID: <1342967583.47.0.436061975286.issue15422@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

For now (3.3 beta) PyCFunction_New defined as macro calling PyCFunction_NewEx.
To be compatible with PEP 384 (Defining a Stable ABI) Objects/methodobject.c has trampoline function named PyCFunction_New which calls PyCFunction_NewEx.
This is only single usage of this idiom in CPython code.
For sake of uniformity we need to:
 - remove PyCFunction_New macro from Include/methodobject.h
 - declare PyCFunction_New as function in Include/methodobject.h
 - replace all calls of PyCFunction_New to PyCFunction_NewEx in code (about 8 occurrences).

----------
assignee: asvetlov
components: Interpreter Core
messages: 166138
nosy: asvetlov, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: Get rid of PyCFunction_New macro
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul 22 17:01:19 2012
From: report at bugs.python.org (AliDD)
Date: Sun, 22 Jul 2012 15:01:19 +0000
Subject: [New-bugs-announce] [issue15423] Minidom tries to parse tags inside
	of <script> tag
Message-ID: <1342969279.78.0.082488772404.issue15423@psf.upfronthosting.co.za>


New submission from AliDD <registration000 at web.de>:

Attempt to parse the string
<script type="text/javascript">document.write('<bb></b>');</script>
by calling minidom.parseString()
causes ExpatError: mismatched tag: line 1, column 53
in lib\xml\dom\expatbuilder.py at line 223.

It looks like the parser detects open / closing tag mismatch, trying to parse <bb></b>.

----------
components: Library (Lib)
messages: 166139
nosy: AliDD
priority: normal
severity: normal
status: open
title: Minidom tries to parse tags inside of <script> tag
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 22 18:22:41 2012
From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=)
Date: Sun, 22 Jul 2012 16:22:41 +0000
Subject: [New-bugs-announce] [issue15424] __sizeof__ of array should include
	size of items
Message-ID: <1342974161.65.0.374402048104.issue15424@psf.upfronthosting.co.za>


New submission from Ludwig H?hne <wkx at gmx.li>:

If sys.getsizeof is called on an array, the result doesn't include the size of the items: 

>>> from array import array
>>> a = array("i", [0] * 100000)
>>> a.__sizeof__()
40

While this makes sense for a list, an array doesn't have separate referents that could be sized:

>>> import gc
>>> gc.get_referents(a)
[]

The attached patch adds an implementation of the __sizeof__ method for arrays that includes the size of the buffer for the elements.

It would be great if the patch would be considered for one of the upcoming versions of Python.

Thanks, Ludwig

----------
components: Library (Lib)
files: array_sizeof.patch
keywords: patch
messages: 166147
nosy: Pankrat
priority: normal
severity: normal
status: open
title: __sizeof__ of array should include size of items
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26479/array_sizeof.patch

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

From report at bugs.python.org  Sun Jul 22 22:07:02 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 22 Jul 2012 20:07:02 +0000
Subject: [New-bugs-announce] [issue15425] Another strange Tracebacks with
	importlib
Message-ID: <1342987622.49.0.633292920923.issue15425@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Two "easy" ways to get tracebacks which contain useless importlib._bootstrap rows:
- When there is a syntax error in the imported module
- On "import package.module", when top-level package cannot be imported


$ ./python -c "import foo"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1421, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1388, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 527, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 899, in load_module
  File "<frozen importlib._bootstrap>", line 880, in load_module
  File "<frozen importlib._bootstrap>", line 503, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 744, in _load_module
  File "<frozen importlib._bootstrap>", line 857, in get_code
  File "./foo.py", line 1
    invalid syntax
                 ^
SyntaxError: invalid syntax


$ ./python
Python 3.3.0b1 (default:afdb0e1a9dac+, Jul 19 2012, 23:55:02) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _sqlite3
>>> del _sqlite3.register_converter
>>> import sqlite3.dump
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1421, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1372, in _find_and_load_unlocked
  File "/home/amauryfa/python/cpython3.x/Lib/sqlite3/__init__.py", line 23, in <module>
    from sqlite3.dbapi2 import *
  File "/home/amauryfa/python/cpython3.x/Lib/sqlite3/dbapi2.py", line 83, in <module>
    register_adapters_and_converters()
  File "/home/amauryfa/python/cpython3.x/Lib/sqlite3/dbapi2.py", line 80, in register_adapters_and_converters
    register_converter("date", convert_date)
NameError: global name 'register_converter' is not defined

----------
messages: 166163
nosy: amaury.forgeotdarc, brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Another strange Tracebacks with importlib
type: behavior

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

From report at bugs.python.org  Sun Jul 22 22:07:52 2012
From: report at bugs.python.org (Shocked Pancake)
Date: Sun, 22 Jul 2012 20:07:52 +0000
Subject: [New-bugs-announce] [issue15426] On a x86_64 Linux workstation,
	the build-from-source is borked.
Message-ID: <1342987672.67.0.931013334684.issue15426@psf.upfronthosting.co.za>


New submission from Shocked Pancake <shockedpancake at gmail.com>:

On a x86_64 Linux workstation, when building from source with ./configure  --prefix=/usr --libdir=/usr/lib64 --enable-ipv6 --with-threads --enable-shared --doc-dir=/usr/doc/python --mandir=/usr/man, almost all library get installed in /usr/lib and not /usr/lib64. And when the python interpreter get launched, it complain about not finding platform dependent libraries and that I should set $PYTHONHOME.
When I apply the patch that I joined with this, it all works well.

----------
components: Build
files: python3.x86_64.diff
keywords: patch
messages: 166164
nosy: Shocked.Pancake
priority: normal
severity: normal
status: open
title: On a x86_64 Linux workstation, the build-from-source is borked.
versions: Python 3.2
Added file: http://bugs.python.org/file26482/python3.x86_64.diff

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

From report at bugs.python.org  Mon Jul 23 00:12:34 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 22:12:34 +0000
Subject: [New-bugs-announce] [issue15427] Describe use of args parameter
	of	argparse.ArgumentParser.parse_args
Message-ID: <1342995154.12.0.902919829048.issue15427@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

>From http://bugs.python.org/issue14191#msg155202:

ArgumentParser.parse_args(args=None, namespace=None)
...
However, nowhere is the args= parameter explained.  One example is given at the end of 15.4.4.6 showing the use of args= which apparently accepts a list of parameters, similar to the positional list of parameters that are used in all the other examples.  It might be nice to clarify that.

----------
assignee: docs at python
components: Documentation
messages: 166174
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: Describe use of args parameter of argparse.ArgumentParser.parse_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/issue15427>
_______________________________________

From report at bugs.python.org  Mon Jul 23 02:00:32 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 00:00:32 +0000
Subject: [New-bugs-announce] [issue15428] add "Name Collision" section to
	argparse docs
Message-ID: <1343001632.52.0.429837248023.issue15428@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Several bugs (e.g. Issue 15327 and Issue 15271) have been filed suggesting that people aren't really clear on how argparse handles argument name collisions or how they can get it to do what they want.

I think these problems could probably be solved by a "Name Collision" section (or something like that) in the argparse documentation. It would give a few example problems and show how to resolve them. Some things to include:

* What happens when two arguments have the same dest (Issue 15271), with solutions including action='append' or different dest= values combined with identical metavar= values.

* What happens when a parser and a sub-parser share some of the same argument names (Issue 15327), with solutions including specifying different dest= values for the parser and sub-parser

* A brief mention and cross-reference to the "conflict_handler" section.

----------
assignee: docs at python
components: Documentation
messages: 166185
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: add "Name Collision" section to argparse docs
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jul 23 02:19:35 2012
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 23 Jul 2012 00:19:35 +0000
Subject: [New-bugs-announce] [issue15429] types.NoneType missing
Message-ID: <1343002775.55.0.171826100235.issue15429@psf.upfronthosting.co.za>


Changes by Anders Kaseorg <andersk at mit.edu>:


----------
assignee: docs at python
components: Documentation
nosy: andersk, docs at python
priority: normal
severity: normal
status: open
title: types.NoneType missing
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul 23 04:39:30 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 02:39:30 +0000
Subject: [New-bugs-announce] [issue15430] Improve filecmp documentation
Message-ID: <1343011170.68.0.66414126493.issue15430@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

filecmp.rst could see some improvements which are easy and useful too. It was discussed in Issue15250 and a patch is attached.

----------
assignee: orsenthil
components: Documentation
files: Issue15250.patch
keywords: easy, patch
messages: 166200
nosy: cjerdonek, orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: Improve filecmp documentation
type: behavior
Added file: http://bugs.python.org/file26488/Issue15250.patch

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

From report at bugs.python.org  Mon Jul 23 08:21:50 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 23 Jul 2012 06:21:50 +0000
Subject: [New-bugs-announce] [issue15431] Cannot build importlib.h on Windows
Message-ID: <1343024510.61.0.395713620689.issue15431@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

On Windows, the _freeze_importlib tool is not built, so it's not possible to refresh the file Python/importlib.h, which makes development on the importlib very difficult on Windows.

The Makefile contains the rules below, it's probably necessary to implement a similar behavior in a new build project:

Modules/_freeze_importlib: Modules/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN)
	$(LINKCC) $(PY_LDFLAGS) -o $@ Modules/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

Python/importlib.h: $(srcdir)/Lib/importlib/_bootstrap.py Modules/_freeze_importlib.c
	$(MAKE) Modules/_freeze_importlib
	./Modules/_freeze_importlib \
		$(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h

----------
components: Build, Windows
messages: 166209
nosy: amaury.forgeotdarc, brian.curtin
priority: high
severity: normal
status: open
title: Cannot build importlib.h on Windows
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 23 11:29:31 2012
From: report at bugs.python.org (Geir Ove Myhr)
Date: Mon, 23 Jul 2012 09:29:31 +0000
Subject: [New-bugs-announce] [issue15432] gzip.py: mtime argument only since
	python 2.7
Message-ID: <1343035771.6.0.0683574772688.issue15432@psf.upfronthosting.co.za>


New submission from Geir Ove Myhr <gomyhr at gmail.com>:

In the gzip documentation (http://docs.python.org/library/gzip.html) a note should be added that the mtime option was added in Python 2.7. 

The patch which adds the option (http://svn.python.org/view?view=revision&revision=68319) is not included in Python 2.6.5.

----------
assignee: docs at python
components: Documentation
messages: 166214
nosy: docs at python, gomyhr
priority: normal
severity: normal
status: open
title: gzip.py: mtime argument only since python 2.7
versions: Python 2.6

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

From report at bugs.python.org  Mon Jul 23 11:48:38 2012
From: report at bugs.python.org (Reinis Ivanovs)
Date: Mon, 23 Jul 2012 09:48:38 +0000
Subject: [New-bugs-announce] [issue15433] argparse usage line is wrong
Message-ID: <1343036918.13.0.713633576876.issue15433@psf.upfronthosting.co.za>


New submission from Reinis Ivanovs <dabas at untu.ms>:

I set a positional argument and an optional argument that accepts a list:

> parser = argparse.ArgumentParser()
> parser.add_argument('foo')
> parser.add_argument('-bar', nargs='*')

The usage line I get from --help is this:

> $ example.py --help
> usage: example.py [-h] [-bar [BAR [BAR ...]]] foo

Trying to actually follow the usage instructions produces this error:

> $ example.py -bar x y z
> error: too few arguments

Reversing the argument order works however:

> $ example.py z -bar x y

So the usage instructions are clearly wrong.

----------
components: Library (Lib)
messages: 166217
nosy: reinis
priority: normal
severity: normal
status: open
title: argparse usage line is wrong
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 23 12:18:04 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Jul 2012 10:18:04 +0000
Subject: [New-bugs-announce] [issue15434] __import__() problem in 3.3
Message-ID: <1343038684.54.0.966180035561.issue15434@psf.upfronthosting.co.za>


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

Using b127046831e2, I'm experiencing an import problem during the NumPy build.

I've reduced it to this scenario, which works in 3.2 but not in 3.3.
Note that in NumPy's setup.py, the equivalent of /home/stefan/tmp is 
the first entry in sys.path. I'm not sure if this isolated example is 
terribly useful:


$ pwd
/home/stefan/tmp
$ ls distutils/command/
__init__.py  xyz.py
$ cat distutils/command/__init__.py

distutils_all = ['xyz']
__import__('distutils.command',globals(),locals(),distutils_all)

$ cat distutils/command/xyz.py
$
$ python3.2 distutils/command/__init__.py
$
$ /home/stefan/usr/bin/python3.3 distutils/command/__init__.py
Traceback (most recent call last):
  File "distutils/command/__init__.py", line 3, in <module>
    __import__('distutils.command',globals(),locals(),distutils_all)
ImportError: No module named 'distutils.command.xyz'
$

----------
components: Interpreter Core
messages: 166218
nosy: brett.cannon, pitrou, skrah
priority: high
severity: normal
status: open
title: __import__() problem in 3.3
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 23 18:26:53 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Mon, 23 Jul 2012 16:26:53 +0000
Subject: [New-bugs-announce] [issue15435] Strange behavior when
	AttributeError raise inside a	property get function
Message-ID: <1343060813.45.0.564529215103.issue15435@psf.upfronthosting.co.za>


New submission from C?dric Krier <cedric.krier at b2ck.com>:

When a AttributeError is raised inside the get function of a property and if the class has a __getattr__ method defined then this method is called.
It is strange behavior because when looking at the traceback it looks like Python doesn't find the property.

----------
components: Interpreter Core
files: test.py
messages: 166234
nosy: ced
priority: normal
severity: normal
status: open
title: Strange behavior when AttributeError raise inside a property get function
type: behavior
Added file: http://bugs.python.org/file26489/test.py

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

From report at bugs.python.org  Mon Jul 23 21:54:42 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Jul 2012 19:54:42 +0000
Subject: [New-bugs-announce] [issue15436] __sizeof__ is not documeneted
Message-ID: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

__sizeof__ is not mentioned on page Doc/reference/datamodel.rst together with other special methods. There is no __sizeof__ in index.

----------
assignee: docs at python
components: Documentation
messages: 166245
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: __sizeof__ is not documeneted
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul 23 22:07:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 20:07:34 +0000
Subject: [New-bugs-announce] [issue15437] Merge Doc/ACKS and Misc/ACKS
Message-ID: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to merge the Doc/ACKS and Misc/ACKS files as discussed here:

http://mail.python.org/pipermail/python-dev/2012-July/121096.html

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166247
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Merge Doc/ACKS and Misc/ACKS

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

From report at bugs.python.org  Tue Jul 24 12:57:50 2012
From: report at bugs.python.org (andrea bergamini)
Date: Tue, 24 Jul 2012 10:57:50 +0000
Subject: [New-bugs-announce] [issue15438] Incredible issue in math.pow
Message-ID: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>


New submission from andrea bergamini <andrea.bergamini.it at gmail.com>:

math.pow(43, 10) gives the wrong result: 21611482313284248.0
Instead, the build-in function 43**10 and pow(43, 10) give the correct result: 21611482313284249L.
This bug has been seen on ActivePython 2.5.1.1. Sorry no tests on recent versions.

----------
components: Library (Lib)
messages: 166275
nosy: andrea.bergamini
priority: normal
severity: normal
status: open
title: Incredible issue in math.pow
type: behavior

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

From report at bugs.python.org  Tue Jul 24 13:51:40 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 11:51:40 +0000
Subject: [New-bugs-announce] [issue15439] Include Misc/ACKS names into the
	documentation
Message-ID: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to include the names in Misc/ACKS into the documentation --
in place of the names from Doc/ACKS.txt.  This was mentioned in the
discussion for issue 15437, which is to add the names from Doc/ACKS.txt
into Misc/ACKS.

This issue should be done shortly after issue 15437.  The current issue
can include (1) converting Misc/ACKS into rst format, (2) deleting
DOC/ACKS.txt (after confirming that any changes since issue 15437 are
reflected in Misc/ACKS), and (3) resolving the intros in the two files
with about.rst's surrounding text so that the text makes sense when
included into the main documentation.

Should Guido's note of acknowledgment in Misc/ACKS be included as is?
And should a new "Python Acknowledgments" section be added to the docs,
or is it okay for this more general acknowledgment to be included in the
section called "About these documents"?  If the former, the "About these
documents" section could link to the more general "Python
Acknowledgments" section to reference documentation contributors.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166279
nosy: cjerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl, jcea, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Include Misc/ACKS names into the documentation

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

From report at bugs.python.org  Tue Jul 24 17:17:52 2012
From: report at bugs.python.org (Bala FA)
Date: Tue, 24 Jul 2012 15:17:52 +0000
Subject: [New-bugs-announce] [issue15440] multiprocess fails to re-raise
	exception which has	mandatory arguments
Message-ID: <1343143072.3.0.822241372547.issue15440@psf.upfronthosting.co.za>


New submission from Bala FA <barumuga at redhat.com>:

I use multiprocess in one of my project.  When an exception which
requires mandatory argument is raised by a server process, is not
re-raised properly to client process.  I get an error something like
below

Traceback (most recent call last):
  File "prod.py", line 69, in <module>
    main()
  File "prod.py", line 61, in main
    print myobj.fun3()
  File "<string>", line 2, in fun3
  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759,
in _callmethod
    kind, result = conn.recv()
TypeError: ('__init__() takes exactly 2 arguments (1 given)', <class
'__main__.MyException2'>, ())

However, if an exception which has optional argument is raised by
server process, is re-raised properly to client process.

Below is a reproducer.

#!/usr/bin/python

import sys
import os
import time
import subprocess
from multiprocessing.managers import BaseManager

class MyManager(BaseManager):
    pass

class MyException1(Exception):
    def __init__(self, msg=''):
        self.msg = msg

    def __str__(self):
        return self.msg

class MyException2(Exception):
    def __init__(self, msg):
        self.msg = msg

    def __str__(self):
        return self.msg

class MyClass(object):
    def fun1(self):
        return 'this is fun1'

    def fun2(self):
        raise MyException1('fun2 raised')

    def fun3(self):
        raise MyException2('fun3 raised')

def runManager():
    manager = MyManager(address=('', 50000), authkey='abc')
    manager.register('instance', callable=MyClass)
    server = manager.get_server()
    print "manager is running"
    server.serve_forever()

def startManager():
    p = subprocess.Popen(['python', __file__, 'manager'])
    time.sleep(1)
    return p

def main():
    p = startManager()
    manager = MyManager(address=('', 50000), authkey='abc')
    manager.register('instance')
    print "connecting to manager"
    manager.connect()
    myobj = manager.instance()
    print myobj.fun1()
    try:
        print myobj.fun2()
    except MyException1, e:
        print e
    try:
        print myobj.fun3()
    except MyException2, e:
        print e
    finally:
        p.kill()

if __name__ == '__main__':
    if len(sys.argv) == 1:
        main()
    else:
        runManager()

I use python 2.7.3 on fedora 17 on x86_64 (rpm version is
python-2.7.3-6.fc17.x86_64)

----------
components: Interpreter Core
messages: 166299
nosy: Bala.FA
priority: normal
severity: normal
status: open
title: multiprocess fails to re-raise exception which has mandatory arguments
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 24 17:24:08 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 24 Jul 2012 15:24:08 +0000
Subject: [New-bugs-announce] [issue15441] test_posixpath fails on Japanese
	edition of Windows
Message-ID: <1343143448.49.0.0362298873842.issue15441@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

test_posixpath.PosixCommonTest.test_nonascii_abspath fails on Japanese edition
of Windows.

If a file name was invalid byte character, os.chdir() raises UnicodeDecodeError()
instead of WindowsError.

This is a byte-api issue on Windows, so we may be able to simply skip this test.

======================================================================
ERROR: test_nonascii_abspath (test.test_posixpath.PosixCommonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\cygwin\home\ishimoto\src\cpython\lib\test\test_genericpath.py", line
318, in test_nonascii_abspath
    with support.temp_cwd(b'\xe7w\xf0'):
  File "C:\cygwin\home\ishimoto\src\cpython\lib\contextlib.py", line 48, in __en
ter__
    return next(self.gen)
  File "C:\cygwin\home\ishimoto\src\cpython\lib\test\support.py", line 614, in t
emp_cwd
    os.chdir(path)
UnicodeDecodeError: 'mbcs' codec can't decode bytes in position 0--1: No mapping
for the Unicode character exists in the target code page.

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

----------
components: Unicode, Windows
files: test_nonascii_abspath.patch
keywords: patch
messages: 166300
nosy: ezio.melotti, ishimoto
priority: normal
severity: normal
status: open
title: test_posixpath fails on Japanese edition of Windows
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26500/test_nonascii_abspath.patch

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

From report at bugs.python.org  Tue Jul 24 18:32:12 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 16:32:12 +0000
Subject: [New-bugs-announce] [issue15442] Expand the list of default dirs
	filecmp.dircmp ignores
Message-ID: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The default ignore list of filecmp.dircmp is ['RCS', 'CVS', 'tags'].

This predates even Subversion! I suggest to freshen up this module to also ignore the dirs for SVN, Mercurial, Git and Bazaar.


[this is a new feature, so no earlier than 3.4...]

----------
components: Library (Lib)
keywords: easy
messages: 166306
nosy: eli.bendersky
priority: low
severity: normal
stage: needs patch
status: open
title: Expand the list of default dirs filecmp.dircmp ignores
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jul 24 21:36:50 2012
From: report at bugs.python.org (Vincenzo Ampolo)
Date: Tue, 24 Jul 2012 19:36:50 +0000
Subject: [New-bugs-announce] [issue15443] datetime module has no support for
	nanoseconds
Message-ID: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>


New submission from Vincenzo Ampolo <vincenzo.ampolo at gmail.com>:

As long as computers evolve time management becomes more precise and more granular.
Unfortunately the standard datetime module is not able to deal with nanoseconds even if OSes are able to. For example if i do:

print "%.9f" % time.time()
1343158163.471209049

I've actual timestamp from the epoch with nanosecond granularity.

Thus support for nanoseconds in datetime would really be appreciated

----------
components: ctypes
messages: 166326
nosy: Vincenzo.Ampolo
priority: normal
severity: normal
status: open
title: datetime module has no support for nanoseconds
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 24 22:25:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 20:25:12 +0000
Subject: [New-bugs-announce] [issue15444] Incorrectly writen contributor's
	names
Message-ID: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Some contributor's names written incorrectly (in ASCII) in documentation:

Jes?s Cea Avi?n as Jes?s Cea Avion
Lars Gust?bel as Lars Gustaebel
Gerhard H?ring as Gerhard Haering
Marc-Andr? Lemburg as Marc-Andre Lemburg
Martin von L?wis as Martin von Loewis
Charles-Fran?ois Natali as Charles-Francois Natali
?iga Seilnach as Ziga Seilnacht

The proposed patch restores natural spelling (based on Doc/ACKS and Misc/ACKS).

I'm not sure about how to write right: ?iga Seilnach or Seilnacht?

----------
assignee: docs at python
components: Documentation
files: doc-nonascii-names.patch
keywords: patch
messages: 166330
nosy: docs at python, ghaering, jcea, lars.gustaebel, lemburg, loewis, neologix, storchaka, zseil
priority: normal
severity: normal
status: open
title: Incorrectly writen contributor's names
Added file: http://bugs.python.org/file26504/doc-nonascii-names.patch

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

From report at bugs.python.org  Wed Jul 25 02:14:26 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 25 Jul 2012 00:14:26 +0000
Subject: [New-bugs-announce] [issue15445] Ability to do code injection via
	logging module	configuration listener port.
Message-ID: <1343175266.51.0.990414840949.issue15445@psf.upfronthosting.co.za>


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

This issue was raised first on security at python.org. Guido responded that not sensitive enough to be kept to the list and that okay to log a bug report.

This issue may not warrant any action except perhaps an update to
documentation for the logging module to warn about it, but thought
that should raise it just in case someone felt it needed actual code
changes to be made to avoid the issue if possible.

The problem arises in the Python logging modules ability to create a
listener socket which can accept new configuration in the ini file
format.

http://docs.python.org/library/logging.config.html#logging.config.listen

"""To send a configuration to the socket, read in the configuration
file and send it to the socket as a string of bytes preceded by a
four-byte length string packed in binary using struct.pack('>L',
n)."""

This sounds innocuous and the documentation at that point doesn't warn
that you are opening yourself up to security problems in using it.

You get a hint of potential issues later if one reads later
documentation about the file format:

"""The class entry indicates the handler?s class (as determined by
eval() in the logging package?s namespace). The level is interpreted
as for loggers, and NOTSET is taken to mean ?log everything?."""

There are other mentions about eval() in context of log level and args
for the handler class as well, but not sure that is used for log level
as it says.

The combination of the open listener port for configuration and that
processing of the configuration file uses eval(), means that one could
send a configuration file to the process containing:

[handler_consoleHandler]
class=os.system('echo security issue') or StreamHandler
level=DEBUG
formatter=simpleFormatter
args=(sys.stdout,)

and one could execute an arbitrary command as the user the process runs as.

The problem is tempered by the fact that someone has to enable the
feature, which is likely rare, but also because socket connections to
send new configuration will only be accepted from the same host
('localhost') and the host can not be overridden. So can only be taken
advantage of by someone (potentially a different user) on the same
host and not remotely at least.

The specific code in Python 3.2 is:

        section = cp["handler_%s" % hand]
        klass = section["class"]
        fmt = section.get("formatter", "")
        try:
            klass = eval(klass, vars(logging))
        except (AttributeError, NameError):
            klass = _resolve(klass)
        args = section["args"]
        args = eval(args, vars(logging))
        h = klass(*args)

and older Python 2.X versions have similar code.

Although you could perhaps avoid need for eval for class lookup, can't
see that you could do that for args unless you restrict it to literal
values and use a more limited eval like parser.

At the minimum there probably should be a warning in the documentation about using the logging module configuration port on untrusted systems with shared users.

----------
components: Library (Lib)
messages: 166343
nosy: grahamd
priority: normal
severity: normal
status: open
title: Ability to do code injection via logging module configuration listener port.
type: security
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 25 11:51:56 2012
From: report at bugs.python.org (Arseniy)
Date: Wed, 25 Jul 2012 09:51:56 +0000
Subject: [New-bugs-announce] [issue15446] Recursion SIGSEGV
Message-ID: <1343209916.8.0.539933820287.issue15446@psf.upfronthosting.co.za>


New submission from Arseniy <senyai at gmail.com>:

a=lambda:a
print eval("a" + "()" * 999999)

----------
components: None
messages: 166378
nosy: senyai
priority: normal
severity: normal
status: open
title: Recursion SIGSEGV
type: crash
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Jul 25 15:15:13 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Wed, 25 Jul 2012 13:15:13 +0000
Subject: [New-bugs-announce] [issue15447] A file is not properly closed by
	webbrowser._invoke
Message-ID: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za>


New submission from Anton Barkovsky <swarmer.pm at gmail.com>:

webbrowser._invoke opens /dev/null, never closes it and a warning is
printed.

I'm attaching a patch.
The diff looks messy, but I'm just wrapping the code in a try-finally
block, the rest is just indented.

----------
components: Library (Lib)
files: fileclose.patch
keywords: patch
messages: 166392
nosy: anton.barkovsky
priority: normal
severity: normal
status: open
title: A file is not properly closed by webbrowser._invoke
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26511/fileclose.patch

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

From report at bugs.python.org  Wed Jul 25 18:50:07 2012
From: report at bugs.python.org (Richard Moseley)
Date: Wed, 25 Jul 2012 16:50:07 +0000
Subject: [New-bugs-announce] [issue15448] utimes() functions fail with
	ENOSYS even when detected	by configure
Message-ID: <1343235007.8.0.870502159269.issue15448@psf.upfronthosting.co.za>


New submission from Richard Moseley <dickie.moseley at virgin.net>:

When building on a ASUS Eee PC 1000 running the original Xandros O/S with libc-2.7-13, the various utimes() functions are being detected as available for use, everything compiles. However, during installation of the lib-dynload libraries, the error 'Error: Function not implemented' is given and the installation halts.

This problem has been tracked down to the fact that some of the utimes() functions will return ENOSYS rather than the expected result.

I have now patched the configure.ac script to check for the seven variants of the function, which is attached. This patch would ideally have made use of the same model as the AC_CHCEK_FUNCS macro but this would require adding a new file to the source tree.

----------
components: Build
files: configure.ac.diff
keywords: patch
messages: 166413
nosy: richmose
priority: normal
severity: normal
status: open
title: utimes() functions fail with ENOSYS even when detected by configure
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file26514/configure.ac.diff

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

From report at bugs.python.org  Wed Jul 25 22:15:48 2012
From: report at bugs.python.org (Sworddragon)
Date: Wed, 25 Jul 2012 20:15:48 +0000
Subject: [New-bugs-announce] [issue15449] Optional size argument for
	readline()
Message-ID: <1343247348.26.0.437825831921.issue15449@psf.upfronthosting.co.za>


New submission from Sworddragon <sworddragon2 at aol.com>:

For file objects the read() function has the optional size argument to limit the data that will be read. I'm wondering why there isn't such an argument for readline(). Theoretically lines in a file could have million of characters and even much more. An optional limit could prevent that a high amount of data will be load into the memory.

----------
components: Library (Lib)
messages: 166422
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Optional size argument for readline()
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 26 02:00:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 00:00:03 +0000
Subject: [New-bugs-announce] [issue15450] Allow dircmp.subdirs to behave
	well under subclassing
Message-ID: <1343260803.75.0.101432828571.issue15450@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Currently, the subdirs attribute of filecmp.dircmp does not respect subclassing:

>>> from filecmp import dircmp
>>> class MyDirCmp(dircmp):
...   pass
... 
>>> my_dcmp = MyDirCmp('dir1', 'dir2')
>>> for item in my_dcmp.subdirs.values():
...   print(type(item))
...   break
... 
<class 'filecmp.dircmp'>

This is the only place where dircmp does not respect subclassing.  It can be corrected here:

def phase4(self): # Find out differences between common subdirectories
    ...
        ...
        self.subdirs[x]  = dircmp(a_x, b_x, self.ignore, self.hide)

This would let one do things like override dircmp.report() and have dircmp.report_full_closure() behave as expected.

----------
components: Library (Lib)
keywords: easy
messages: 166443
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Allow dircmp.subdirs to behave well under subclassing
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 26 02:57:10 2012
From: report at bugs.python.org (Grissiom Gu)
Date: Thu, 26 Jul 2012 00:57:10 +0000
Subject: [New-bugs-announce] [issue15451] PATH is not honored in
	subprocess.Popen in win32
Message-ID: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>


New submission from Grissiom Gu <chaos.proton at gmail.com>:

My system is 32 bit win7 and python is 2.7.2.

Sample code is here:
=======================
import os, sys

nenv = {}
nenv['PATH'] = 'C:\\Windows\\System32\\;e:\\projects\\teest\\python\\exe\\'
nenv['SystemRoot'] = 'C:\\Windows\\'

#os.putenv('PATH', nenv['PATH'])
import subprocess
proc = subprocess.Popen('test.bat', stdin=subprocess.PIPE, stdout=subprocess.PIPE,
    stderr=subprocess.PIPE, shell = False, env=nenv)
data, err = proc.communicate()
rv = proc.wait()

if data:
    print data
if err:
    print err
sys.exit(rv)
==========================
in E:\projects\teest\python I have two folders: 'exe/' have a bat file named 'test.bat' and a 'launch/' folder have the above script. When execute the above script, python yield "WindowsError: [Error 2]" which means could not find the executable.

However, if I un-comment the line "#os.putenv('PATH', nenv['PATH'])", it works like a charm. It seems _subprocess.CreateProcess does not honer the PATH.

FYI, if I use the CreateProcess of win32 extensions, thing works fine without the need to export PATH.

----------
messages: 166447
nosy: Grissiom.Gu
priority: normal
severity: normal
status: open
title: PATH is not honored in subprocess.Popen in win32
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 26 03:01:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 01:01:35 +0000
Subject: [New-bugs-announce] [issue15452] Eliminate the use of eval() in the
	logging config	implementation
Message-ID: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>


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

The current implementation of PEP 391 relies on eval, which is substantially more permissive than the expected syntax described in the spec. This means the listen() feature provides an attack vector for injection of untrusted code.

While the documentation has been updated with a cautionary note to this effect, longer term, the use of eval() should be replaced with:

1. ast.literal_eval()
2. refactoring the str.format attribute and item lookup code into something suitable for reuse in other contexts (perhaps exposed via the ast module as "ast.lookup_eval()")

----------
components: Library (Lib)
messages: 166448
nosy: ncoghlan, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate the use of eval() in the logging config implementation
type: security
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 26 09:24:57 2012
From: report at bugs.python.org (Mike Castle)
Date: Thu, 26 Jul 2012 07:24:57 +0000
Subject: [New-bugs-announce] [issue15453] ctype with packed bitfields does
	not match native	compiler
Message-ID: <1343287497.79.0.127552089432.issue15453@psf.upfronthosting.co.za>


New submission from Mike Castle <dalgoda at gmail.com>:

On debian/testing with python 2.7.3rc2 and gcc 4.7.1.

I was trying to use ctypeslib to wrap libdvdnav and running into some issues porting my test C code to Python, eventually tracking it down to this difference between how ctypes and gcc handles bitfields in packed structs (i.e., affects real world problems).

Basically, by default, gcc treats 8, 16 and 32 bit types in bit fields as 1 byte when using __attribute__ ((packed)) , while ctypes treats them each as 1, 2 and 4 bytes even when using _pack_ = 1.  (and libdvdnav using packed a lot)

Output from the attached programs:

$ ./a.out
1
1
1
$ ./t.py
1
2
4

Removing the packed attribute or building with gcc -mms-bitfields both match the ctypes expectations (though -mms-bitfields is probably rarely used in Linux).

----------
components: ctypes
files: t.py
messages: 166462
nosy: Mike.Castle
priority: normal
severity: normal
status: open
title: ctype with packed bitfields does not match native compiler
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file26521/t.py

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

From report at bugs.python.org  Thu Jul 26 09:48:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 07:48:52 +0000
Subject: [New-bugs-announce] [issue15454] Allow dircmp.report() output
	stream to be customized
Message-ID: <1343288932.25.0.229744443043.issue15454@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Currently, filecmp.dircmp's report(), report_partial_closure(), and report_full_closure() methods all only allow printing to stdout.

This issue is to provide some way for the caller to control the stream to which these methods print their output (e.g. a 'stream' argument on the three methods).

This suggestion was made by Eli in the discussion for issue 15269.

----------
components: Library (Lib)
keywords: easy
messages: 166464
nosy: cjerdonek, eli.bendersky
priority: normal
severity: normal
status: open
title: Allow dircmp.report() output stream to be customized
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 26 10:55:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 08:55:36 +0000
Subject: [New-bugs-announce] [issue15455] index entries not showing up in
	glossary
Message-ID: <1343292936.36.0.839564467916.issue15455@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I haven't tracked down the reason for this, but certain index entries seem to be getting skipped in the Glossary.  If you view source on the Glossary page and search for "index-":

http://docs.python.org/dev/glossary.html

You will find that it skips from 'index-2' to 'index-5'.  Only :pep: index entries are getting included even though the Glossary's rst file contains explicit index directives (where 'index-3' and 'index-4' would otherwise be).

I tried some experiments, and this seems to occur even if the index directive text does not match the name of the Glossary term.

----------
assignee: docs at python
components: Documentation
messages: 166467
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: index entries not showing up in glossary
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 26 12:29:15 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jul 2012 10:29:15 +0000
Subject: [New-bugs-announce] [issue15456] Correct __sizeof__ support for
	code objects
Message-ID: <1343298555.0.0.339886098812.issue15456@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements __sizeof__ for code objects (PyCodeObject) counting co_cell2arg array.

----------
components: Interpreter Core
files: code_sizeof.patch
keywords: patch
messages: 166469
nosy: storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for code objects
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26523/code_sizeof.patch

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

From report at bugs.python.org  Thu Jul 26 13:37:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 11:37:56 +0000
Subject: [New-bugs-announce] [issue15457] consistent treatment of generator
	terminology
Message-ID: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation on generators (outside of PEP 255) does not currently educate the reader on the more specific  "generator function" and "generator iterator" terminology, or at least not in any consistent or systematic way.

For example, the glossary includes only a single entry for "generator," and that entry does not mention the two more specific forms.

I think it would help for general discourse purposes if this distinction were made clearer, while still continuing to allow for the use of the generic word "generator" when the context makes it clear.

There are also cases where index entries can be improved in this regard, and where references to the section containing details about generators can still be added.  I am in the process of completing a proposed patch.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166474
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: consistent treatment of generator terminology
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 26 17:42:55 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 26 Jul 2012 15:42:55 +0000
Subject: [New-bugs-announce] [issue15458] Add python-config --configdir
	option
Message-ID: <1343317375.87.0.261249641765.issue15458@psf.upfronthosting.co.za>


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

To assist with vendor builds, Matthias has requested added a --configdir option to the python3-config script.  This would return sysconfig.get_config_var('LIBPL').  The value is embedded in the output for --ldflags, but not in a convenient way.

The change is fairly trivial; see attached patch.  I am assigning this to Georg and making it a release blocker because I would like to get a freeze exemption for Python 3.3.  If Georg agrees, I will commit the patch.  If not, please twiddle Priority, Versions, and Assigned To as appropriate.

----------
assignee: georg.brandl
files: configdir.diff
keywords: patch
messages: 166491
nosy: barry, georg.brandl
priority: release blocker
severity: normal
status: open
title: Add python-config --configdir option
versions: Python 3.3
Added file: http://bugs.python.org/file26528/configdir.diff

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

From report at bugs.python.org  Thu Jul 26 20:35:05 2012
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 26 Jul 2012 18:35:05 +0000
Subject: [New-bugs-announce] [issue15459] ctypes Structures with subclassed
	types in the _fields_	list
Message-ID: <1343327705.62.0.223741820518.issue15459@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

When a ctypes Structure uses a subclass of c_int, c_short, c_byte in the _fields_ list to define bitfields, the results are wrong.

The attached script showbug.py demonstrates this behaviour.

----------
components: ctypes
files: showbug.py
keywords: needs review, patch
messages: 166496
nosy: theller
priority: normal
severity: normal
status: open
title: ctypes Structures with subclassed types in the _fields_ list
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26529/showbug.py

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

From report at bugs.python.org  Thu Jul 26 20:39:01 2012
From: report at bugs.python.org (Charlie Clark)
Date: Thu, 26 Jul 2012 18:39:01 +0000
Subject: [New-bugs-announce] [issue15460] SQLite cursor.description is not
	DB-API compatible
Message-ID: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>


New submission from Charlie Clark <charlie.clark at clark-consulting.eu>:

It says in the docs:
"""This read-only attribute provides the column names of the last query. To remain compatible with the Python DB API, it returns a 7-tuple for each column where the last six items of each tuple are None."""

According to the DB-API, however, the first two items, name and type, must be specified:
"""
The first two items (name and type_code) are mandatory, the other five are optional and are set to None if no meaningful values can be provided.
"""

Even with it's limited number of types SQLite is typed and should be able to return the type for column.

----------
components: Library (Lib)
messages: 166498
nosy: CharlieX
priority: normal
severity: normal
status: open
title: SQLite cursor.description is not DB-API compatible
type: behavior

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

From report at bugs.python.org  Thu Jul 26 23:03:21 2012
From: report at bugs.python.org (coder.maliubiao)
Date: Thu, 26 Jul 2012 21:03:21 +0000
Subject: [New-bugs-announce] [issue15461] os.stat() 's inappropriate
	behavior when dealing with a	broken link in linux systems.
Message-ID: <1343336601.05.0.224760800644.issue15461@psf.upfronthosting.co.za>


New submission from coder.maliubiao <maliubiao at gmail.com>:

the code:
import os,stat
mode=os.stat("a broken link file").st_mode
then i got :OSError: [Errno 2] No such file or directory.

why not just treat a broken link as something existing and don't report any error.

----------
components: Library (Lib)
messages: 166519
nosy: maliubiao at gmail.com
priority: normal
severity: normal
status: open
title: os.stat() 's inappropriate behavior when dealing with a broken link in linux systems.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 26 23:06:21 2012
From: report at bugs.python.org (Aimon Bustardo)
Date: Thu, 26 Jul 2012 21:06:21 +0000
Subject: [New-bugs-announce] [issue15462] UTF8 BOM incorrectly prepended
	syslog messages when	using rsysolog
Message-ID: <1343336781.88.0.897924928117.issue15462@psf.upfronthosting.co.za>


New submission from Aimon Bustardo <abustardo at morphlabs.com>:

Ubuntu 12.0.4 LTS 64bit
python2.7-minimal 2.7.3-0ubuntu3
rsyslog 5.8.6-1ubuntu8

Python converts all syslog messages to UTF8 before sending to syslog. It also prepends the Byte Order Mark (BOM) of the Unicode Standard. This prepended BOM causes bad characters when using rsyslog (have not verified with std syslog or syslog-ng).

Example log line:

Jul 25 13:36:03 mc ???2012-07-25 13:36:03 INFO nova.api.openstack.wsgi [req-48a555a5-6d2a-4a38-8384-3b4684357e72 19f932a5b0b34655989f4cb761522bb3 2617e657fdf84569a6be7977318e46c8] http://MASKED:8774/v1.1/2617e657fdf84569a6be7977318e46c8/os-hosts/MASKED.json?ignore_awful_caching1343248563 returned with HTTP 200

Note the ' ???' before the date field.

Interesting find on issues from another site:

"Yes, "???" is the Byte Order Mark (BOM) of the Unicode Standard. Specifically it is the hex bytes EF BB BF, which form the UTF-8 representation of the BOM, misinterpreted as ISO 8859/1 text instead of UTF-8."

If I patch the code in /usr/lib/python2.7/logging/handlers.py:
------------------------------------------
@@ -797,9 +797,10 @@
                                             self.mapPriority(record.levelname))
         # Message is a string. Convert to bytes as required by RFC 5424
         if type(msg) is unicode:
            msg = msg.encode('utf-8')
- if codecs:
- msg = codecs.BOM_UTF8 + msg
+ #if codecs:
+ # msg = codecs.BOM_UTF8 + msg
         msg = prio + msg
         try:
             if self.unixsocket:

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

The logs will now appear normally. What is happening with the 'codecs' condition? Is this controllable through config? Is this a bug in rsyslog? 

Related tickets:

https://bugs.launchpad.net/openstack-common/+bug/1029116
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1029640
http://bugzilla.adiscon.com/show_bug.cgi?id=346

----------
components: IO, Library (Lib), Unicode
messages: 166520
nosy: Aimon.Bustardo, ezio.melotti
priority: normal
severity: normal
status: open
title: UTF8 BOM incorrectly prepended syslog messages when using rsysolog
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 27 03:23:08 2012
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 Jul 2012 01:23:08 +0000
Subject: [New-bugs-announce] [issue15463] test_faulthandler can fail if
	install path is too long
Message-ID: <1343352188.31.0.766597419616.issue15463@psf.upfronthosting.co.za>


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

======================================================================
FAIL: test_dump_traceback_threads (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 365, in test_dump_traceback_threads
    self.check_dump_traceback_threads(None)
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 361, in check_dump_traceback_threads
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n(?:  File ".*threading.py", line [0-9]+ in [_a-z]+\n){1,3}  File "<string>", line 23 in run\n  File ".*threading.py", line [0-9]+ in _bootstrap_inner\n  File ".*threading.py", line [0-9]+ in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 10 in dump\n  File "<string>", line 28 in <module>$' not found in 'Thread 0x0000000103a4a000:\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 184 in wait\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 330 in wait\n  File "<string>", line 23 in run\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 639 in _bootstrap_inner\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 616 in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 10 in dump\n  File "<string>", line 28 in <module>'

======================================================================
FAIL: test_dump_traceback_threads_file (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 369, in test_dump_traceback_threads_file
    self.check_dump_traceback_threads(filename)
  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/3.3/lib/python3.3/test/test_faulthandler.py", line 361, in check_dump_traceback_threads
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n(?:  File ".*threading.py", line [0-9]+ in [_a-z]+\n){1,3}  File "<string>", line 23 in run\n  File ".*threading.py", line [0-9]+ in _bootstrap_inner\n  File ".*threading.py", line [0-9]+ in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 8 in dump\n  File "<string>", line 28 in <module>$' not found in 'Thread 0x0000000105215000:\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 184 in wait\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 330 in wait\n  File "<string>", line 23 in run\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 639 in _bootstrap_inner\n  File "/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Versions/...", line 616 in _bootstrap\n\nCurrent thread XXX:\n  File "<string>", line 8 in dump\n  File "<string>", line 28 in <module>'

----------------------------------------------------------------------
Ran 27 tests in 20.582s

FAILED (failures=2)
test test_faulthandler failed

The two failing tests call check_dump_traceback_threads which has a regex to find threading.py in the traceback but the path is truncated in the traceback so "threading.py" doesn't appear.

----------
components: Tests
messages: 166531
nosy: haypo, ned.deily
priority: low
severity: normal
status: open
title: test_faulthandler can fail if install path is too long
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 27 03:34:16 2012
From: report at bugs.python.org (=?utf-8?q?Thi=C3=A9baud_Weksteen?=)
Date: Fri, 27 Jul 2012 01:34:16 +0000
Subject: [New-bugs-announce] [issue15464] ssl: add set_msg_callback function
Message-ID: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>


New submission from Thi?baud Weksteen <thiebaud at weksteen.fr>:

I wrote a patch for Python 3 to expose the function
SSL_CTX_set_msg_callback in the module ssl.

Here is a description of this function:
"SSL_CTX_set_msg_callback() or SSL_set_msg_callback() can be used
to define a message callback function cb for observing all SSL/TLS
protocol messages (such as handshake messages) that are received or sent."

There is also a test case included in the patch.

Comments are welcomed.

----------
components: Extension Modules
files: ssl_msg_callback.patch
keywords: patch
messages: 166532
nosy: tweksteen
priority: normal
severity: normal
status: open
title: ssl: add set_msg_callback function
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26534/ssl_msg_callback.patch

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

From report at bugs.python.org  Fri Jul 27 09:05:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Jul 2012 07:05:25 +0000
Subject: [New-bugs-announce] [issue15465] Improved documentation for C API
	version info
Message-ID: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>


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

As far as I can tell, the only mentions of the C API version macros are:

1. In the prose for the stable ABI section (incidentally: this section has a typo in the title)

2. In the documentation for sys.hexversion

There should be a clear "API and ABI Versioning" section in the C API docs that covers:

PY_LIMITED_API
PY_HEX_VERSION
PY_MAJOR_VERSION
PY_MINOR_VERSION
PY_MICRO_VERSION
PY_RELEASE_LEVEL
PY_RELEASE_SERIAL

----------
assignee: docs at python
components: Documentation
messages: 166546
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Improved documentation for C API version info
type: enhancement

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

From report at bugs.python.org  Fri Jul 27 14:50:59 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 Jul 2012 12:50:59 +0000
Subject: [New-bugs-announce] [issue15466] Python/importlib.h is different on
	32bit and 64bit
Message-ID: <1343393459.17.0.272006722766.issue15466@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

As shown in a patch in issue15431, frozen.c does not output the same data on different platforms.

The first difference looks like this (extracted from the patch):
-    101,73,255,255,255,255,0,0,0,0,40,10,0,0,0,117,
+    101,108,3,0,0,0,255,127,255,127,3,0,40,10,0,0,

On first row, 'I' followed by 0xFFFFFFFF on 8 bytes.
On second row, 'l' followed by 3 followed by 0xFFFFFFFF (in 3 chunks of 15 bits).
The Python number 0xFFFFFFFF is marshalled with TYPE_INT64 when SIZEOF_LONG>4 (Unix 64bit), and with TYPE_LONG on other platforms (32bit, or win64)

The C "long" type has much less importance in 3.x Python, because PyIntObject does not exist anymore.
I suggest to remove this distinction, and allow TYPE_INT64 on all platforms.

I don't see any compatibility issue, on unmarshalling both methods produce the same object.
I'll try to suggest a patch later today.

----------
messages: 166559
nosy: amaury.forgeotdarc, pitrou
priority: high
severity: normal
status: open
title: Python/importlib.h is different on 32bit and 64bit

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

From report at bugs.python.org  Fri Jul 27 17:33:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:33:45 +0000
Subject: [New-bugs-announce] [issue15467] Updating __sizeof__ tests
Message-ID: <1343403225.85.0.0534140376443.issue15467@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

The proposed patches move to test.support some functions, which will be useful for testing __sizeof__. The next few patches will use it. Also in 3.3 some bugs have fixed, now "n" is used for Py_ssize_t and Py_hash_t (which is not long now).

----------
components: Tests
files: sizeof_tests-3.3.patch
keywords: patch
messages: 166574
nosy: loewis, storchaka
priority: normal
severity: normal
status: open
title: Updating __sizeof__ tests
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26541/sizeof_tests-3.3.patch

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

From report at bugs.python.org  Fri Jul 27 17:46:47 2012
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 Jul 2012 15:46:47 +0000
Subject: [New-bugs-announce] [issue15468] Edit docs to hide hashlib.md5()
Message-ID: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za>


New submission from Daniel Holth <dholth at fastmail.fm>:

md5() has been obsolete since 1996. It has no place as the first item in hashlib's list of "guaranteed to be available" hashes, and it doesn't work when Python has been compiled to be FIPS-compliant.

The documentation should be edited to make md5's availability as non-obvious as possible.

----------
messages: 166577
nosy: dholth
priority: normal
severity: normal
status: open
title: Edit docs to hide hashlib.md5()
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 27 17:47:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 15:47:58 +0000
Subject: [New-bugs-announce] [issue15469] Correct __sizeof__ support for
	deque
Message-ID: <1343404078.66.0.00721941905437.issue15469@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements correct __sizeof__ for collections.deque.

Test depends on issue15467.

----------
components: Library (Lib)
files: deque_sizeof.patch
keywords: patch
messages: 166578
nosy: storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for deque
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26544/deque_sizeof.patch

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

From report at bugs.python.org  Fri Jul 27 18:01:10 2012
From: report at bugs.python.org (Seamus McKenna)
Date: Fri, 27 Jul 2012 16:01:10 +0000
Subject: [New-bugs-announce] [issue15470] Stuck/hang when reading ssl object
Message-ID: <1343404870.87.0.816938002683.issue15470@psf.upfronthosting.co.za>


New submission from Seamus McKenna <seamus.mckenna at intunenetworks.com>:

My python scripting has been running for several weeks periodically sending out emails.  However the script has been stuck for the last 24 hrs.  No parts of my script have been executed in this period.

On terminating the script via ctrl-c, I can see that the script is stuck with the python ssl library. See below;

-----------------------------------------------------------------
File "/export2/home/intregress/LabEnv210/lab/int_lib/int_tools/PTM_COMMON/user.py", line 4277, in email
    mailServer.sendmail(gmail_user, to, msg.as_string())
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 713, in sendmail
    (code,resp) = self.data(msg)
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 482, in data
    (code,msg)=self.getreply()
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 338, in getreply
    line = self.file.readline()
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/smtplib.py", line 177, in readline
    chr = self.sslobj.read(1)
  File "/tools/ACTIVESTATE/python/2.7.1.3/x86/lib/python2.7/ssl.py", line 138, in read
    return self._sslobj.read(len)
-------------------------------------------------------------------

----------
components: None
messages: 166579
nosy: seamus.mckenna
priority: normal
severity: normal
status: open
title: Stuck/hang when reading ssl object
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 27 19:09:37 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 Jul 2012 17:09:37 +0000
Subject: [New-bugs-announce] [issue15471] importlib's __import__() argument
	style nit
Message-ID: <1343408977.86.0.620892563203.issue15471@psf.upfronthosting.co.za>


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

Very minor style nit.  In general, it's not considered good style to use mutable objects in default argument values.  importlib's _bootstrap.__import__() does just this for its globals, locals, and fromlist arguments.

The implementation currently doesn't abuse this, or allow any of the extensions to abuse, it may be possible in the future to naively cause negative side-effects due to mutate the keyword arguments.  It would be better to use non-mutable default values in the argument list.

----------
assignee: brett.cannon
components: Library (Lib)
keywords: easy
messages: 166585
nosy: barry, brett.cannon
priority: low
severity: normal
status: open
title: importlib's __import__() argument style nit
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 27 20:23:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 18:23:54 +0000
Subject: [New-bugs-announce] [issue15472] Itertools doc summary table
	misdocuments some arguments
Message-ID: <1343413434.71.0.36910737273.issue15472@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In the tables near the top of http://docs.python.org/library/itertools , some functions like cycle have an example that uses ?seq?, which is interpreted as ?sequence? but the functions do work with any iterable.

----------
assignee: docs at python
components: Documentation
messages: 166594
nosy: docs at python, eric.araujo, rhettinger
priority: normal
severity: normal
status: open
title: Itertools doc summary table misdocuments some arguments
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 27 20:36:57 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 Jul 2012 18:36:57 +0000
Subject: [New-bugs-announce] [issue15473] importlib no longer uses
	imp.NullImporter
Message-ID: <1343414217.14.0.255366402583.issue15473@psf.upfronthosting.co.za>


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

I think this is mostly just out of date documentation, but I want to get Brett's feedback.  The sys module has this to say about sys.path_importer_cache:

"A dictionary acting as a cache for finder objects. The keys are paths that have been passed to sys.path_hooks and the values are the finders that are found. If a path is a valid file system path but no explicit finder is found on sys.path_hooks then None is stored to represent the implicit default finder should be used. If the path is not an existing path then imp.NullImporter is set."

Notice that last sentence.  AFAICT, this is not true in importlib.  I can find no relevant reference to imp.NullImporter in _bootstrap.py.  Maybe we should just remove this from the documentation?  OTOH, there are a few tests that check semantics related to imp.NullImporter found in sys.path_importer_cache, so clearly there are API constraints.  See also runpy.py, which gives some semantics to finding this importer in the cache.

Any suggestions for better wording about imp.NullImporter and sys.path_importer_cache?  I'd like to add this to my rewritten import machinery docs, but I'm not exactly sure what to say about it.

----------
assignee: brett.cannon
components: Documentation
messages: 166595
nosy: barry, brett.cannon, eric.smith, ncoghlan
priority: normal
severity: normal
status: open
title: importlib no longer uses imp.NullImporter
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 27 21:10:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 19:10:07 +0000
Subject: [New-bugs-announce] [issue15474] Differentiate decorator and
	decorator factory in docs
Message-ID: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Some of the confusion encountered when writing decorators arise from the difference between a decorator (@something) and a decorator factory (@something(args)).  It would help to adopt this clearer terminology in our docs: a decorator takes the decorated function as argument and does its business, a decorator factory takes some arguments and returns a decorator which wraps the decorated function.

(I think it was Nick who suggested this in a recent-ish mailing list thread.)

----------
assignee: docs at python
components: Documentation
messages: 166600
nosy: docs at python, eric.araujo, ncoghlan
priority: normal
severity: normal
status: open
title: Differentiate decorator and decorator factory in docs
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 27 21:44:02 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Jul 2012 19:44:02 +0000
Subject: [New-bugs-announce] [issue15475] Correct __sizeof__ support for
	itertools
Message-ID: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is a patch that implements correct __sizeof__ for some itertools iterators: product(), combinations(), combinations_with_replacement() and permutations().

----------
components: Library (Lib)
files: itertools_sizeof-3.3.patch
keywords: patch
messages: 166603
nosy: rhettinger, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for itertools
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26547/itertools_sizeof-3.3.patch

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

From report at bugs.python.org  Sat Jul 28 09:11:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 07:11:11 +0000
Subject: [New-bugs-announce] [issue15476] Add "code object" to glossary
Message-ID: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to add "code object" to the documentation glossary, as discussed in issue 15457 regarding the documentation around generators.

This can be a minimal entry that links to the details here, for example--

http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
specifically: http://docs.python.org/dev/reference/datamodel.html#index-52

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166633
nosy: cjerdonek, docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "code object" to glossary
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 28 12:03:57 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Jul 2012 10:03:57 +0000
Subject: [New-bugs-announce] [issue15477] test_cmath failures on OS X 10.8
Message-ID: <1343469837.83.0.840988569572.issue15477@psf.upfronthosting.co.za>


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

======================================================================
FAIL: testAtanSign (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 526, in testAtanSign
    self.assertComplexIdentical(cmath.atan(z), z)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 96, in assertComplexIdentical
    self.assertFloatIdentical(x.imag, y.imag)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 86, in assertFloatIdentical
    self.fail(msg.format(x, y))
AssertionError: floats -0.0 and 0.0 are not identical: zeros have different signs

======================================================================
FAIL: testAtanhSign (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 533, in testAtanhSign
    self.assertComplexIdentical(cmath.atanh(z), z)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 95, in assertComplexIdentical
    self.assertFloatIdentical(x.real, y.real)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 86, in assertFloatIdentical
    self.fail(msg.format(x, y))
AssertionError: floats 0.0 and -0.0 are not identical: zeros have different signs

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 382, in test_specific_values
    msg=error_message)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 128, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: atan1000: atan(complex(-0.0, 0.0))
Expected: complex(-0.0, 0.0)
Received: complex(-0.0, -0.0)
Received value insufficiently close to expected value.

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

Failures seen across various compilers and deployment targets and running the tests with the same binaries on earlier OS X versions do not fail.

FWIW, the Apple-supplied Python 2.7.2 in 10.8 (that's the most recent version supplied) also has a test_cmath failure:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py", line 352, in test_specific_values
    msg=error_message)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py", line 94, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: atan0000: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.

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

Is there any reason to not consider this a platform bug?  If it is, what should the bug report be?

----------
messages: 166642
nosy: mark.dickinson, ned.deily
priority: normal
severity: normal
status: open
title: test_cmath failures on OS X 10.8
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 28 14:49:05 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Jul 2012 12:49:05 +0000
Subject: [New-bugs-announce] [issue15478] UnicodeDecodeError on OSError
Message-ID: <1343479745.83.0.410557070565.issue15478@psf.upfronthosting.co.za>


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

On Windows, if an OS error fails, the filename type is bytes and the filename cannot be decoded: Python raises an UnicodeDecodeError instead of an OSError. The problem is that Python decodes the filename to fill OSError.filename field. See the issue #15441 for the initial report.

There are different options to solve this issue:
 - always keep the filename parameter unchanged, so OSError.filename can be a str or a bytes string, depending on the input parameter
 - try to decode the filename from the filesystem encoding, or keep the filename unchanged: OSError.filename is only a bytes string if the filename cannot be decoded
 - don't fill OSError.filename (= None) if the filename cannot be decoded
 - use "surrogateescape", "replace" or "backslashreplace" error handler to decode the filename

This issue is specific to Windows: on other plaforms, the filename is decoded using the "surrogateescape" error handler and so decoding the filename cannot fail.

I don't know if OSError.filename is only used to display more information to the user, or if it is used to do another operation on the file (ex: os.chmod).

I like solutions keeping the filename unchanged, because it does not loose information, and the user can decide how to handle the undecodable filename.

I don't like the option trying to decode the filename or keeping it unchanged it decoding fails, because applications will work in most cases, but "crash" when someone comes with an unusual code page, a special USB key, or a filename with a non-ASCII character.

So the best option is maybe to always keep the bytes filename unchanged.

Such change cannot be done anymore in Python 3.3, it's too late to test it correctly.

----------
components: Unicode, Windows
messages: 166652
nosy: ezio.melotti, flox, haypo, ishimoto, loewis, tim.golden
priority: normal
severity: normal
status: open
title: UnicodeDecodeError on OSError
versions: Python 3.4

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

From report at bugs.python.org  Sat Jul 28 18:13:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 16:13:52 +0000
Subject: [New-bugs-announce] [issue15479] Allow MAX_STRING_LENGTH limits to
	be changed at runtime
Message-ID: <1343492032.88.0.552798503045.issue15479@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to allow the MAX_STRING_LENGTH limit defined in Python/traceback.c to be changed at runtime, as discussed in issue 15463, as well as the two related limits:

#define MAX_STRING_LENGTH 100
#define MAX_FRAME_DEPTH 100
#define MAX_NTHREADS 100

http://hg.python.org/cpython/file/ddf15cd9be4a/Python/traceback.c#l16

----------
messages: 166661
nosy: cjerdonek, haypo
priority: normal
severity: normal
status: open
title: Allow MAX_STRING_LENGTH limits to be changed at runtime
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jul 28 19:49:02 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 17:49:02 +0000
Subject: [New-bugs-announce] [issue15480] Drop TYPE_INT64 from marshal in
	Python 3.4
Message-ID: <1343497742.77.0.0142368260807.issue15480@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

As a follow-up of issue15466, TYPE_INT64 can be deleted in Python 3.4.

----------
messages: 166670
nosy: loewis
priority: deferred blocker
severity: normal
status: open
title: Drop TYPE_INT64 from marshal in Python 3.4
versions: Python 3.4

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

From report at bugs.python.org  Sat Jul 28 21:33:10 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Jul 2012 19:33:10 +0000
Subject: [New-bugs-announce] [issue15481] Add exec_module() as part of the
	import loader API
Message-ID: <1343503990.21.0.184521715499.issue15481@psf.upfronthosting.co.za>


New submission from Eric Snow:

issue15110 introduced a new private function, _exec_module(), to the default loaders in Lib/importlib/_bootstrap.py.  Doing so helped hide importlib frames from the traceback.  A related fix is likely required for issue15425.

Should some general form of exec_module() be an official part of the loader API (in importlib.abc.Loader).  If a loader subclasses one of the default ones, it already gets the behavior for free.  Otherwise it does not benefit from the cleaner traceback (unless the author is savvy to the _exec_module() implementation detail).

Though the use of Loader._exec_module() to strip tracebacks is an implementation detail of CPython, having a public Loader.exec_module() would allow other implementations to perform a similar action.  And if we found a way to move remove_importlib_frames to importlib then all the better.  (Looking into traceback API improvements is on my to-do list.)

As a bonus, Loader.exec_module() would also allow loaders that wrap other loaders (yes, esoteric) to manage the execution portion of loading.  I haven't given this part a lot of thought, so it may not be much of a bonus (or could even be a negative).

>From the perspective of caution, the import machinery is already pretty complicated.  It may not be advisable to add to that even in this little way.

----------
assignee: eric.snow
components: Interpreter Core
messages: 166677
nosy: amaury.forgeotdarc, brett.cannon, eric.snow, pitrou
priority: normal
severity: normal
status: open
title: Add exec_module() as part of the import loader API
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jul 29 04:55:10 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Sun, 29 Jul 2012 02:55:10 +0000
Subject: [New-bugs-announce] [issue15482] __import__() change between 3.2
	and 3.3
Message-ID: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>


New submission from Ronan Lamy:

I noticed a change in the behaviour of __import__() between 3.2 and 3.3. It looks like in 3.2 __import__() does a Py2-style combo relative/absolute import. Here's a minimal test case:

$ ls foo
bar.py  __init__.py  __pycache__
$ cat foo/__init__.py
__import__('bar', globals(), locals())
$ python3.3 -c "import foo"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./foo/__init__.py", line 1, in <module>
    __import__('bar', globals(), locals())
ImportError: No module named 'bar'
$ python3.2 -c "import foo"
$

I believe that 3.3 is correct and that 3.2 is wrong but can't be changed now, so I suppose that 3.2 should just document the actual behaviour of __import__() and 3.3 should document the change. 

(The context is that I encountered issue 15434. This looks related, but I'm not sure it is.)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 166706
nosy: Ronan.Lamy, brett.cannon, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: __import__() change between 3.2 and 3.3
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 29 11:40:33 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:40:33 +0000
Subject: [New-bugs-announce] [issue15483] CROSS: initialise include and
	library paths in setup.py
Message-ID: <1343554833.66.0.976178324221.issue15483@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

In setup.py  inc_dirs and lib_dirs are not initialized in cross-build case.

----------
files: 1-CROSS-initialise-include-and-library-paths.patch
keywords: patch
messages: 166733
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: initialise include and library paths in setup.py
Added file: http://bugs.python.org/file26568/1-CROSS-initialise-include-and-library-paths.patch

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

From report at bugs.python.org  Sun Jul 29 11:43:22 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:43:22 +0000
Subject: [New-bugs-announce] [issue15484] CROSS: use _PYTHON_PROJECT_BASE in
	distutils sysconfig
Message-ID: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Same as sysconfig but now in distutils  _PYTHON_PROJECT_BASE has to be used in cross-build environment.

----------
components: Build
files: 2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch
keywords: patch
messages: 166734
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
versions: Python 3.3
Added file: http://bugs.python.org/file26569/2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch

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

From report at bugs.python.org  Sun Jul 29 11:55:17 2012
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 29 Jul 2012 09:55:17 +0000
Subject: [New-bugs-announce] [issue15485] CROSS: append gcc library search
	paths
Message-ID: <1343555717.99.0.825702829621.issue15485@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Currently if cross-build add_gcc_paths use append_dir_to_list but later prepend library paths. As result  gcc is multilib 64-bit libraries will be found first before 32-bit one.

----------
components: Cross-Build
files: 3-CROSS-append-gcc-library-search-paths.patch
keywords: patch
messages: 166737
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: append gcc library search paths
versions: Python 3.3
Added file: http://bugs.python.org/file26571/3-CROSS-append-gcc-library-search-paths.patch

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

From report at bugs.python.org  Sun Jul 29 12:46:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 10:46:43 +0000
Subject: [New-bugs-announce] [issue15486] Standardise the mechanisms for
	stripping importlib frames
Message-ID: <1343558803.76.0.656342797945.issue15486@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Thanks to issue #15425, the number of special cases in the importlib frame stripping is growing. This patch tweaks the frame stripping mechanism to make it easy to selectively strip frames in importlib._bootstrap by creating a _call_with_frames_removed helper function.

The rules in remove_importlib_frames then change to remove any sequence of importlib frames which ends with that helper and all importlib frames in the ImportError case.

----------
messages: 166745
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Standardise the mechanisms for stripping importlib frames

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

From report at bugs.python.org  Sun Jul 29 15:10:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 13:10:45 +0000
Subject: [New-bugs-announce] [issue15487] Correct __sizeof__ support for
	buffered I/O
Message-ID: <1343567445.16.0.656305805275.issue15487@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of buffered I/O files: io.BufferedReader, io.BufferedWriter and io.BufferedRandom.

----------
components: IO, Library (Lib)
messages: 166756
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for buffered I/O
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 29 19:56:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 17:56:32 +0000
Subject: [New-bugs-announce] [issue15488] Closed files keep their buffer
	alive
Message-ID: <1343584592.55.0.343269676926.issue15488@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> f = open("LICENSE", "rb")
>>> sys.getsizeof(f)
4296
>>> f.close()
>>> sys.getsizeof(f)
4296

Instead of waiting for the file object's deallocation, perhaps we should free the buffer when it is closed?

----------
components: IO, Library (Lib)
messages: 166801
nosy: pitrou
priority: low
severity: normal
status: open
title: Closed files keep their buffer alive
type: resource usage
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jul 29 21:48:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:48:07 +0000
Subject: [New-bugs-announce] [issue15489] Correct __sizeof__ support for
	BytesIO
Message-ID: <1343591287.44.0.516337828305.issue15489@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of io.BytesIO.

----------
components: IO, Library (Lib)
files: bytesio_sizeof-3.3.patch
keywords: patch
messages: 166806
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for BytesIO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26583/bytesio_sizeof-3.3.patch

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

From report at bugs.python.org  Sun Jul 29 21:53:37 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 19:53:37 +0000
Subject: [New-bugs-announce] [issue15490] Correct __sizeof__ support for
	StringIO
Message-ID: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of io.StringIO.

I haven't tested the patch on narrow build.

----------
components: IO, Library (Lib)
files: stringio_sizeof-3.3.patch
keywords: patch
messages: 166807
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for StringIO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26586/stringio_sizeof-3.3.patch

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

From report at bugs.python.org  Sun Jul 29 22:17:08 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 20:17:08 +0000
Subject: [New-bugs-announce] [issue15491] hg.python.org/cpython "browse"
	link defaults to 2.7
Message-ID: <1343593028.62.0.462659118728.issue15491@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

I'm not sure if I'm filing this in the right place since I don't see hg.python.org in the tracker "components" list, but if one clicks on the "Browse online" link of the Dev Guide here:

http://docs.python.org/devguide/

One is taken to--

http://hg.python.org/cpython/

(which is actually the list of revisions rather than the browser).

But if one then clicks on the "browse" link in the left column, it seems to default to the 2.7 branch.

It is a bit confusing because the browser does not say the name of the branch at the top, which can lead to unknowingly browsing the wrong branch.

So there may be three issues here: (1) the Dev Guide links to the revision list rather than directly to the browser, (2) browsing defaults to browsing 2.7 rather than the default branch, and (3) the branch name should be diplayed somewhere on the page when browsing (or better yet, also in the URL itself).

----------
messages: 166810
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: hg.python.org/cpython "browse" link defaults to 2.7

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

From report at bugs.python.org  Sun Jul 29 23:11:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 21:11:57 +0000
Subject: [New-bugs-announce] [issue15492] textwrap.wrap expand_tabs does not
	behave as expected
Message-ID: <1343596317.09.0.0346303694102.issue15492@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

While working on issue 1859, I noticed that textwrap.wrap()'s tab expansion does not seem to behave sensibly.

In particular, the documentation says, "If expand_tabs is true, then all tab characters in text will be expanded to zero or more spaces, *depending on the current column* and the given tab size."

The problem is that tab expansion is done as the first stage (and in particular, before wrapping), which means that "the current column" is no longer current after wrapping.  This leads to results like--

from textwrap import wrap

text = ("a\tb "
        "a\tb")

lines = wrap(text, width=5, tabsize=4)
for line in lines:
    print(repr(line))

Output:
'a   b'
'a b'

One would expect tab expansion to occur after (or while) wrapping, so that tab stops line up in the wrapped output.

----------
messages: 166815
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: textwrap.wrap expand_tabs does not behave as expected

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

From report at bugs.python.org  Mon Jul 30 00:13:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jul 2012 22:13:09 +0000
Subject: [New-bugs-announce] [issue15493] No more Daily OS X installers
Message-ID: <1343599989.22.0.189482939769.issue15493@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The "Daily OS X installer" link in the devguide points to an empty directory (http://www.python.org/dev/daily-dmg/).

----------
components: Devguide
messages: 166822
nosy: ezio.melotti, ned.deily, pitrou, ronaldoussoren
priority: low
severity: normal
status: open
title: No more Daily OS X installers

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

From report at bugs.python.org  Mon Jul 30 03:37:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 01:37:11 +0000
Subject: [New-bugs-announce] [issue15494] Move test/support.py into a
	test.support subpackage
Message-ID: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to move test/support.py into a test.support subpackage as discussed in issue 15403.

This can be done post-release.

----------
components: Tests
messages: 166848
nosy: cjerdonek, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Move test/support.py into a test.support subpackage

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

From report at bugs.python.org  Mon Jul 30 03:49:50 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 30 Jul 2012 01:49:50 +0000
Subject: [New-bugs-announce] [issue15495] enable type truncation warnings
	for gcc builds
Message-ID: <1343612990.44.0.366704900621.issue15495@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

It would seem that enabling GCC's type conversion/truncation warnings would be a good thing for Python builds.

This would bring GCC builds in line with MSVC builds and reduce the burden on the Windows developers in fixing them.  Also, it would bring attention to those issues by the developer who writes code and would hopefully understand the truncation issues at hand.

The CFLAGS required for this are '-Wconversion -Wno-sign-conversion'.

I unfortunately do not know the autoconf foo needed to implement this suggestion, however.  Perhaps it should only be enabled for debug builds as well to eliminate excess noise for other builds.  Or at least enabled on some of the buildbots.

----------
components: Build
messages: 166851
nosy: jkloth
priority: normal
severity: normal
status: open
title: enable type truncation warnings for gcc builds
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jul 30 04:14:55 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 30 Jul 2012 02:14:55 +0000
Subject: [New-bugs-announce] [issue15496] harden directory removal for tests
	on Windows
Message-ID: <1343614495.69.0.283818579392.issue15496@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

Currently, removing directories during testing on Windows w/NTFS can causing sporadic failures due to access denied errors.  This is caused by other processes getting a handle to the directory itself (change notifications) or a handle to a file within the directory.  The most notable offender is the Indexing Service.

Most (but not all!) external programs can be configured to ignore the development directory.  For example, the Indexing Service can be disabled or have those directories ignored.  TortoiseSVN is another offender that can exclude directories but each directory needs to be listed separately so it is easy to forgot one.  On my machine I have programs that simply do not have an option to ignore any directories thus causing some grief during testing.

The attached patch to test.support eliminates the need to disable or and ignores to any programs (tested on a Win7-x64 i7-3770K at 4.3GHz).

It achieves this by checking for the removal of the directory before returning to the caller.  It performs an exponential backoff timeout loop that amounts to a total of ~1 second in the worst case.  If the directory is not removed from the filesystem by then, it will probably be in error anyway.  However, the loop is seldom executed more than once.

----------
components: Tests
files: support.diff
keywords: patch
messages: 166853
nosy: jkloth
priority: normal
severity: normal
status: open
title: harden directory removal for tests on Windows
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26590/support.diff

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

From report at bugs.python.org  Mon Jul 30 06:10:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 04:10:41 +0000
Subject: [New-bugs-announce] [issue15497] correct characters in
	TextWrapper.replace_whitespace docs
Message-ID: <1343621441.45.0.427004155003.issue15497@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to correct the list of whitespace characters to replace in the documentation for the textwrap module's TextWrapper.replace_whitespace attribute.

The documentation says this list is string.whitespace:

http://docs.python.org/dev/library/textwrap.html#textwrap.TextWrapper.replace_whitespace

However, the code deliberately avoids using string.whitespace and uses a hard-coded list of characters instead.  For example, see this code comment:

# Hardcode the recognized whitespace characters to the US-ASCII
# whitespace characters.  The main reason for doing this is that in
# ISO-8859-1, 0xa0 is non-breaking whitespace, so in certain locales
# that character winds up in string.whitespace....

http://hg.python.org/cpython/file/917295aaad76/Lib/textwrap.py#l12

Patch attached.

----------
assignee: docs at python
components: Documentation
files: issue-textwrap-whitespace.patch
keywords: easy, patch
messages: 166855
nosy: cjerdonek, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: correct characters in TextWrapper.replace_whitespace docs
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file26591/issue-textwrap-whitespace.patch

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

From report at bugs.python.org  Mon Jul 30 09:34:24 2012
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Jul 2012 07:34:24 +0000
Subject: [New-bugs-announce] [issue15498] Eliminate the use of deprecated OS
	X APIs in getpath.c
Message-ID: <1343633664.98.0.256476653975.issue15498@psf.upfronthosting.co.za>


New submission from Ned Deily:

getpath.c uses three OS X APIs that have been producing deprecation warnings since at least OS X 10.5:  NSModuleForSymbol, NSLookupAndBindSymbol, and NSLibraryNameForModule.  We should figure out how to live without them.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 166863
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate the use of deprecated OS X APIs in getpath.c
versions: Python 3.4

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

From report at bugs.python.org  Mon Jul 30 13:18:42 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 11:18:42 +0000
Subject: [New-bugs-announce] [issue15499] Sleep is hardcoded in
	webbrowser.UnixBrowser
Message-ID: <1343647122.66.0.223275733233.issue15499@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

webbrowser.UnixBrowser._invoke will sleep for at least 1 second after
launching browser process and then probably 4 more seconds. These numbers
are hardcoded and can't be modified which is especially problematic for
testing.

I think this code should be replaced with Popen.wait with timeout.
A patch is attached.

----------
components: Library (Lib)
files: webbrowser_sleep.patch
keywords: patch
messages: 166877
nosy: anton.barkovsky
priority: normal
severity: normal
status: open
title: Sleep is hardcoded in webbrowser.UnixBrowser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26596/webbrowser_sleep.patch

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

From report at bugs.python.org  Mon Jul 30 14:19:30 2012
From: report at bugs.python.org (Attila Nagy)
Date: Mon, 30 Jul 2012 12:19:30 +0000
Subject: [New-bugs-announce] [issue15500] Python should support naming
	threads
Message-ID: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za>


New submission from Attila Nagy:

Python class Thread has a "name" argument, which sets the name of the given thread. This name is used only internally, while there is a possibility to set this on an OS-level.
Related discussion:
http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-in-pthreads-linux

#include <pthread.h>
int pthread_setname_np(pthread_t thread, const char *name);

// FreeBSD & OpenBSD: function name is slightly different
void pthread_set_name_np(pthread_t tid, const char *name);

// Mac OS X: it only seems applicable to the current thread (no thread ID)
int pthread_setname_np(const char*);

It would be very useful if Python set the name parameter with the above pthread calls, so the user/developer could see which threads do what in ps or top.

----------
components: Library (Lib)
messages: 166890
nosy: bra
priority: normal
severity: normal
status: open
title: Python should support naming threads
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 30 15:31:42 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 13:31:42 +0000
Subject: [New-bugs-announce] [issue15501] Document exception classes in
	subprocess module
Message-ID: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

Exception classes from subprocess module are mentioned in the doc but do
not have their own entries.

I'm attaching patches for 3.3, 3.2 and 2.7

This issue supersedes #14966.

----------
assignee: docs at python
components: Documentation
files: subprocess_doc_3.3.patch
keywords: patch
messages: 166895
nosy: anton.barkovsky, docs at python
priority: normal
severity: normal
status: open
title: Document exception classes in subprocess module
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26598/subprocess_doc_3.3.patch

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

From report at bugs.python.org  Mon Jul 30 15:39:42 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Jul 2012 13:39:42 +0000
Subject: [New-bugs-announce] [issue15502] Meta path finders and path entry
	finders are different, but share an ABC
Message-ID: <1343655582.21.0.35016238234.issue15502@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In the review of #15295, Brett noted that the APIs of meta path finders and path entry finders have now diverged substantially thanks to PEP 420, thus it's rather dubious that they continue to share a single Finder ABC in importlib.

----------
components: Library (Lib)
messages: 166897
nosy: brett.cannon, georg.brandl, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Meta path finders and path entry finders are different, but share an ABC
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 30 16:20:01 2012
From: report at bugs.python.org (=?utf-8?q?Petri_Heinil=C3=A4?=)
Date: Mon, 30 Jul 2012 14:20:01 +0000
Subject: [New-bugs-announce] [issue15503] concatenating string in dict
	unexpected performance
Message-ID: <1343658001.1.0.546887001379.issue15503@psf.upfronthosting.co.za>


New submission from Petri Heinil?:

In concatenating string in dict somehow radically depends the added string size.

code 

----
import timeit

s1 = """
text = ""
for i in range(1,50000):
  text += "12345678901234567890"
"""
print("str cat 20: {0}s".format(timeit.timeit(s1,number=1)))

s2 = """
d = dict()
d["text"] = ""
for i in range(1,50000):
  d["text"] += "12345"
"""
print("dict cat 5: {0}s".format(timeit.timeit(s2,number=1)))

s3 = """
d = dict()
d["text"] = ""
for i in range(1,50000):
  d["text"] += "1234567890"
"""
print("dict cat 10: {0}s".format(timeit.timeit(s3,number=1)))


s4 = """
d = dict()
d["text"] = ""
for i in range(1,50000):
  d["text"] += "12345678901234567890"
"""
print("dict cat 20: {0}s".format(timeit.timeit(s4,number=1)))

----

gives:

str cat 20: 0.011670112609863281s
dict cat 5: 2.994051933288574s
dict cat 10: 6.61974310874939s
dict cat 20: 34.230541944503784s

----------
assignee: collinwinter
components: Benchmarks
files: string_cat.py
messages: 166901
nosy: collinwinter, hevi
priority: normal
severity: normal
status: open
title: concatenating string in dict unexpected performance
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file26603/string_cat.py

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

From report at bugs.python.org  Mon Jul 30 17:43:48 2012
From: report at bugs.python.org (Philipp Lies)
Date: Mon, 30 Jul 2012 15:43:48 +0000
Subject: [New-bugs-announce] [issue15504] pickle/cPickle saves
	invalid/incomplete data
Message-ID: <1343663028.38.0.42350418133.issue15504@psf.upfronthosting.co.za>


New submission from Philipp Lies:

I just stumbled upon a very serious bug in cPickle where cPickle stores the data passed to it only partially without a warning/error:

#creating a >8GB long random data sting
import os
import cPickle
random_string = os.urandom(int(1.1*2**33))
print len(random_string)
fout = open('test.pickle', 'wb')
cPickle.dump(random_string, fout, 2)
fout.close()
fin = open('test.pickle', 'rb')
random_string2 = cPickle.load(fin)
print len(random_string2)
print random_string == random_string2

The loaded string is significantly shorter, meaning that some of the data got lost while storing the string. This is a serious issue. However, when I use pickle, writing fails with 
error: 'i' format requires -2147483648 <= number <= 2147483647
so I guess pickle is not able to handle large data, therefore cPickle should either throw an error as well of pickle/cPickle should be patched to handle larger data.

Code to reproduce error using numpy (that's how I stumbled upon it):
import numpy as np
import cPickle as pickle
A = np.random.randn(1080,1920,553)
fout = open('test.pickle', 'wb')
pickle.dump(A, fout, 2)
fout.close()
fin = open('test.pickle', 'rb')
B = pickle.load(fin)
Here, numpy detects that the amount of data is wrong and throws an error. However, still serious because saving does not lead to an error so the user expects that the data are safely stored.

I guess might be related to http://bugs.python.org/issue13555 which is still open.

Python 2.7.3 on latest Ubuntu with numpy 1.6.2, 64bit architecture, 128GB RAM

----------
messages: 166906
nosy: Philipp.Lies
priority: normal
severity: normal
status: open
title: pickle/cPickle saves invalid/incomplete data
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 30 18:37:02 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 30 Jul 2012 16:37:02 +0000
Subject: [New-bugs-announce] [issue15505] unittest.installHandler
	incorrectly assumes SIGINT	handler is set.
Message-ID: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

unittest.installHandler incorrectly assumes signal.SIGINT will always be set to a callable object, rather than signal.SIG_DFL or signal.SIG_IGN. This breaks if the test is being executed in an environment that e.g. ignores signal.SIGINT, like a bash script that executes 'make' in a subshell, because an attempt to call the original handler (for whatever reason) causes it to try and call an integer.

On top of that, the *tests* for unittest.installHandler in unittest/tests/test_break.py assume not just that signal.SIGINT is set to a callable object, but that they're set to signal.default_int_handler.

----------
components: Tests
messages: 166910
nosy: twouters
priority: normal
severity: normal
status: open
title: unittest.installHandler incorrectly assumes SIGINT handler is set.
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jul 30 19:52:21 2012
From: report at bugs.python.org (Mike Frysinger)
Date: Mon, 30 Jul 2012 17:52:21 +0000
Subject: [New-bugs-announce] [issue15506] configure should use
	PKG_PROG_PKG_CONFIG
Message-ID: <1343670741.23.0.818269374942.issue15506@psf.upfronthosting.co.za>


New submission from Mike Frysinger:

the current configure script open codes the pkg-config look up:
AC_PATH_TOOL([PKG_CONFIG], [pkg-config])

rather than using the standard macro from pkg-config's own pkg.m4:
PKG_PROG_PKG_CONFIG

this causes the build env to not operate exactly like other pkg-config autoconf builds :(

simple fix:
-AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
+PKG_PROG_PKG_CONFIG

----------
components: Build
messages: 166915
nosy: vapier
priority: normal
severity: normal
status: open
title: configure should use PKG_PROG_PKG_CONFIG
type: compile error

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

From report at bugs.python.org  Mon Jul 30 22:35:41 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 30 Jul 2012 20:35:41 +0000
Subject: [New-bugs-announce] [issue15507] test_subprocess assumes SIGINT is
	not being ignored.
Message-ID: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

test_subprocess's test_send_signal assumes SIGINT is not being ignored, by spawning a new process and expecting it to have the default SIGINT handler . SIGINT can be set to SIG_IGN if the process running the test inherited it from the parent process.

----------
components: Tests
messages: 166921
nosy: twouters
priority: normal
severity: normal
status: open
title: test_subprocess assumes SIGINT is not being ignored.
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jul 30 23:39:34 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Jul 2012 21:39:34 +0000
Subject: [New-bugs-announce] [issue15508] __import__.__doc__ has outdated
	information about level
Message-ID: <1343684374.06.0.811645492819.issue15508@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

$ python3.2 -c '__import__("os", level=-1)'
$ python3.3 -c '__import__("os", level=-1)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: level must be >= 0
$ python3.3 -c 'print(__import__.__doc__)'
__import__(name, globals={}, locals={}, fromlist=[], level=-1) -> module

Import a module. Because this function is meant for use by the Python
interpreter and not for general use it is better to use
importlib.import_module() to programmatically import a module.

The globals argument is only used to determine the context;
they are not modified.  The locals argument is unused.  The fromlist
should be a list of names to emulate ``from name import ...'', or an
empty list to emulate ``import name''.
When importing a module from a package, note that __import__('A.B', ...)
returns package A when fromlist is empty, but its submodule B when
fromlist is not empty.  Level is used to determine whether to perform 
absolute or relative imports.  -1 is the original strategy of attempting
both absolute and relative imports, 0 is absolute, a positive number
is the number of parent directories to search relative to the current module.
$

Also please add a ".. versionchanged:: 3.3" note in Doc/library/functions.rst about no longer allowed negative level.

----------
messages: 166925
nosy: Arfrever, brett.cannon
priority: normal
severity: normal
status: open
title: __import__.__doc__ has outdated information about level
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 31 00:35:18 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 22:35:18 +0000
Subject: [New-bugs-announce] [issue15509] webbrowser.open sometimes passes
	zero-length argument to	the browser.
Message-ID: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

Because of the way webbrowser.UnixBrowser.open generates command-line
arguments the resulting list sometimes looks like this:

  ['chromium', '', 'http://www.example.org/']

This seems to work fine with chromium for me but as you can see:

  >>> subprocess.call(['ls', '', '-l'])
  ls: cannot access : No such file or directory
  2

It's not a good idea to rely on that.
I'm attaching a patch that filters out those empty arguments.

----------
components: Library (Lib)
files: webbrowser_args.patch
keywords: patch
messages: 166930
nosy: anton.barkovsky
priority: normal
severity: normal
status: open
title: webbrowser.open sometimes passes zero-length argument to the browser.
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26607/webbrowser_args.patch

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

From report at bugs.python.org  Tue Jul 31 03:26:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 01:26:19 +0000
Subject: [New-bugs-announce] [issue15510] textwrap.wrap('') returns empty
	list
Message-ID: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

While working on issue 1859, I found that textwrap.wrap() returns an empty list when passed the empty string:

>>> from textwrap import wrap
>>> wrap('')
[]

as opposed to a list containing the empty string which is what I expected--

['']

I originally accepted this as intended behavior, but for the following reasons I now think it is a bug that we should consider fixing:

1. The textwrap documentation says that wrap(), "Wraps the single paragraph in text (a string) so every line is at most width characters long. Returns a list of output lines, without final newlines."  The empty string is less than width characters long, so following the documentation, wrapping should not change it.

2. It is known that wrap() is broken for strings containing newlines (i.e. strings containing more than one paragraph).  Indeed, this is the issue that issue 1859 is meant to fix.

The commonly recommended work-around is to call splitlines() on the incoming string, pass the pieces to wrap(), and then join the return values on newlines.

However, the behavior described in this issue causes this workaround not to behave sensibly when the original string contains breaks between paragraphs.  See this message, for example:

http://bugs.python.org/issue1859#msg166627

Currently, this work-around would return "a\nb" for both "a\nb" and "a\n\nb" for example when common sense says it should preserve the newlines and return "a\nb" and "a\n\nb", respectively.

3. In addition, the behavior causes the following inconsistent behavior:

>>> repr(wrap('  ', drop_whitespace=False))
"['  ']"
>>> repr(wrap('  ', drop_whitespace=True))
'[]'

The documentation says this about drop_whitespace: "If true, whitespace that, after wrapping, happens to end up at the beginning or end of a line is dropped."  If the first case is correct, then, the second case should at least return a non-empty list because that is what would result from dropping whitespace from the string '  ' in the first list.  This is how drop_whitespace behaves when the string contains non-whitespace characters:

>>> repr(wrap('a  ', drop_whitespace=False))
"['a  ']"
>>> repr(wrap('a  ', drop_whitespace=True))
"['a']"

4. There is no unit test for the case of the empty string, and existing tests still pass after fixing the issue.

If we cannot correct this behavior, then I feel we should at least document the inconsistent behavior, and then work around it in the fix for issue 1859.

Marking for this issue to be resolved either way before fixing issue 1859.  I am happy to prepare the patch.

----------
messages: 166940
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: textwrap.wrap('') returns empty list
type: behavior

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

From report at bugs.python.org  Tue Jul 31 09:39:02 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Jul 2012 07:39:02 +0000
Subject: [New-bugs-announce] [issue15511] _decimal does not build in
	PGUpdate mode
Message-ID: <1343720342.96.0.267944398489.issue15511@psf.upfronthosting.co.za>


New submission from Stefan Krah:

_decimal does not build in PGUpdate mode. I didn't notice this because
I've always used the Release mode so far:

msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=x64
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=x64


"C:\Users\stefan\pydev\cpython\PCbuild\pcbuild.sln" (default target) (1) ->                                              
"C:\Users\stefan\pydev\cpython\PCbuild\_decimal.vcxproj" (default target) (10) ->                                        
(Link target) ->                                                                                                         
  LINK : fatal error LNK1181: cannot open input file 'C:\Users\stefan\pydev\cpython\PCbuild\\amd64\python33.lib' [C:\Use 
rs\stefan\pydev\cpython\PCbuild\_decimal.vcxproj]

----------
components: Extension Modules
messages: 166970
nosy: brian.curtin, loewis, skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: _decimal does not build in PGUpdate mode
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 31 10:31:53 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:31:53 +0000
Subject: [New-bugs-announce] [issue15512] Correct __sizeof__ support for
	parser
Message-ID: <1343723513.03.0.835632561476.issue15512@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for ST objects in parser module.

----------
components: Interpreter Core, Library (Lib)
files: parser_sizeof.patch
keywords: patch
messages: 166978
nosy: benjamin.peterson, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for parser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26613/parser_sizeof.patch

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

From report at bugs.python.org  Tue Jul 31 10:35:39 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:35:39 +0000
Subject: [New-bugs-announce] [issue15513] Correct __sizeof__ support for
	pickle
Message-ID: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for Pickler and Unpickler in pickler module.

----------
components: Library (Lib)
files: pickle_sizeof-3.3.patch
keywords: patch
messages: 166979
nosy: alexandre.vassalotti, pitrou, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for pickle
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26615/pickle_sizeof-3.3.patch

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

From report at bugs.python.org  Tue Jul 31 10:40:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Jul 2012 08:40:04 +0000
Subject: [New-bugs-announce] [issue15514] Correct __sizeof__ support for
	cpu_set
Message-ID: <1343724004.49.0.263322089559.issue15514@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for cpu_set class in os module.

This is 3.3-only issue.

----------
components: Library (Lib)
files: cpu_set_sizeof.patch
keywords: patch
messages: 166981
nosy: loewis, storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for cpu_set
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26619/cpu_set_sizeof.patch

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

From report at bugs.python.org  Tue Jul 31 20:08:58 2012
From: report at bugs.python.org (Caleb Rouleau)
Date: Tue, 31 Jul 2012 18:08:58 +0000
Subject: [New-bugs-announce] [issue15515] Regular expression match does not
	return
Message-ID: <1343758138.43.0.559829332434.issue15515@psf.upfronthosting.co.za>


New submission from Caleb Rouleau:

Version info: 2.7.1 (r271:86832, Feb  7 2011, 11:33:02) [MSC v.1500 64 bit (AMD64)]

The program included never prints "done" because it never returns from re.match(). 

 -- Caleb Rouleau

----------
components: Regular Expressions
files: RegexBug.py
messages: 167024
nosy: crouleau, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regular expression match does not return
versions: Python 2.7
Added file: http://bugs.python.org/file26627/RegexBug.py

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

From report at bugs.python.org  Tue Jul 31 21:59:40 2012
From: report at bugs.python.org (Tom Tromey)
Date: Tue, 31 Jul 2012 19:59:40 +0000
Subject: [New-bugs-announce] [issue15516] exception-handling bug in
	PyString_Format
Message-ID: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za>


New submission from Tom Tromey:

In gdb we supply a class whose nb_int method can throw
an exception.

A user wrote code like this:

    return '%x' % value

... where "value" was an instance of this class.
This caused funny exception behavior later on.
You can see the original report here:

http://sourceware.org/bugzilla/show_bug.cgi?id=14320

I tracked down the odd behavior to this code in
stringobject.c:PyString_Format:

                        iobj = PyNumber_Int(v);
                        if (iobj==NULL) iobj = PyNumber_Long(v);

Here, PyNumber_Int fails and sets the exception.
I think this ought to be cleared before calling
PyNumber_Long.  In our case, PyNumber_Long succeeds,
and the program keeps executing until something happens
to call PyErr_Occurred.

I think this patch ought to fix the problem:

diff -r e0eb7dea245f Objects/stringobject.c
--- a/Objects/stringobject.c	Mon Jul 30 04:07:49 2012 -0700
+++ b/Objects/stringobject.c	Tue Jul 31 13:58:07 2012 -0600
@@ -4489,7 +4489,10 @@
                     }
                     else {
                         iobj = PyNumber_Int(v);
-                        if (iobj==NULL) iobj = PyNumber_Long(v);
+                        if (iobj==NULL) {
+			    PyErr_Clear();
+			    iobj = PyNumber_Long(v);
+			}
                     }
                     if (iobj!=NULL) {
                         if (PyInt_Check(iobj)) {

I haven't written a test case yet; David Malcolm suggested I file
a bug here first.

----------
components: None
messages: 167043
nosy: tromey
priority: normal
severity: normal
status: open
title: exception-handling bug in PyString_Format
type: behavior
versions: Python 2.7

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